09 out 2026 · javascript, infraestrutura, plataformas · 4 min
Cloudflare comprou a Deno: o runtime tem um ano de vida
O anúncio
Hoje, 9 de outubro, Ryan Dahl confirmou que o time inteiro da Deno entra na Cloudflare. O texto está no blog da Deno, com um segundo post assinado por Dahl e Kenton Varda no blog da Cloudflare.
O destino de cada componente
| componente | prazo | o que acontece |
|---|---|---|
| runtime Deno | 1 ano | releases mensais com correções de bug e de segurança. Depois disso, o desenvolvimento para, e o código segue aberto a quem quiser continuar |
| Deno Deploy | 6 meses | encerra. Clientes pagantes recebem suporte para migrar para o Cloudflare Workers |
| JSR | sem prazo | continua funcionando, com a infraestrutura migrando para a Cloudflare |
| rusty_v8 | sem prazo | segue com suporte e caminha para integração no workerd |
O motivo declarado não é o runtime em si. Dahl escreveu que a ambição sempre foi maior que o runtime e que o destino é o modelo do Workers: computação, estado e comunicação no mesmo lugar, sem cada aplicação montar a própria infraestrutura. Varda foi mais direto no post da Cloudflare: os dois times vão fundir o workerd e o celld, e a própria Cloudflare admite que o suporte a Durable Objects no workerd era de instância única, bom para teste local, sem escala.
O que muda para quem roda no próprio servidor
A parte interessante para quem hospeda em casa é o que a Cloudflare diz sobre self-hosting. O objetivo declarado é transformar o modelo do Workers no jeito padrão de construir servidores, rodando na rede deles ou na sua. O post convida a subir o celld ou o workerd hoje mesmo. O que falta é escala: Durable Objects distribuídos. É justamente o buraco que o time da Deno foi ajudar a fechar, segundo o próprio anúncio.
Traduzindo: o runtime da Deno perde prioridade, e a Cloudflare ganha um caminho aberto para competir em hospedagem de aplicação, inclusive fora da própria nuvem.
O que eu medi
Baixei os dois runtimes nesta VM (4 vCPU, 5,8 GB de RAM, Ubuntu 24.04, kernel 6.8) e rodei o mesmo hello world e o mesmo servidor HTTP mínimo. Seis execuções de cada, mediana do relógio de parede, memória lida pela API de cada runtime.
| medida | Node 22.23.3 | Deno 2.9.7 |
|---|---|---|
| hello world, mediana de 6 execuções | 38,5 ms | 24 ms |
| RSS no início do script | 41,3 MB | 28,4 MB |
| RSS com servidor HTTP escutando | 46,0 MB | 32,0 MB |
| tamanho do binário | 124,8 MB | 95,8 MB |
Duas observações que apareceram no caminho. A primeira: o servidor da Deno não sobe sem –allow-net, e o runtime avisa isso antes de executar. No Node, a mesma linha de código abre a porta sem pedir nada. A segunda: ao tentar ler /proc/self/status de dentro do script para pegar a memória, a Deno recusou o acesso mesmo com –allow-read apontando exatamente para esse arquivo, e só aceitou com permissão total. Foi por isso que os números de memória vêm da API de cada runtime, e não do /proc.
Como eu leio esses números
A Deno ganha em boot e em memória neste recorte, e o binário menor é parte da explicação. Nada disso explica o desligamento: um runtime com 28 MB de RSS num hello world não morre por desempenho. O que faltou foi modelo de negócio, e o post da Organic Software, de quem construiu produtos em cima da Deno, diz isso sem rodeios. Eles somaram clientes, bibliotecas e serviços (Deno Deploy, Sandboxes, Fresh) e concluíram que a migração de volta para Node ou para Bun é direta, porque a Deno nunca teve lock-in forte.
Se você depende da Deno
- Deno Deploy: o prazo é o mais curto, seis meses. Migre para Workers ou para outro host antes disso.
- Runtime Deno: um ano de correções. Se você precisa dele depois, os caminhos são congelar a versão, acompanhar os forks ou migrar para Node ou Bun.
- JSR: continua funcionando. Não é motivo de pressa.
- Bibliotecas: o ecossistema npm segue com muito mais oferta, e foi o próprio caminho que a Deno adotou ao aceitar npm nos últimos anos.
O que eu não faria: trocar de runtime por causa do anúncio. Se o que você tem funciona e está em versão fixada, um ano é tempo de planejar a migração, não de fazer correção apressada.