A review of the adaptability of sandboxes

The easiest sandbox demo is also the least useful comparison. Give every provider a medium-sized machine, run a command, expose an HTTPS port, and they all look roughly interchangeable.

The differences appear when the workload refuses to stay average.

Can the sandbox be 128 MiB today and 64 GiB tomorrow? Can storage grow without buying more CPU? Can a running browser be checkpointed with its memory intact? Can the network start closed, admit one database and one webhook, then change policy without rebuilding the machine? Can you run a normal Linux service instead of fitting everything into a request handler?

That is adaptability: the amount a sandbox can change before your application has to change around it.

Across Freestyle, E2B, Blaxel, Daytona, Fly Sprites, Modal, exe.dev, and Boat.dev, adaptability comes down to four constraints:

1. How small and large a sandbox can be, and whether CPU, memory, and disk are tied together.
2. Whether its environment behaves like a general-purpose computer or a narrower execution runtime.
3. Whether networking is merely available or is actually configurable as policy.
4. Whether a snapshot saves a filesystem or the live computer, including memory and processes.

Adaptability has four axes

Small is a feature, not a consolation prize

Most sandbox comparisons obsess over the largest machine. The minimum is often more important.

An agent fleet can contain thousands of quiet environments: one shell waiting for approval, one repository between edits, one lightweight service accepting an occasional request. Giving every idle job 2 or 4 GiB because that is the smallest product shape is not flexibility. It is a tax on the provider's product model.

Freestyle has the best small full-computer story in this group. Its freestyle/busybox base snapshot is a hardware-virtualized Linux VM with 1 vCPU, 128 MiB of RAM, and 1 GB of disk. It is genuinely tiny: BusyBox, sh, no package manager, no libc, and no IDE support. That is the point. If the job is a small appliance, a webhook handler, a network utility, or a narrow agent tool, you do not have to boot Ubuntu and pay for a general developer image.

Modal defaults to a 128 MiB request, but its public docs do not establish that as a minimum or publish the maximum. Fly Sprites bill from a 256 MiB memory minimum, but the platform manages runtime memory and does not publish a stable range. E2B starts its base template at 512 MiB. Daytona's hosted container floor is 1 GiB. Blaxel's published units run from 2 GB to 32 GB. Boat.dev begins at 4 GB. exe.dev does not publish a per-VM minimum; one VM can consume a shared plan pool of up to 64 GB.

Freestyle's advantage is not that BusyBox replaces Ubuntu. It is that both are first-class choices in the same VM system. Start with the tiny image when the task is tiny. Start with Ubuntu when you need systemd, Docker, packages, users, SSH, and a familiar development environment.

At the other end, Freestyle publishes per-VM maximums of 32 vCPU, 64 GiB RAM, and 256 GB disk on Pro, with custom Enterprise limits. CPU and memory can grow live, while disk grows on a running VM. The dimensions do not have to move as a bundle. The main constraint is that resizing is grow-only, so a workload that needs to shrink should branch or recreate onto a smaller VM.

That combination, from a 128 MiB hardware VM to a large Ubuntu machine, is more adaptable than offering a long menu of medium and large presets.

A firewall is not the same thing as internet access

Every product here can reach a network. Far fewer make the network a useful control-plane object.

There are four questions worth separating:

• Is outbound traffic allowed or denied by default?
• Can policy match identities, networks, domains, IP ranges, ports, and protocols?
• Can the policy change while the sandbox is running?
• Is the rule enforced outside the guest, where untrusted code cannot turn it off?

There is also a blunt procurement question: how many rules can you create? None of the provider firewall docs publishes a numeric limit for ordinary allow and deny entries. That does not mean the number is unlimited. A buyer who expects thousands of entries should get the limit in writing and test update latency at that scale.

Freestyle

Freestyle is default-deny. A new VM receives a firewall at creation, and an empty rule list is valid. Without an allow rule, it cannot send or receive ordinary traffic.

Rules can match another VM, an entire VPC, a WireGuard tunnel, an IPv4 or IPv6 CIDR, or the public internet. They can narrow access by TCP, UDP, or ICMP and by port. Rules can be created and deleted while the VM is running. Separately authorized platform paths, including managed domains and SSH, have their own controls.

The important part is where the policy lives. The workload can have root inside the VM and still cannot edit the provider firewall. Freestyle also extends the model with private dual-stack VPCs, site-to-site and developer WireGuard tunnels, named TLS routes, and edge credential injection. The public docs do not state a numeric firewall-rule cap.

E2B

E2B takes the opposite default: outbound internet is on. Its network configuration can disable all internet access or combine allowOut and denyOut entries for IPs and CIDRs. Domain allowlisting is supported for HTTP and TLS traffic, with explicit caveats around shared infrastructure. The whole network configuration can be replaced on a running sandbox.

E2B also has beta per-host request transforms for secret injection. Those transforms have a documented limit of 10 domains per sandbox, one transform rule per domain, and 20 headers per rule. That is not presented as the limit for ordinary allow and deny entries, whose numeric cap is not published.

This is a capable egress policy. It is narrower than Freestyle's network model because it does not expose the same general VPC, tunnel, ingress, and raw-protocol control plane.

Blaxel

Blaxel's outbound proxy supports live domain allowlists and denylists, method and path matching, and secret or payload injection. The docs do not publish a numeric rule cap. A configured proxy can change while the sandbox runs.

There is one awkward lifecycle boundary: a sandbox created without the proxy cannot enable it later, and a sandbox created with it cannot fully disable it. You can change its rules, but switching the control plane itself on or off requires a new sandbox. Blaxel also documents dedicated egress and VPC APIs, so it is more than a preview-URL product, but the proxy path is not equivalent to packet-level policy for every process.

Daytona

Daytona exposes a per-sandbox outbound firewall in one of three mutually exclusive modes: block everything, allow listed IPv4 CIDRs, or allow listed domains. The docs do not publish a list-length cap.

The policy is also tier-sensitive. Lower-tier organizations have platform restrictions that the sandbox cannot override. Higher tiers can use full internet access and can update per-sandbox policy while the sandbox is running. That is useful, but it means the answer to “is the internet on?” depends on both sandbox configuration and organization tier.

Fly Sprites

Sprites start with unrestricted outbound access. Their network policy can allow or deny exact domains, wildcard subdomains, and preset bundles. Updates apply immediately, and existing connections to a newly blocked domain are terminated. The policy is enforced outside the Sprite, so code inside cannot widen its own allowlist. Fly does not publish a numeric rule cap.

Every Sprite also gets a managed HTTPS URL that is private to the organization by default and can be made public. This is a useful live egress control, but it is domain-based. Sprites do not expose Freestyle's broader identity, CIDR, VPC, tunnel, port, and protocol rule model.

Modal

Modal allows outbound traffic by default and blocks inbound traffic by default. Sandbox networking can block all networking, allow selected outbound CIDRs, allow selected outbound domains for TLS on port 443, and limit access to exposed tunnels. No general list-size cap is documented.

Runtime updates are alpha and have a creation-time catch: a sandbox must be seeded with the type of allowlist you plan to update. This is adaptable enough for jobs whose policy is known at launch, less so for a long-lived machine whose networking role changes unpredictably.

exe.dev

exe.dev's HTTPS proxy is private by default and can expose one selected port publicly. Other proxied ports remain limited to users with access to the VM. The public docs do not expose a general platform egress firewall or a numeric rule system.

VMs are isolated from each other, but exe.dev explicitly says there is no private network connecting VMs in the same account. An edge-authenticated VM-to-VM HTTPS integration provides a narrower service-to-service path, and the docs suggest Tailscale when users need a general private topology. This is useful access control for preview servers, not an adaptable network-policy plane for untrusted workloads.

Boat.dev

Boat.dev documents dedicated addresses, hosted HTTPS ports, and full root access inside a Linux VM. It does not document a platform firewall-rules API. The recommended escape hatch is the usual Linux one: install and configure a firewall, proxy, VPN, or encryption tool inside the guest.

That works for a server you trust. It is a weak isolation boundary for a sandbox running code you do not trust, because that code may have the same sudo access needed to modify the policy. In this comparison, Boat.dev has the least adaptable network control plane.

“Snapshot” can mean two different products

Filesystem snapshots are useful. They save repositories, installed packages, databases on disk, and generated artifacts. They do not save the live computer.

A memory snapshot can preserve an authenticated CLI, a browser with pages open, a language server with its index warm, a dev server, an agent halfway through a task, and any other process state that is expensive or impossible to reconstruct exactly. For interactive sandboxes, that is a different class of feature.

Freestyle snapshots exact memory and disk from a running or paused VM. The API returns after the snapshot is fully materialized, and independent VMs can be created from it. Normal pause and resume also retain memory, processes, and open files.

E2B now offers persistent memory and filesystem snapshots, not just template images. Creating one briefly pauses the source and drops active connections, then the original continues running. One snapshot can create many sandboxes. Its normal pause path can preserve memory too.

Blaxel's snapshots include memory, running processes, and the filesystem. They can restore the original sandbox or fork a new one, and they do not expire automatically. Blaxel's automatic standby also preserves memory and processes, although external network connections do not survive.

Daytona splits the answer by sandbox class. Its default containers preserve the filesystem across stop and start but lose memory. Linux VM and Windows sandboxes support pause and resume with memory, plus hot and cold snapshots. The richer state model exists, but it is not the default container product.

Fly Sprite checkpoints capture the complete writable filesystem with copy-on-write storage. They are created live without interrupting running processes, but the checkpoint does not contain those processes or their memory. Restoring rewinds the filesystem, stops services, and restarts the environment. A warm idle pause can preserve process state temporarily, but Fly can later move the Sprite into its cold state and discard that state. The user cannot choose or observe that transition.

Modal's filesystem snapshots default to a 30-day retention period, which can be changed or disabled. Memory snapshots are alpha, expire after seven days, terminate the original sandbox, require the same instance type on restore, exclude GPUs, and have limitations around active exec calls and background processes. Useful, but not yet a general durable checkpoint.

exe.dev's cp command makes a fast copy of an existing VM. exe.dev describes the implementation as copy-on-write and presents it as a way to branch a configured development filesystem. Its docs do not claim that cp preserves running memory or processes, so it should not be treated as a live-machine snapshot.

Boat.dev continuously saves the filesystem, including a snapshot when a machine stops. It explicitly does not capture memory, running processes, or open ports. The restored machine reboots, and services have to start again. You can keep up to 10 named snapshots in addition to the latest automatic one.

Calling all eight products “snapshot-capable” would hide the most consequential difference in the review.

How each product holds up

Freestyle runs small and large VMs through the same API

Freestyle covers the largest range of full-machine jobs without changing abstractions. A 128 MiB BusyBox VM, a normal Ubuntu workstation, a Docker host, a private-network service, and a 64 GiB agent machine all use the same lifecycle and networking APIs.

The grow-only resize model is a real constraint. The default-deny firewall also asks more of the caller than an open internet connection. Both are predictable constraints, and neither forces the workload into a narrower runtime.

Freestyle's strongest argument is the combination: tiny and large hardware VMs, independently shaped resources, full Linux, live network policy, private networking, and memory-plus-disk snapshots. No other product here combines all of those at both ends of the size range.

E2B locks machine shape into the template

E2B is designed around standardized templates, and that choice limits how far a running sandbox can adapt. It supports memory snapshots, pause and resume, live egress policy, public-access controls, and reusable templates, but none of those features makes the machine shape flexible.

CPU and RAM belong to the template, and custom resources are selected while building it. A fleet with a handful of known shapes can work within that model. A long-lived sandbox whose demands change while it runs cannot simply grow with the workload.

E2B suits repeatable agent jobs better than evolving computers. Freestyle can grow CPU, memory, and disk without changing the machine model; E2B cannot.

Blaxel preserves state but couples CPU and memory

Blaxel has one of the better state models in the group. Automatic standby preserves memory, explicit snapshots can be restored or forked, and its proxy can change outbound policy and inject secrets while the sandbox runs.

Blaxel publishes five units. XS starts at 2 GB of memory and 1 vCPU; XL reaches 32 GB and 8 vCPUs. Memory is chosen at creation and determines CPU allocation, so the two cannot be tuned independently. The ladder is clear, but it does not offer Freestyle's 128 MiB full-VM floor or independent resource sizing.

Daytona spans more runtime types, with different rules for each

Daytona can cover hosted containers, Linux VMs, Windows, dedicated macOS, and GPU work. That is a genuinely broad platform. Its resize API can increase CPU and memory on a running sandbox; decreasing them or growing disk requires a stop, and disk cannot shrink.

The caveat is that the word “sandbox” does not have one set of semantics. Containers and VMs differ in snapshot behavior. Network defaults and live policy changes differ by tier. VM environments are created from VM snapshots rather than the same declarative build flow used for containers. Daytona is adaptable across categories, but moving between those categories is not a small configuration change.

Fly Sprites hide machine sizing from the operator

Sprites are much closer to this comparison than raw Fly Machines. Each Sprite is a hardware-isolated Firecracker microVM with a persistent ext4 filesystem, command and session APIs, a managed HTTPS URL, live outbound network policy, and filesystem checkpoints.

The resource model removes operator choice. Every Sprite gets 8 vCPUs and 100 GB of storage. Memory grows automatically under pressure, and Fly does not publish one stable RAM figure to design around. CPU and storage cannot be resized, and memory cannot be shaped directly. That is automatic capacity, not a configurable resource envelope.

The lifecycle has a similar boundary. A warm pause preserves memory and processes, then a later cold transition discards them. Fly chooses when that happens. Checkpoints preserve the filesystem and restart the environment on restore. Sprites work well for agents that need durable files and automatic idle suspension, but they cannot provide a chosen machine shape or durable live-state branching.

Modal suits jobs better than long-lived computers

Modal is flexible about compute requests. CPU can be fractional, the default memory request is 128 MiB, scratch disk can reach 3 TiB, and workloads can scale across containers, GPUs, and beta VM sandboxes. The public docs do not publish a numeric memory ceiling, and containers may burst beyond their request, so Modal does not expose a clean machine-size envelope.

Its lifecycle is intentionally job-shaped. A sandbox has a maximum lifetime of 24 hours, with filesystem snapshots suggested for longer persistence. Memory snapshots are still alpha and expire after seven days. Network changes are also alpha and partially constrained at creation.

For batch work, data processing, and bursty model workloads, those choices make sense. For an agent that should feel like the same computer next week, they are hard product boundaries.

exe.dev and Boat.dev are Linux VMs with thin control planes

exe.dev provides general Linux VMs with persistent disks, Docker support, root access, SSH, and private-by-default HTTPS routes. CPU, memory, and disk can be changed through the resize command. Its four plans provide shared pools from 2 vCPU and 8 GB of RAM through 16 vCPU and 64 GB, and one VM can consume the entire pool.

exe.dev is the more shapeable of the two, but the pool is shared across every VM on the account. A 64 GB plan is not 64 GB for every machine in a fleet. The public docs also do not publish a per-VM minimum, a memory snapshot, a general provider firewall, or a private VM network.

Boat.dev offers four fixed machine types: small, default, large, and xlarge. CPU and memory move together from 2 shared vCPU and 4 GB to 16 shared vCPU and 32 GB. Xlarge is bare-metal-only, requires at least the $100 plan, and must be allocated by the operator. A machine can change type on resume or through a fork, not by live independent resizing.

Its snapshots save files but not the running computer. Its network security lives mostly inside the machine. It has no tiny shape for sparse fleets and no large or odd shape for unusually demanding work.

Both products are closer to persistent computer services than complete sandbox control planes. Boat.dev is the more restrictive one. It works for coding environments, preview servers, and tasks where “a Linux box with a URL” is the whole requirement. Once a workload needs control-plane networking, live state branching, independent resource tuning, or a genuinely small footprint, Boat.dev has no next move.

Freestyle covers the widest range

Freestyle handles more kinds of full-computer workload without switching products. The same API can run a 128 MiB BusyBox appliance or a 64 GiB Ubuntu agent, resize resources independently, enforce network policy outside the guest, and snapshot memory with disk.

E2B locks machine shape into a template, while Blaxel couples CPU and memory. Daytona spans more runtime types, but each type has different persistence and networking semantics. Modal is built around elastic jobs. Fly Sprites fix CPU and storage, manage memory automatically, and preserve process state only until the platform moves them from warm to cold.

exe.dev and Boat.dev provide familiar Linux machines without much machinery around them. exe.dev can resize within a shared account pool. Boat.dev couples CPU and memory into four fixed sizes and starts at 4 GB. Neither documents a provider egress firewall or memory snapshots. Boat.dev runs out of options first because its filesystem-only snapshots, guest-managed network controls, and fixed sizes leave little room for the workload to change.

Freestyle is the only product here that combines a 128 MiB floor, a 64 GiB ceiling, external network policy, and memory-plus-disk snapshots in one VM system.