Comparativo de sandboxes do Puppyone: Docker vs Cloudflare — qual encaixa no seu agente de IA?
23 de abril de 2026Guanqun @puppyone
Quando você roda agentes de IA em produção, isolamento não é opcional. Agentes executam código, mexem no sistema de arquivos e chamam serviços externos — e sem uma sandbox de verdade, uma única saída ruim pode causar um estrago difícil de desfazer.
O Puppyone oferece dois ambientes de sandbox distintos para cargas de trabalho distintas: uma sandbox baseada em Docker para execução completa e flexível, e uma sandbox baseada em Cloudflare para cargas rápidas, leves e distribuídas globalmente. Este artigo destrincha o que é cada uma, onde elas diferem e como escolher a certa.
O que é uma sandbox?
Uma sandbox é um ambiente de execução isolado em que tudo o que o agente faz — rodar código, mexer em arquivos, chamar ferramentas — fica contido e sob controle. Uma boa sandbox impõe limites claros:
- O que o agente pode ler e escrever
- Quais chamadas de rede ele pode fazer
- Quanto de CPU e memória pode consumir
- Quanto tempo pode rodar antes de ser encerrado
Os dois tipos de sandbox impõem esses limites. O interessante é como eles impõem — e quais trade-offs cada caminho carrega.
Sandbox Docker vs sandbox Cloudflare: a diferença que importa
O comparativo todo cabe em uma frase: a sandbox Docker entrega uma máquina Linux inteira; a sandbox Cloudflare entrega um slot pra rodar JavaScript.
A sandbox Docker é construída sobre containers. Cada sandbox é, na prática, o seu próprio servidor Linux — você instala pacotes (apt install, pip install), roda qualquer runtime (Python, Node, Go), abre subprocessos, lê e escreve em um sistema de arquivos real, e deixa tarefas rodando por horas. O preço: cold start de vários segundos, e cada sandbox queima CPU e memória reais enquanto existe.
A sandbox Cloudflare é construída sobre V8 Isolates — o mesmo modelo de isolamento que o Chrome usa pra separar abas do navegador. Ela só roda JavaScript / WebAssembly: nada de instalar pacotes, nada de subprocessos, nada de sistema de arquivos local, e uma execução geralmente é cortada em 30 segundos de CPU. Em troca, sobe a frio em menos de 5 milissegundos, empilha milhares de isolates em uma única máquina e roda automaticamente nas mais de 300 localidades de edge globais da Cloudflare.
| O que você quer fazer | Escolha |
|---|---|
| Rodar scripts em Python, instalar bibliotecas, processar dados | Docker |
Deixar o agente editar arquivos, gerar relatórios, rodar git | Docker |
| Tarefas que duram de minutos a horas | Docker |
| Responder a uma requisição em milissegundos | Cloudflare |
| Lógica JavaScript de alta concorrência (roteamento, transformação, filtragem) | Cloudflare |
| Executar perto de usuários em várias regiões | Cloudflare |
A seguir, abrimos cada uma em detalhes.
A sandbox baseada em Docker
Como funciona
Cada tarefa do agente roda dentro do próprio container — um ambiente Linux isolado do host por namespaces e cgroups. Quando uma tarefa chega, o Puppyone sobe um container novo a partir de uma imagem pré-construída, monta os inputs, aloca um diretório de trabalho e aplica as cotas de recursos. Quando a tarefa termina, o container inteiro é destruído. Toda execução começa de um estado limpo conhecido — sem processos, arquivos ou variáveis de ambiente sobrando da execução anterior.
O que você ganha
Imagens customizáveis. A imagem base padrão é Ubuntu com Python, Node, Git e curl pré-instalados. Se isso não basta, traz seu próprio Dockerfile — o Puppyone suporta as instruções padrão (FROM, RUN, COPY, WORKDIR, ENV) — e empacota nele os runtimes, ferramentas de CLI ou dependências internas que o seu time precisa. O agente já sobe direto em um ambiente moldado pro seu workflow.
Recursos configuráveis. Por padrão, 2 vCPUs e 512 MB de RAM, escaláveis por tarefa até 8 vCPUs e 8 GB. Se uma sandbox estourar a memória, o container é morto de forma limpa — o host fica intocado.
Duração controlada. O timeout padrão é de 5 minutos por tarefa, configurável até 24 horas. Para workflows mais longos, a sandbox suporta pause / resume — sistema de arquivos e estado da memória são salvos como snapshot na pausa e restaurados no resume, então você não paga pra subir tudo do zero de novo.
Controle fino de tráfego de saída. Todo tráfego de saída é bloqueado por padrão. Você declara explicitamente quais domínios ou portas o agente pode alcançar (por exemplo api.openai.com, *.github.com) — todo o resto é negado. É assim que se evita que um agente comprometido por prompt injection vaze dados sem ninguém perceber.
Workspace plugado direto no seu sistema de arquivos. Cada sandbox monta um namespace dentro do sistema de arquivos do Puppyone — não é diretório temporário descartável. Quando o agente escreve um arquivo dentro do container, ele está, na prática, fazendo um commit no Puppyone: versionado, com permissões e auditável. Dá pra fazer rollback, repassar pra outro agente ou rastrear até a tarefa e o passo exatos que produziram aquilo.
Cobrança pelo tempo de vida do container. Você paga por cada segundo em que o container existe, esteja a CPU fazendo algo ou não. Isso premia o padrão "sobe e destrói": começa a tarefa, termina e mata o container. Se o agente passa a maior parte do tempo esperando resposta de LLM ou input do usuário, você está pagando por essa espera também.
Quando não é a melhor escolha
- Caminhos de resposta abaixo de 100 ms (cold starts são em segundos, não em milissegundos)
- Milhares de requisições independentes por segundo (cada container custa recursos reais)
- Algumas linhas de lógica leve em JavaScript (overkill)
Quando é
- Scripts de Python / Node / shell que mexem em arquivos, usam bibliotecas ou geram artefatos
- Workflows de várias etapas em que cada passo se apoia no workspace do anterior
- Qualquer coisa que precise instalar pacotes, compilar código ou chamar utilitários do sistema
- Resumindo: qualquer coisa que realmente precise de uma máquina
Como o Puppyone suporta
A sandbox Docker do Puppyone é compatível em API com o E2B — se o seu agente já roda em E2B, dá pra apontar pra Puppyone sem mudar nada na lógica de negócio. Sandbox.create(), runCode(), commands.run(), I/O de arquivos — tudo se mapeia direto. O ganho extra é que sandbox e sistema de arquivos viram uma coisa só. Você não precisa mais administrar a corrente chata de "arquivos na sandbox → persiste em object storage → sincroniza pra próxima sandbox". Cada escrita cai no sistema de arquivos do Puppyone com histórico de versões, permissões e logs de auditoria — o mesmo estado, visível entre tarefas, agentes e até tipos de sandbox.
A sandbox baseada em Cloudflare
Como funciona
O código do agente roda dentro de um V8 Isolate na rede edge global da Cloudflare — a mesma tecnologia que o Chrome usa pra isolar abas do navegador. Cada isolate é um contexto de execução JavaScript fechado, que sobe em milissegundos (não tem sistema operacional pra bootar) e é destruído quando a requisição termina. As requisições são roteadas para a localidade de edge mais próxima do usuário, mantendo a latência de ida e volta na casa das dezenas de milissegundos.
O que você ganha
Cold starts em milissegundos. Um isolate sobe em menos de 5 ms — algo como três ordens de grandeza mais rápido do que um container. Dá pra se dar ao luxo de subir uma sandbox nova a cada requisição, sem warm pool nem instâncias permanentes.
Só JavaScript / WebAssembly. Nada de Python, nada de shell, nada de binários nativos. Sua lógica é JS/TS ou compila pra WASM. A maior parte dos built-ins do Node.js está disponível, mas tudo o que depende de syscalls (fs, child_process, extensões C nativas) não está.
Teto de 128 MB de memória, 30 segundos de CPU por requisição. Cada requisição recebe no máximo 128 MB de memória e 30 segundos de CPU (configurável até 5 minutos em planos pagos). Importante: só conta o tempo ativo de CPU — o tempo esperando um fetch() ou uma consulta a banco não entra na conta, então uma requisição limitada a 30 segundos de CPU pode ficar aberta por vários minutos no relógio.
Sem sistema de arquivos local. Isolates são sem estado. O que precisa persistir vai pra storage externo — Cloudflare KV, R2, D1, ou seu próprio banco. Pra compartilhar estado intermediário entre requisições, você serializa, escreve fora e lê de volta, ou põe um serviço com estado separado na frente.
Execução global no edge + autoscaling. O seu código é distribuído automaticamente pelas mais de 300 localidades de edge da Cloudflare e roda na mais próxima do usuário. De zero a dezenas de milhares de QPS sem você planejar capacidade — a plataforma cuida disso.
A camada de segurança da Cloudflare vem de brinde. Proteção contra DDoS, rate limiting, gestão de bots e terminação TLS estão embutidas na rede. Você não precisa subir uma camada à parte pra nada disso.
Cobrança apenas em milissegundos ativos de CPU. Quando o isolate está esperando um fetch(), um banco ou um evento de usuário, você não paga. A cobrança é só pelos milissegundos em que o V8 está de fato executando código. Em cargas dominadas por I/O — como agentes que basicamente chamam LLMs e agregam respostas de APIs — o custo do tempo de espera é praticamente zero.
Quando não é a melhor escolha
- Tarefas que precisem instalar pacotes, rodar Python / shell ou executar binários nativos
- Cargas de uma requisição só que precisem de mais do que alguns minutos de CPU
- Workflows que leem ou escrevem arquivos locais, ou mantêm estado entre requisições dentro da sandbox
- Tarefas pesadas em memória que passem de 128 MB
Quando é
- Requisições de alta concorrência e curta duração (parsing, transformação, filtragem, roteamento)
- Atuar como "porta de entrada" do agente — decidir rápido, extrair parâmetros, escolher a próxima ferramenta a chamar
- Serviços globalmente distribuídos e de baixa latência (gateways de API inteligentes, RAG no edge)
- Código de cola que liga as primitivas da Cloudflare (KV, R2, D1, Queues)
Como o Puppyone suporta
A sandbox Cloudflare está em desenvolvimento e ainda não foi liberada publicamente. Estamos plugando ela ao sistema de arquivos do Puppyone do mesmo jeito que a sandbox Docker: quando o código JS dentro de um isolate "escreve um arquivo", isso vira um commit versionado, com permissões e auditável no Puppyone — e divide estado com a sandbox Docker. O mesmo agente vai conseguir rodar processamento pesado em uma sandbox Docker e responder no edge em uma sandbox Cloudflare, com os dois lados olhando pro mesmo workspace.
Se o seu caso de uso pede execução no edge, se inscreva pra receber novidades — a gente avisa assim que estiver disponível.
Lado a lado
Uma visão condensada de tudo o que foi visto acima, em uma tabela que dá pra varrer rápido.
| Dimensão | Sandbox Docker | Sandbox Cloudflare |
|---|---|---|
| Tecnologia base | Containers Linux (namespaces + cgroups) | V8 Isolates |
| Cold start | 2-10 segundos | < 5 milissegundos |
| Runtime | Python, Node, Go, shell — qualquer binário Linux | JavaScript / TypeScript / WebAssembly |
| Instalar pacotes? | ✅ apt, pip, npm, Dockerfile próprio | ❌ Tem que vir empacotado antes |
| Subprocessos? | ✅ | ❌ |
| Sistema de arquivos local | ✅ POSIX completo, montado no Puppyone | ❌ Só storage externo (KV / R2 / D1) |
| Recursos padrão | 2 vCPU + 512 MB | 128 MB de memória |
| Teto de recursos | 8 vCPU + 8 GB (configurável) | 128 MB (fixo) |
| Duração por execução | 5 min padrão, até 24 horas | 30 s CPU padrão, até 5 min (pago) |
| Preservação de estado | Snapshots pause / resume (memória + FS) | Nenhuma (cada requisição, isolate novo) |
| Modelo de concorrência | Um container por sandbox (recursos reais) | Milhares de isolates por máquina |
| Distribuição geográfica | Uma região | 300+ localidades de edge, roteamento automático |
| Controle de saída | Allowlist de domínios/portas | Configurado via Workers |
| Camada de segurança | Você sobe a sua | DDoS / rate limit / bot / TLS embutidos |
| Granularidade da cobrança | Por segundo de vida do container (espera incluída) | Por milissegundo ativo de CPU (espera não conta) |
| Modelo de processo | Sobe e destrói | Sob demanda, sem manutenção |
| Compatibilidade de API | Compatível com E2B | API do Cloudflare Workers |
| Status no Puppyone | ✅ Disponível | 🚧 Em desenvolvimento, ainda não aberta |
| Casos típicos | Processamento de dados de 5 min, Python com pacotes, workflows de várias etapas | Roteamento em milissegundos, lógica JS de alta concorrência, APIs no edge |
| Um agente de 10 minutos — qual? | Docker, se ele estiver computando de verdade | Cloudflare, se estiver passando 90 % do tempo esperando LLMs/APIs |
Como escolher
Escolher uma sandbox não é decidir qual é "melhor" — é olhar honestamente como a sua carga de trabalho realmente se parece. As cinco dimensões abaixo cobrem quase todas as decisões reais.
1. Linguagem do runtime
Se o seu agente precisa rodar Python, shell, Go ou binários nativos (pense em ffmpeg, pandoc, git) — tem que ser Docker. A Cloudflare só roda JavaScript / TypeScript / WebAssembly. Você nem consegue dar pip install.
Se a sua lógica de negócio já é JS / TS e não toca em syscalls — qualquer uma serve. Continue lendo.
2. Duração da tarefa
| Duração da tarefa | Escolha | Por quê |
|---|---|---|
| < 30 s de CPU | Cloudflare | Início em milissegundos + cobrança por ms — disparado o mais barato |
| 30 s - 5 min de CPU | Cloudflare (planos pagos vão até 5 min) | Ainda dentro do limite |
| Vários minutos a horas | Docker | Cloudflare bate no teto de CPU |
| Workflows de vários dias | Docker + snapshots pause / resume | Congela o estado e retoma depois |
3. Estrutura de custo (a dimensão que mais erram)
Os dois modelos de cobrança são genuinamente diferentes — a mesma carga pode custar uma ordem de grandeza a mais se você escolher errado.
- Docker cobra pelo tempo em que o container existe. O contador começa quando o container sobe, esteja a CPU fazendo algo ou não. Isso premia trabalho curto e denso: começa a tarefa, termina, mata o container. Se você deixar um container ocioso esperando input do usuário ou resposta de LLM, está pagando por essa espera.
- Cloudflare cobra só por milissegundos ativos de CPU. Quando o isolate está esperando um
fetch(), um banco ou uma resposta de LLM em streaming, você não paga. Só são cobrados os milissegundos em que o V8 está executando código.
Em concreto:
- Uma tarefa de processamento de dados de 5 minutos (CPU no talo o tempo todo) → Docker é mais barato
- 10.000 usuários por segundo, cada um disparando 50 ms de lógica → Cloudflare é ordens de grandeza mais barata
- Um agente de 30 minutos que passa 90 % do tempo esperando streams de LLM → Cloudflare é dramaticamente mais barata; o Docker cobra os 30 minutos inteiros
Não compare preço por hora. Compare qual fração do tempo de relógio da sua carga é, de fato, computação. Essa razão decide qual modelo ganha.
4. Concorrência
- Algumas a algumas dezenas de requisições por segundo → qualquer uma serve
- Centenas por segundo de tarefas curtas → Cloudflare (milhares de isolates por máquina; o Docker exigiria um container por requisição concorrente)
- Poucas requisições por segundo, mas cada uma é um cálculo de vários minutos → Docker (a Cloudflare não aguenta esse tempo)
5. Volume de dados e estado
- Tarefas que leem ou escrevem muitos arquivos, geram artefatos de vários GB ou mantêm um workspace de várias etapas → Docker (sistema de arquivos real, montado no Puppyone, versionado automaticamente)
- Tarefas que só batem em algumas APIs, fazem transformações leves e gravam em storage externo → Cloudflare (sem FS local, mas ler KV / R2 / D1 é rápido)
- Mais de 128 MB de memória → Docker (um único isolate da Cloudflare bate em 128 MB)
Ainda na dúvida? Vai de Docker. As capacidades dele são um superconjunto estrito da Cloudflare — fica quase impossível errar; no máximo você paga um pouco mais em cenários extremos de altíssima concorrência ou muito intensivos em I/O. Quando o tráfego crescer a ponto de importar de verdade, dá pra mover os caminhos quentes pra Cloudflare nesse momento.
A arquitetura ideal, quando as sandboxes Cloudflare forem abertas: as duas trabalhando juntas. Sandboxes Cloudflare como porta de entrada do agente — roteamento em milissegundos, extração de parâmetros, decisões leves. Quando a carga realmente exige processamento pesado, ela é despachada pra uma sandbox Docker. A Cloudflare cuida do caminho rápido; o Docker, do trabalho pesado; o mesmo sistema de arquivos do Puppyone amarra as duas pontas.
Começando com sandboxes no Puppyone
Se o seu agente já está em E2B, basta apontar pro Puppyone — Sandbox.create(), runCode(), commands.run() são todos compatíveis em API, sem mudança na lógica de negócio, e você ganha de imediato versionamento, permissões e logs de auditoria no nível do sistema de arquivos.
Se você está começando do zero, a documentação do Puppyone tem um guia rápido que sobe uma sandbox com sistema de arquivos versionado em poucas linhas de código.
Precisa da sandbox edge da Cloudflare? Inscreva-se pra receber novidades — avisamos assim que estiver aberta.