Cloudflare reformula o Containers para agentes de IA: início 6 vezes mais rápido

A Cloudflare reformulou a infraestrutura do Containers para a carga gerada por agentes de IA: as sandboxes surgem sob demanda, uma para cada tarefa, e precisam estar prontas de imediato. No benchmark independente ComputeSDK, o tempo mediano de início caiu de 4,049 segundos para 648 milissegundos (6,2 vezes menos). No teste preliminar da própria empresa, uma única conta iniciou 100 000 contêineres em 5,387 segundos, em seis localidades. Junto com isso, chegaram a escolha de imagem e de recursos direto pelo código e os snapshots do sistema de arquivos, em beta público.

Imagem e hardware são escolhidos pelo código, não pelo deploy

Antes, o Containers era organizado em torno da aplicação: imagem e recursos computacionais eram definidos no deploy e distribuídos de forma centralizada. Para uma sandbox de agente, isso é pouco prático. Ela precisa de ferramentas, volume de recursos e arquivos iniciais diferentes conforme a tarefa, e pode viver por minutos, "dormir" entre requisições ou ser restaurada depois de vários dias.

O modelo antigo exigia, para cada combinação de imagem e tipo de instância, uma aplicação separada, um namespace próprio de Durable Objects e o roteamento em um Worker. Uma sandbox pequena com Node.js e um ambiente grande em Python para builds significavam dois deploys. A nova política de agendamento `durable_object` transforma isso em uma condição `if`: na configuração do wrangler, declaram-se as imagens disponíveis (por exemplo, node e python), e o Durable Object, ao iniciar, passa para `ctx.container.start()` a imagem, o tipo de instância (digamos, standard-1 ou standard-2) e a flag de acesso à internet. Um novo ambiente passa a surgir com uma alteração de código, e não com um novo deploy.

O mesmo vale para a distribuição de atualizações. Grace periods, splits percentuais e chamadas à API de configuração saem de cena: o contêiner continua rodando na imagem com a qual foi iniciado até que o código o interrompa, e a execução seguinte usa a imagem que o código escolher. Disso resultam canary releases para 5% das novas sandboxes com base no hash do ID do Durable Object, fixação de projetos ativos na imagem atual, migração em um checkpoint e rollback simplesmente trocando a imagem das próximas execuções.

Por que o primeiro comando roda mais rápido

Antes, o início de um contêiner passava por um plano de controle global, que processava a configuração da aplicação, procurava capacidade e coordenava o posicionamento. Agora a demanda surge no nível do Durable Object. A infraestrutura primeiro procura espaço na mesma máquina, depois amplia a busca dentro da localidade e dá prioridade aos hosts em que a imagem ou o snapshot já estão armazenados localmente.

Depois que o contêiner chega ao host, também foi cortado o que era desnecessário: em vez de inicializar uma máquina virtual do zero, o ambiente de execução restaura uma VM previamente preparada e ainda não atribuída, reaproveita a configuração de rede e do sistema de arquivos, agrupa operações repetitivas e não espera por serviços de que o primeiro comando não precisa. Resultados do benchmark Burst TTI (100 sandboxes simultâneas, medição no lado do cliente):

• mediana: 4,049 s → 648 ms (6,2 vezes mais rápido); • percentil 95: 5,839 s → 910 ms (6,4 vezes); • percentil 99: 6,717 s → 1129 ms (5,9 vezes).

Separadamente, a Cloudflare lançou a imagem `cloudflare/debian-trixie`, com Debian Trixie Slim e Node.js 24.20.0 LTS. O agente pode iniciar uma sandbox Linux sem Dockerfile, sem build e sem push de imagem, e depois clonar um repositório e instalar pacotes via `exec()`. Como a imagem é controlada pela própria Cloudflare, ela é distribuída antecipadamente pelos hosts adequados, e nada é baixado nem descompactado na inicialização.

Snapshots: salvar o espaço de trabalho e voltar a ele

Mesmo um início rápido não elimina a etapa de configuração: clonar repositórios, instalar dependências e configurar a toolchain muitas vezes levam mais tempo do que iniciar o contêiner em si. Para resolver isso, os snapshots nativos do sistema de arquivos entraram em beta público. O método `snapshotContainer()` salva o espaço de trabalho, e `start()` com o parâmetro `containerSnapshot` o restaura.

Os snapshots são imutáveis e reutilizáveis, por isso funcionam em dois cenários. O primeiro: um mesmo espaço de trabalho continua entre sessões. Um agente de código salva o repositório, as dependências, os caches de build e as alterações quando o usuário sai, e os restaura no dia seguinte.

O segundo: um checkpoint comum para várias sandboxes. Isso é útil na avaliação de agentes, quando a mesma tarefa é executada com diferentes system prompts, skills, modelos ou versões do agente, e todo o resto precisa permanecer igual. Um único snapshot inicia vários ambientes isolados com a mesma base e elimina a deriva do ambiente nos resultados.

O encadeamento também funciona: o agente parte do debian-trixie, configura o ambiente via `exec()` e salva o resultado como snapshot.

Para quem isso é útil

Os cenários para os quais a plataforma foi reformulada são: agentes de código com repositórios, gerenciadores de pacotes, compiladores e servidores de desenvolvimento; evals com estado inicial conhecido; sistemas de aprendizado por reforço que criam, avaliam e reiniciam um grande número de ambientes; e tarefas longas em que é preciso preservar arquivos.

A Base44 (ambiente de desenvolvimento isolado para cada aplicativo, com preview ao vivo) e a Kilo Code (ambiente separado para cada sessão de agente na nuvem) já constroem seus produtos sobre o Containers. Há integrações com Cursor Cloud Agents, Devin Outposts, OpenAI Agents API e Claude Managed Agents. O modelo também chega ao Sandbox SDK 1.0, e a API nativa `ctx.container` ganha mais recursos para que o Durable Object gerencie o contêiner sem uma classe wrapper.

Para equipes que desenvolvem produtos com agentes, a conclusão prática é esta: se você mantém aplicações separadas para cada stack, é possível consolidá-las em uma única classe Durable Object com escolha da imagem em runtime. Para evals e RL, vale montar um snapshot de referência e executar rodadas paralelas a partir dele. Para sessões de longa duração, serve o par "snapshot ao pausar, restauração ao retornar". Os números dos 100 000 contêineres são preliminares, então é melhor validar a carga real com o seu próprio perfil de uso.