A Cloudflare lançou a Dynamic Worker Loader API

Há uma diferença fundamental entre um agente que chama ferramentas e um agente que escreve programas. O segundo está se tornando padrão: LLMs gerando JavaScript para consumir APIs, manipular dados, encadear lógicas complexas em runtime. E aí está o nó.

Executar esse código gerado dinamicamente dentro da sua aplicação host, via eval() ou qualquer variante, é uma porta aberta para injeção, vazamento de credenciais e comprometimento do ambiente inteiro. A pergunta deixa de ser “como meu agente é inteligente?” e passa a ser “onde diabos eu executo o que ele gera com segurança?”

Containers Linux resolvem, mas cobram um preço alto

A resposta tradicional é isolar cargas de trabalho em containers Linux. Funciona, mas o modelo tem um custo que poucos falam abertamente:

• Latência de inicialização: centenas de milissegundos por container

• Footprint de memória: centenas de megabytes por instância

• Reutilização forçada: para evitar esse custo, operadores mantêm pools de containers e os reutilizam entre tarefas diferentes, o que degrada exatamente a propriedade que você queria garantir: o isolamento

Quando você precisa suportar dezenas de agentes ativos por usuário, cada um gerando e executando código sob demanda, essa arquitetura simplesmente não escala.

A aposta da Cloudflare: sandboxes V8 em vez de containers

Motores JavaScript como o V8, o mesmo que roda no Chrome, inicializam em milissegundos e consomem apenas alguns megabytes de memória. A Cloudflare lançou a Dynamic Worker Loader API exatamente para transformar essa característica em primitiva de infraestrutura.

Em vez de provisionar containers, você instancia um novo sandbox contendo lógica arbitrária em runtime, por requisição. Cada chamada ganha seu próprio espaço de execução isolado. As instâncias rodam em paralelo sem os limites de concorrência ou taxas de criação que travam soluções baseadas em containers.

O resultado prático: aproximadamente 100x mais rápido e 10-100x mais eficiente em memória que um container padrão.

O problema das credenciais: seu agente não precisa saber os segredos

Isolar a execução resolve metade do problema. A outra metade é: como esse código isolado acessa serviços externos sem que as credenciais vazem?

A resposta da API é a opção globalOutbound. Ela permite injetar credenciais nas requisições de saída do sandbox sem expô-las ao código que está sendo executado. A lógica gerada pelo LLM chama serviços como se tivesse acesso, mas nunca toca nas chaves reais.

O padrão recomendado é usar TypeScript para descrever as interfaces disponíveis ao sandbox, uma bridge RPC tipada que expõe exatamente o que o agente pode fazer, nada além. Isso é mais conciso que OpenAPI e consome menos tokens de contexto, dois problemas que quem trabalha com agentes em produção conhece bem.

Estado entre execuções: sistemas de arquivos virtuais e persistência transacional

Agentes que fazem mais de uma coisa precisam de estado. A arquitetura suporta sistemas de arquivos virtuais que permitem leitura, escrita e manipulação de dados entre execuções separadas, com suporte de armazenamento via SQLite e R2.

O detalhe que importa para produção: gravações em lote funcionam de forma transacional por padrão, se algo falhar durante a execução, as escritas anteriores são revertidas automaticamente. Sem estado corrompido no meio do caminho.

Quem está usando isso em produção?

A Zite, uma plataforma onde usuários constroem aplicativos CRUD via interface de chat, adotou Dynamic Workers como camada de execução para o código gerado pelos seus LLMs. O requisito era direto: execução instantânea, isolada e segura. Segundo Antony Toron, CTO da empresa, a plataforma atende hoje milhões de requisições de execução por dia, com compatibilidade com o ecossistema Node.js e suporte a centenas de integrações com terceiros.

O que observar antes de adotar

Sandboxes V8 têm uma superfície de ataque diferente de containers. Proteger esses ambientes exige defesa em profundidade: patches de segurança rápidos, sandboxing customizado em segunda camada, proteção de memória em nível de hardware e defesas contra ataques de canal lateral como Spectre.

Não é complexidade que deve assustar, é complexidade que deve estar no radar de quem desenha a arquitetura.

Quanto ao custo: US$ 0,002 por Worker carregado único por dia. Comparado ao custo de inferência que domina a fatura de qualquer sistema com LLM, é irrelevante.

Quando vale a pena trocar containers por sandboxes

A regra de ouro é simples: se suas tarefas são curtas, simultâneas e geradas dinamicamente, a latência baixa dos sandboxes V8 vai fazer diferença real. Se você está reutilizando containers entre tarefas para economizar no tempo de inicialização, você já está comprometendo o isolamento que justificou os containers em primeiro lugar, esse é o sinal mais claro de que vale revisar a arquitetura.

A Dynamic Worker Loader API está em beta aberto para usuários pagos da Cloudflare.