# Deno junta-se à Cloudflare; Deno Deploy encerra em seis meses

Published: 2026-10-09

A equipa completa da Deno está a juntar-se à Cloudflare. O Deno Deploy irá operar por seis meses antes de encerrar, com suporte de migração para clientes pagantes que mudem para Workers. A equipa atual irá manter o "runtime" de código aberto por mais um ano, enquanto o JSR continua a operar. Este "Daily Diff" de 9 de outubro separa esses compromissos do trabalho futuro de fusão de "workerd" e "celld" para "self-hosting" distribuído. Histórias de apoio explicam o SDK de "sandbox" MXC da Microsoft e as demonstrações de gráficos reais do Bevy 0.20, requisitos de "hardware" e "tradeoffs" de qualidade. O veredicto de Niko é "NEEDS REVIEW": planeie a migração de "hosting" e identifique o proprietário da manutenção do "runtime".

Canonical: https://thedailydiff.dev/pt-PT/video/deno-cloudflare-deploy-deadline/

## O que este vídeo aborda

- Deno é um "runtime" de JavaScript e TypeScript de código aberto. Deno Deploy é um serviço de "hosting" gerido separado; o seu suporte e planos de encerramento são diferentes.
- O Deno Deploy irá operar por seis meses antes de encerrar. O anúncio oferece suporte de migração para clientes pagantes que mudem para Cloudflare Workers, sem estabelecer compatibilidade universal de substituição direta.
- A equipa atual promete mais um ano de correções mensais de "bugs" e atualizações de segurança do "runtime", e depois termina o seu próprio desenvolvimento de "runtime". O Deno permanece de código aberto e outros podem continuar o desenvolvimento.
- O JSR continuará a operar com a infraestrutura a ser movida para a Cloudflare. O suporte a "rusty\_v8" continua, com trabalho para integrá-lo no "workerd".
- A fusão de "workerd"/"celld" visa melhorar o "self-hosting" de Workers e Durable Objects. A Cloudflare reconhece que a implementação atual de Durable Objects do "workerd" é de instância única e não pode fornecer a escalabilidade distribuída pretendida. A plataforma fundida é trabalho futuro.
- Microsoft MXC é um SDK incorporado para execução em "sandbox" de código não confiável em Windows, Linux e macOS, com SDKs para Rust, .NET e Node. A sua versão 1.0 foi publicada a 7 de outubro; o repositório inclui o histórico de lançamento público de junho.
- As "sandboxes" de processo nativas do SO do MXC e os "backends" de VM têm diferentes limites de segurança. O modo de auditoria desativa explicitamente a segurança da "sandbox" para análise de políticas confiáveis e não deve ser usado para cargas de trabalho não confiáveis.
- Bevy 0.20, lançado a 8 de outubro, é um motor de jogo Rust gratuito e de código aberto. O Solari experimental requer suporte a "ray-query". O suporte a Metal/macOS é fornecido sem um "denoiser" Mac incorporado; o episódio não faz nenhuma afirmação sobre DLSS em Mac ou "hardware" universal.
- Bevy torna o ReSTIR opcional e desativado por padrão para desempenho. Isso pode reduzir a qualidade das sombras ou perder sombras em movimento em cenas com muitas luzes, portanto, as cenas existentes precisam de revisão. A melhoria do "lag" das sombras e do brilho das reflexões são melhorias separadas da versão.

## Capítulos

- 0:00 O que sobrevive à entrada da Deno na Cloudflare?
- 0:46 Quem tem seis meses para migrar?
- 1:21 O que acontece ao "runtime" e ao JSR?
- 2:03 Porquê construir Workers auto-hospedados?
- 2:42 O que é o "sandbox" MXC da Microsoft?
- 3:55 O que mudou na iluminação do Bevy?
- 4:41 O que ainda falta à saída?
- 4:54 Porquê "NEEDS REVIEW" na mudança da Deno?

## Transcrição traduzida

Traduzido da narração original em inglês. Áudio e legendas disponíveis são controlados pelo YouTube.

### O que sobrevive à entrada da Deno na Cloudflare?

0:00 Código aberto parece permanente. A equipa completa da Deno está a juntar-se à Cloudflare, e o Deno Deploy tem seis meses antes do encerramento. Neste vídeo, o que sobrevive? Quem move a sua aplicação? E pode a Cloudflare facilitar a saída? É sexta-feira, nove de outubro, e este é o "The Daily Diff". Mantenha uma questão aberta, porque a porta de saída tem uma peça em falta. Deno é um "runtime" de código aberto,

0:20 o programa que executa JavaScript e TypeScript fora do seu navegador. Inclui ferramentas para testar e empacotar o seu código. Deno Deploy é o serviço de "hosting" separado que executa as suas aplicações nos servidores de outra pessoa. Esses têm futuros diferentes. Ryan Dahl, que criou o Node, anunciou a mudança hoje. A Microsoft tem uma "sandbox" para o código que o seu agente quer executar,

0:38 e ontem Bevy lançou gráficos de jogos Rust mais bonitos. Aparentemente, o "ticket" de migração de sexta-feira vem com suporte emocional "ray traced". Aqui está o prazo de "hosting" no próprio anúncio da Deno.

### Quem tem seis meses para migrar?

0:48 Deploy continua a operar por seis meses, depois encerra. Clientes pagantes recebem suporte de migração para Cloudflare Workers. Se o Deploy hospeda o seu negócio, esse calendário agora pertence ao seu planeamento de incidentes, ao lado do orçamento para café. Workers executa código do lado do servidor na rede da Cloudflare. Mudar para lá significa verificar as suposições da sua aplicação. Faça um inventário das conexões da base de dados, "jobs" em segundo plano e dados armazenados. A ajuda de migração precisa de uma revisão de compatibilidade antes de prometer ao chefe um

1:12 fim de semana sem problemas. Todos os outros recebem o aviso de encerramento. Essa é uma distinção útil quando alguém reencaminha a manchete com as palavras reconfortantes, "deve ficar bem", e imediatamente fica "offline".

### O que acontece ao "runtime" e ao JSR?

1:21 O "runtime" recebe mais um ano de correções mensais de "bugs" e atualizações de segurança desta equipa. Depois o seu desenvolvimento termina. O código-fonte permanece aberto, e outros "maintainers" podem continuá-lo. O seu executável existente continua a funcionar, mas o seu futuro suporte agora precisa de um proprietário. JSR, o registo de pacotes para JavaScript e TypeScript, continua a operar enquanto a sua infraestrutura se move para a Cloudflare. A equipa também continua a suportar "rusty vee eight", as suas "bindings" Rust para o motor JavaScript da Google, e planeia integrar esse trabalho no "runtime" da Cloudflare.

1:49 Então o logótipo do dinossauro sobrevive, o "hosting" tem um prazo, e as pessoas que constroem o "runtime" escolheram outro projeto. Uma licença aberta preserva a sua capacidade de assumir o trabalho. Infelizmente, é fornecido sem a equipa de engenharia sobressalente necessária para o fazer. O novo foco é a fusão de "workerd" e "celld" para simplificar o "self-hosting" de Workers e

### Porquê construir Workers auto-hospedados?

2:07 Durable Objects. Um Durable Object é uma peça de código de servidor endereçável individualmente com a sua própria base de dados, útil para manter as mensagens e conexões de uma sala de "chat" juntas. Use um objeto por sala, e a plataforma pode distribuir as salas por várias máquinas. Dahl descreve o "celld" como um binário Rust com armazenamento de objetos como a sua única dependência de serviço externo. Essa é a ambição, menos projetos de infraestrutura anexados a cada aplicação. Isso parece atraente se alguma vez construiu uma aplicação de "chat" e acidentalmente fundou

2:34 um departamento de administração de bases de dados. Os programadores poderiam operar o mesmo modelo de programação eles próprios. A porta de saída operacional ainda precisa do trabalho a que voltaremos.

### O que é o "sandbox" MXC da Microsoft?

2:42 O "Execution Container" da Microsoft, ou M X C, é um "kit" de "software" que a sua aplicação incorpora para executar código não confiável dentro de uma "sandbox". Isso significa restringir o que um "plugin" ou um programa gerado por um agente pode aceder, em vez de lhe entregar o seu portátil inteiro e esperar que a "prompt" fosse educada. Suporta Windows, Linux e macOS, com SDKs para Rust, .net e Node. Você especifica a carga de trabalho e a política. A versão um chegou a sete de outubro, e o repositório tem um "commit" de lançamento público de

3:10 junho. A atenção de hoje veio mais tarde. A parte inteligente é uma interface comum sobre diferentes limites. A parte perigosa é assumir que são idênticos porque a API parece organizada. Também pode colocar a parte complicada longe o suficiente para que ninguém a verifique. O Linux usa "Bubblewrap" por padrão, e o macOS usa "Seatbelt". O Windows usa um "container" de processo por padrão. Outros "backends" incluem máquinas virtuais, com alguns marcados como experimentais. Uma "sandbox" de processo de sistema operativo e uma máquina virtual separada têm

3:36 diferentes limites de segurança. Escolha o "backend" para a carga de trabalho que está realmente a executar. E leia o aviso do modo de auditoria. A auditoria desliga toda a segurança da "sandbox" para a carga de trabalho que está a ser analisada. É para aprender o que uma ferramenta confiável precisa, para que possa criar a sua política. Colocar um "script" de agente desconhecido nesse modo anularia a razão pela qual instalou a "sandbox". Bevy é um motor de jogo gratuito e de código aberto construído em Rust.

### O que mudou na iluminação do Bevy?

3:57 A versão zero ponto vinte chegou ontem. O seu "renderer" Solari experimental simula a luz a saltar pela cena em tempo real, com sombras em movimento melhoradas e reflexões menos cintilantes à medida que a câmara se move. Solari precisa de suporte a "ray query". Agora funciona no macOS através do Metal, embora a versão Mac não tenha um "denoiser" embutido. A técnica de amostragem de luz chamada ReSTIR está desativada por padrão para desempenho. Isso pode reduzir a qualidade das sombras e perder sombras em movimento em cenas

4:21 com muitas luzes. Teste a sua cena antes de celebrar. Existem mais "widgets" de interface e uma extensão de linguagem de "shader" chamada wesl. Pode arrastar um valor numérico para o alterar, uma demonstração refrescantemente pequena depois de descobrir onde os seus servidores vão viver. Se preferir ler isto do que ouvir-me dizer, o "diff" chega à sua caixa de entrada todas as manhãs, gratuitamente em "thedailydiff dot dev", link abaixo. Aqui está a peça em falta.

### O que ainda falta à saída?

4:41 O "workerd" de código aberto suporta Durable Objects numa única instância, o que limita a escalabilidade. A fusão de "celld" destina-se a preencher essa lacuna. O impulso de "self-hosting" da Cloudflare poderia facilitar uma saída, mas a plataforma distribuída finalizada permanece trabalho futuro.

### Porquê "NEEDS REVIEW" na mudança da Deno?

4:54 Então o veredicto de hoje, "needs review". Eu colocaria a migração do Deploy no calendário agora e exigiria um proprietário de manutenção nomeado antes de construir mais em torno do "runtime". Subscreva, toque no sino, e diga-me nos comentários se o teria carimbado de forma diferente. E esse é o "diff" de hoje. Sou o Niko da Axrisi. Faça a fusão responsavelmente.

## Fontes

- [Deno is joining Cloudflare](https://deno.com/blog/cloudflare) — Deno / Ryan Dahl
- [Deno is joining Cloudflare — joint self-hosting plan](https://blog.cloudflare.com/deno-joins-cloudflare/) — Cloudflare / Ryan Dahl and Kenton Varda
- [Microsoft eXecution Container README and audit warning](https://github.com/microsoft/mxc) — Microsoft on GitHub
- [MXC SDK v1.0.0 release](https://github.com/microsoft/mxc/releases/tag/v1.0.0) — Microsoft on GitHub
- [Bevy 0.20 release notes](https://bevy.org/news/bevy-0-20/) — Bevy Contributors
- [Solari in Bevy 0.20 — technical explanation and real demos](https://jms55.github.io/posts/2026-09-18-solari-bevy-0-20/) — JMS55
- [Solari 0.20 source: experimental status and required ray-query features](https://github.com/bevyengine/bevy/blob/v0.20.0/crates/bevy_solari/src/lib.rs) — Bevy on GitHub
- [Deno is joining Cloudflare discussion](https://news.ycombinator.com/item?id=50019911) — Hacker News
- [Microsoft MXC discussion](https://news.ycombinator.com/item?id=50016489) — Hacker News
- [Bevy 0.20 discussion](https://news.ycombinator.com/item?id=50013610) — Hacker News