~ / freestyle-team ❯ Cloudflare Sandbox vs. VMs for AI Agents
Cloudflare Sandbox SDK and VM-based agent infrastructure solve related problems, but they are not the same bet.
Cloudflare Sandbox SDK is a Workers-native way to run untrusted code in isolated environments. It is built on Cloudflare Containers, managed through Durable Objects, and exposed through a TypeScript API for commands, files, processes, ports, browser terminals, and code interpreter workflows.
That is a strong product if your application already lives on Cloudflare and the workload is naturally request-shaped: run code, inspect output, expose a preview, maybe keep a container warm while the user is active.
But many AI agent products are not request-shaped. They are machine-shaped. A coding agent, app builder, browser agent, or long-running research agent wants a real workspace that can install packages, run services, keep terminals alive, preserve state between turns, expose traffic, survive disconnects, and fork when the agent needs to try alternatives.
That is where Freestyle VMs fit. Freestyle VMs are the most powerful VMs for AI agents: they are hardware virtualized, they can run forever when configured to stay running, and they run real Linux rather than a narrow command sandbox.
The core difference
Cloudflare starts from the Worker. Your application code calls getSandbox(), a Durable Object manages lifecycle and routing, and a container runs the untrusted code. Cloudflare's own architecture docs describe that three-layer model: Workers, Durable Objects, and Containers.
Freestyle starts from the machine. The API creates a full Linux VM, and the rest of the product builds around that VM as the durable runtime object. The Freestyle VM docs describe VMs as full Linux virtual machines for long-running, complex tasks that can be started by API calls, SSH, or network activity.
That distinction sounds abstract until you design the product lifecycle.
If the agent is doing a short task, a container sandbox is a clean fit. If the agent is operating a workspace that users return to, debug, share, preview, and branch, the VM model is simpler. The runtime itself becomes product state.
Cloudflare Sandbox is good at edge-native execution
Cloudflare Sandbox SDK is compelling when your app is already a Cloudflare Workers app.
The docs show APIs for executing commands, managing files, running background processes, exposing services, connecting browser terminals, and using code interpreter contexts. The container runtime docs describe an isolated Linux container with Python, Node.js, common development tools, runtime package installation through package managers, a standard Linux filesystem, background processes, and port exposure.
That is a useful shape for AI code execution. You can build a code interpreter, run generated Python, start a Node app, expose a preview URL, and stream output back through a Worker. Cloudflare also has a clear story for edge routing: sandbox identity is tied to a Durable Object, and incoming requests can be routed to the right sandbox.
If your product is a Workers application that needs controlled execution close to Cloudflare's platform, Sandbox SDK is worth evaluating.
The state model is the deciding factor
The important comparison is not "container versus VM" in the abstract. It is what happens after the user goes away.
Cloudflare's sandbox lifecycle docs say sandbox state remains available while the container is active: files, running processes, shell sessions, and environment variables. After inactivity, the container stops by default, a fresh container starts on the next request, and previous state is lost. Cloudflare provides keepAlive to prevent automatic sleep, but its lifecycle API docs also warn that keep-alive containers need explicit management so they do not run indefinitely.
That model is reasonable for many workloads. It is not the same as a VM that can be treated as the workspace.
Freestyle VMs are built to be controlled as durable runtime objects. The VM lifecycle docs expose running, stopped, forked, and deleted states. Stopping preserves disk. Starting brings the VM back. Setting idleTimeoutSeconds to null keeps a workload running until you stop or delete it. Forking creates a new VM from the current running state so an agent can explore multiple paths from the same environment.
For agents, that difference matters because state is not just files. It is also processes, terminals, caches, servers, logs, sockets, browser sessions, and the half-finished debugging context the agent will need ten minutes later.
Long-running agents need a workspace, not just a warm container
A serious coding agent does not only call exec("npm test").
It clones a repo, installs dependencies, starts a dev server, tails logs, opens a terminal, modifies files, re-runs tests, serves a preview, debugs a failing process, asks the model for the next step, and then resumes from the same context later. Sometimes it needs to keep working while the user closes the tab. Sometimes it needs to hand the workspace to a human. Sometimes it needs to branch the whole environment and compare approaches.
Cloudflare Sandbox can run background processes and expose services. For request-native products, that may be enough.
Freestyle is stronger when the workspace is the product. A Freestyle VM can run the app, database, worker, test runner, browser, terminal, and agent loop in the same Linux environment. It can be accessed over SSH through scoped identity tokens, as described in the Freestyle SSH docs. It can route HTTPS traffic from a custom domain to a port inside the VM through VM domain mappings. It can keep interactive shell sessions alive through persistent PTYs that survive disconnects, VM suspends, and VM forks.
Those are not convenience features. They are what make the agent workspace feel like infrastructure instead of a one-off execution cell.
Forking is the agent-native primitive
Agents are increasingly parallel. When a model is uncertain, the best product pattern is often to fork the workspace, try multiple approaches, and compare results.
That is awkward if your only durable unit is a container session whose state disappears after inactivity. You can rebuild from an image, restore files, or replay setup scripts, but that is not the same as cloning the current running context at the decision point.
Freestyle's lifecycle model includes forking a running VM. A fork starts from the current environment, so each child can diverge independently. The PTY docs go further: non-exited PTY sessions are inherited by forks under the same session ID, seeded with the at-fork screen, and output diverges per child.
That is the shape agents want. They do not only need to run more jobs. They need to branch a live workspace with all the boring state that made the current moment meaningful.
When the agent is editing code, you should also store important source state in a reviewable system. Freestyle VMs work well with Freestyle Git repositories, so the machine can run the work while Git remains the durable record for files, branches, diffs, and review.
Where Cloudflare is the right choice
Choose Cloudflare Sandbox SDK if the sandbox is an extension of a Cloudflare Workers application.
That is especially true when you want TypeScript-first control from Workers, Durable Object identity, Cloudflare routing, code interpreter workflows, short-lived task sandboxes, or execution close to the rest of your Cloudflare stack. The product has good primitives for commands, files, sessions, ports, tunnels, terminals, and runtime package installation.
It is also a good fit when losing runtime state after inactivity is acceptable, or when your application already has a clear rebuild and restore path.
Where VMs are the better fit
Choose Freestyle when the environment itself is part of the user experience.
Use Freestyle for AI coding agents, app builders, browser agents, hosted development environments, persistent code interpreters, multi-service workspaces, or long-running agents where state should be explicit rather than accidental.
The VM model wins when you need:
- real Linux behavior instead of a provider-specific execution cell
- long-running processes that can run forever when configured that way
- SSH and editor access for support, debugging, and handoff
- custom domain routing to services inside the workspace
- persistent interactive terminals with reconnect
- running-state fork for parallel agent exploration
- a clear boundary between runtime state in the VM and source state in Git
Those are the requirements that show up after the demo, once users start treating the agent environment like a real workspace.
The bottom line
Cloudflare Sandbox SDK is a strong edge-native sandbox for Workers applications. It is especially attractive when code execution is a feature inside a Cloudflare product.
But the best infrastructure for serious AI agents is still a real computer. Agents need package managers, terminals, services, files, ports, SSH, long-running state, and the ability to branch a live environment. They need the operating system as the interface.
If your product needs short-lived execution from Workers, Cloudflare Sandbox may be the right fit. If your product needs a durable, inspectable, forkable Linux workspace for agents and users, start with Freestyle VMs.
