Ryan Dahl criou o Node.js em 2009, se arrependeu em 2018, criou o Deno pra consertar tudo, e agora em 2026 vendeu o Deno pra Cloudflare. O runtime que nasceu como “o Node feito direito” tem data de validade: 12 meses de patches de segurança e acabou. O Deno Deploy? Seis meses e fecha.

Se você usa Deno em produção, esse artigo é urgente. Se não usa, ele ainda é uma aula sobre como o mercado de serverless está se reorganizando ao redor de um projeto que quase ninguém conhece: o CellD.

O que aconteceu, exatamente?

No dia 9 de outubro de 2026, o time inteiro do Deno anunciou que está se juntando à Cloudflare. Ryan Dahl e Bert Belder vão liderar um esforço para permitir que desenvolvedores rodem aplicações Workers em infraestrutura própria. O email do Ryan agora é ry@cloudflare.com.

Não teve valor divulgado. Mas os termos práticos são claros:

O código do Deno continua open source (licença MIT). Qualquer pessoa pode forkar e continuar. Mas sem o time principal, sem a empresa por trás, a realidade é que o Deno como projeto ativo morreu.

Por que a Cloudflare quer o Deno (spoiler: não é pelo runtime)

Vamos ser diretos: a Cloudflare não comprou o Deno pelo Deno. Comprou pelo CellD.

O CellD é um daemon escrito em Rust que Ryan Dahl lançou em agosto de 2026. Ele faz algo que a própria Cloudflare tentou e falhou: rodar Durable Objects e Workers de forma distribuída, fora da infraestrutura da Cloudflare, usando storage S3-compatível como camada de coordenação.

Kenton Varda, arquiteto principal da Cloudflare e criador do workerd, tentou construir uma versão self-hosted dos Durable Objects e, nas palavras dele, “embarrassingly didn’t work”. O CellD resolveu o problema com uma abordagem diferente: epoch fencing tokens sobre object storage padrão, SQLite para estado por objeto e o runtime Tokio do Rust para execução assíncrona.

O que são Durable Objects (pra quem não conhece)

Durable Objects são a feature mais poderosa (e mais presa ao vendor) do Cloudflare Workers. Pensa neles como mini-servidores stateful que vivem na edge. Cada objeto tem:

• Um ID único global
• Estado persistente (storage + SQLite)
• Garantia de single-threaded (sem race conditions)
• WebSocket nativo

Eles são perfeitos para: chat em tempo real, sessões de jogo multiplayer, collaborative editing, rate limiting distribuído e, cada vez mais, agentes de IA stateful.

O problema? Até agora, Durable Objects só existiam dentro da Cloudflare. Se você construía em cima deles, estava locked-in. Ponto.

CellD muda o jogo

O CellD é um binário único em Rust que roda em qualquer servidor. Você aponta ele pra um bucket S3 (ou MinIO, R2, qualquer coisa S3-compatível), e ele te dá:

• Workers API compatível
• Durable Objects com estado distribuído
• Coordenação via fencing tokens (sem necessidade de Raft/Paxos)
• Custo de infra ~88% menor que Cloudflare managed

Isso é enorme. A Cloudflare está dizendo: “pode rodar nosso modelo de programação onde quiser”. Parece contraintuitivo, certo? Por que facilitar a saída dos clientes?

Porque a aposta é que, ao remover o medo do lock-in, mais empresas entram. Kubernetes fez a mesma jogada com o Docker. O modelo de programação vira o padrão, e quem oferece o managed service (Cloudflare) captura o mercado que não quer gerenciar infra.

O impacto real: quem se ferrou?

Usuários do Deno Deploy

Se você tem workloads no Deno Deploy, o relógio está correndo. Seis meses. A Cloudflare prometeu “migration support” para clientes pagos, o que na prática significa ajuda para migrar pra Workers. Se seu código já usa as APIs do Deno, prepare-se para adaptar.

A migração não é trivial, mas também não é um rewrite completo. O modelo de Workers é similar em conceito (isolates V8, request/response), mas as APIs são diferentes. O Deno.serve() vira export default { fetch() {} }. Os módulos NPM que você importava com npm: precisam funcionar no ambiente do workerd.

Supabase e Netlify

Aqui a coisa fica interessante. O Supabase Edge Functions e o Netlify Edge Functions são construídos sobre o runtime do Deno. Com o fim do desenvolvimento ativo do Deno em 12 meses, esses serviços precisam decidir: forkar o Deno e manter sozinhos, ou migrar para outra base.

O Supabase provavelmente já está avaliando alternativas. O Netlify tem mais flexibilidade porque seu edge runtime pode rodar sobre diferentes engines. Mas nenhum dos dois está em posição confortável.

Bun e Node.js

O Bun de Jarred Sumner é o último runtime “alternativo” independente, e agora carrega sozinho a bandeira de “alternativa ao Node”. Irônico, porque o Bun sempre foi mais sobre performance do que sobre princípios de design (que era o pitch do Deno).

Node.js, por outro lado, sai fortalecido. É o único runtime JavaScript mainstream com governança independente (OpenJS Foundation). Nenhuma empresa pode comprar e matar o Node. Essa estabilidade institucional, que parecia burocrática, agora parece visionária.

CellD por dentro: a arquitetura que convenceu a Cloudflare

Eu fui olhar o código e a documentação do CellD pra entender por que a Cloudflare pagou por algo que não conseguiu construir internamente.

O problema que o workerd não resolvia

O workerd (o runtime open source da Cloudflare) roda Workers isolates perfeitamente. Mas Durable Objects precisam de coordenação distribuída: garantir que apenas uma instância de cada objeto exista em todo o cluster, rotear requests para o nó correto, e manter o estado consistente.

Dentro da Cloudflare, isso é resolvido pela infraestrutura proprietária deles. Mas quando tentaram empacotar isso no workerd open source, não funcionou. A coordenação distribuída é um problema difícil, e a solução interna da Cloudflare estava muito acoplada à rede deles.

A sacada do CellD: S3 como coordenador

Em vez de implementar consenso distribuído (Raft, Paxos), o CellD usa uma técnica elegante: epoch fencing tokens sobre object storage.

┌─────────────┐     ┌─────────────┐     ┌─────────────┐
│   CellD #1  │     │   CellD #2  │     │   CellD #3  │
│  (Rust bin) │     │  (Rust bin) │     │  (Rust bin) │
└──────┬──────┘     └──────┬──────┘     └──────┬──────┘
       │                   │                   │
       └───────────┬───────┴───────────────────┘
                   │
           ┌───────▼───────┐
           │  S3 / MinIO   │
           │  (coordination│
           │   + storage)  │
           └───────────────┘

Cada instância de CellD compete por “leases” nos objetos via operações condicionais do S3. Quem ganha o lease, processa os requests daquele Durable Object. Se um nó cai, o lease expira e outro nó assume. Sem eleição de líder, sem heartbeats complexos, sem split-brain.

O SQLite local cuida do estado rápido (leituras e escritas no objeto), e o S3 serve como durabilidade e coordenação. Simples, barato e surpreendentemente robusto.

Benchmark: CellD vs Cloudflare Managed

Os números que circularam na comunidade mostram que o CellD self-hosted sai 88% mais barato que usar Durable Objects diretamente na Cloudflare. Claro, você paga com complexidade operacional (precisa gerenciar os servidores, o S3, monitoramento). Mas pra empresas que já têm infra AWS/GCP, o custo marginal é baixo.

O que isso significa para agentes de IA

Ryan Dahl deixou claro no anúncio que seu foco na Cloudflare será agent infrastructure. E faz sentido.

Agentes de IA precisam de exatamente o que Durable Objects oferecem:

• Estado persistente: um agente precisa lembrar do contexto entre chamadas
• Single-threaded execution: evita race conditions quando o agente manipula estado
• WebSockets: comunicação bidirecional em tempo real com o usuário
• Baixa latência: edge computing coloca o agente perto do usuário

O modelo “um Durable Object por agente” é natural. Cada agente tem seu próprio mini-servidor stateful na edge, com SQLite local para memória rápida e S3 para persistência de longo prazo.

Com o CellD integrado ao workerd, você pode rodar esses agentes tanto na Cloudflare quanto na sua própria infra. Um cluster de GPUs on-premise rodando inference + CellD pra orquestração dos agentes. Ou tudo na Cloudflare se você preferir não gerenciar nada.

A jogada estratégica da Cloudflare

Vamos dar um passo atrás e olhar o tabuleiro.

A Cloudflare está jogando o jogo do Kubernetes. Quando o Google abriu o Kubernetes, parecia loucura: dar de graça a tecnologia que rodava o Google internamente. Mas o resultado foi que Kubernetes virou o padrão, e o Google Cloud (com GKE) capturou uma fatia enorme do mercado de orquestração.

A Cloudflare está fazendo a mesma coisa com Workers + Durable Objects:

1. Abriu o workerd (o runtime) como open source
2. Comprou o CellD (a coordenação distribuída) e vai mergear no workerd
3. Resultado: qualquer um pode rodar Workers + Durable Objects em qualquer lugar

O modelo de programação vira o padrão. E quando empresas querem a versão managed, sem dor de cabeça, vão pra Cloudflare. É a mesma dinâmica do Redis (open source) vs Redis Cloud (managed).

Para a Vercel, AWS Lambda e outros players de serverless, isso é preocupante. A Cloudflare está oferecendo algo que ninguém mais tem: serverless stateful portátil. Lambda não tem equivalente a Durable Objects. Vercel roda sobre Lambda. Nenhum dos dois compete nesse nível de abstração.

Como migrar do Deno: guia prático

Se você precisa migrar, aqui vai um resumo das suas opções.

Opção 1: Deno → Cloudflare Workers

A migração mais natural se você já usa Deno Deploy.

// Antes (Deno)
Deno.serve({ port: 8000 }, (req) => {
  return new Response("Hello from Deno");
});

// Depois (Cloudflare Workers)
export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    return new Response("Hello from Workers");
  }
};

Para módulos NPM, o Workers suporta node_modules via compatibilidade Node.js:

// wrangler.toml
compatibility_flags = ["nodejs_compat_v2"]

// worker.ts
import { createClient } from "@supabase/supabase-js";

Opção 2: Deno → Node.js

Se você quer sair de runtimes proprietários:

// Antes (Deno)
const text = await Deno.readTextFile("./data.json");

// Depois (Node.js)
import { readFile } from "node:fs/promises";
const text = await readFile("./data.json", "utf-8");

O maior trabalho será substituir APIs específicas do Deno (Deno.serve, Deno.readFile, Deno.env.get) pelos equivalentes do Node.

Opção 3: Deno → Bun

Bun tem alta compatibilidade com APIs do Node e performance superior. Se performance era o motivo do Deno, Bun é a transição mais direta.

// Bun serve (similar ao Deno.serve)
Bun.serve({
  port: 8000,
  fetch(req) {
    return new Response("Hello from Bun");
  },
});

Opção 4: Forkar o Deno

Tecnicamente possível (código é MIT). Mas manter um runtime JavaScript completo exige um time dedicado. A não ser que uma fundação ou empresa grande assuma, um fork comunitário tende a morrer em meses.

O ciclo de Ryan Dahl

Tem algo quase poético na trajetória do Ryan Dahl.

2009: cria o Node.js. Revoluciona o backend JavaScript. Sai do projeto em 2012.

2018: apresenta “10 Things I Regret About Node.js” na JSConf EU. Anuncia o Deno como a correção de tudo que errou. TypeScript nativo, permissões granulares, sem node_modules, sem package.json, URLs como imports.

2020-2025: Deno evolui. Deno Deploy lança. JSR (JavaScript Registry) tenta substituir o npm. A adoção cresce, mas nunca atinge massa crítica. O Node.js continua dominante. O Bun aparece e rouba parte do hype.

2026: Deno é vendido pra Cloudflare. O runtime será descontinuado. Ryan vai trabalhar em infra para agentes de IA.

Cada capítulo faz sentido isoladamente. Mas juntos, eles contam a história de como é difícil desbancar um ecossistema estabelecido, mesmo quando você é literalmente a pessoa que o criou.

O que fica e o que morre

Fica:

• O modelo de programação Workers/Durable Objects (agora portátil)
• JSR como registry TypeScript-first
• rusty_v8 como binding Rust para V8
• A ideia de que serverless pode ser stateful

Morre:

• Deno como runtime independente
• Deno Deploy como plataforma
• A promessa de “Node.js feito direito”
• A ilusão de que um novo runtime pode substituir o Node em escala

Pra quem apostou no Deno como stack principal: meus pêsames. Pra quem está construindo com Workers ou pensando em agentes de IA stateful: o futuro ficou mais interessante. O CellD dentro do workerd é genuinamente uma mudança de paradigma para serverless. Poder rodar Durable Objects em qualquer lugar, com custo 88% menor, usando S3 como coordenador distribuído? Isso é o tipo de inovação que justifica uma aquisição.

Ryan Dahl pode não ter vencido a guerra dos runtimes. Mas o CellD pode vencer a guerra do serverless.

Fonte de inspiração: Deno is joining Cloudflare