If an agent writes code and something runs it, you have a sandboxing problem whether you have named it or not. The question is not whether to isolate execution. It is which isolation primitive, and where the execution happens.
This post compares six options on four things that are hard to change later: the isolation primitive, whether self-hosting is actually available, how concurrency is priced, and whether the project is still shipping.
Everything below was checked against each project's repository, LICENSE file and pricing page during August 2026.
Start with the primitive, not the product
Three levels of isolation, in increasing strength and cost:
Containers share the host kernel. A container escape is a kernel exploit away, and AI-generated code is untrusted input by definition. Fine for code you wrote, questionable for code a model wrote in response to a user's prompt.
MicroVMs (Firecracker and similar) give each workload its own kernel with a deliberately minimal device model. This is the primitive most of this category has converged on, and for good reason: it is a real security boundary with startup times measured in tens of milliseconds rather than seconds.
Full VMs are stronger still and slower to start. Rarely the right trade for per-request agent execution.
gVisor sits between the first two: a user-space kernel that intercepts syscalls so the workload never talks to the host kernel directly. It is what Modal uses, and it is a real boundary rather than a plain container.
If a vendor is vague about which of these they use, that is the first thing to pin down. Everything else on their page is downstream of it.
E2B
Apache-2.0, 13,599 stars, Firecracker microVMs.
The best-known name here and a genuinely excellent developer experience. Creating a sandbox and running code takes about four lines, and the SDKs are well made.
Two facts decide most evaluations.
Concurrency is a pricing tier. Hobby caps at 20 concurrent sandboxes, Pro at 100, with extra concurrency purchasable up to 1,100. Session length is tiered too: up to 1 hour on Hobby, up to 24 hours on Pro. Agent workloads are bursty, so the concurrency ceiling is usually the first constraint teams hit, and hitting it is a procurement conversation rather than a scaling one.
Self-hosting is documented, but it is not what you buy. There are two Apache-2.0 repositories, e2b-dev/E2B for the SDK and e2b-dev/infra for the Go infrastructure, and a root-level self-host.md describing a Terraform deployment: GCP is marked GA, AWS is beta, and Azure and generic Linux are listed unchecked. It expects a Cloudflare account and domain, Postgres, Packer and Terraform 1.7.5. What stays hosted-only is the commercial product and the pricing page, across Hobby, Pro and Ultimate tiers. So this is more paved than most roundups say, including an earlier version of this one, but it is a path you walk yourself.
Compute is billed per second and, unusually for this category, published openly: 1 vCPU at $0.000014 per second up to 8 vCPU at $0.000112, plus $0.0000045 per GiB per second of RAM. Storage is included at 10 GiB on Hobby and 20 GiB on Pro. Hobby gives you a one-time $100 of credits; Pro is $150 per month.
One number not to quote: E2B's homepage gives two different startup figures, less than 200 ms in one place and 80 ms in another. Take neither as authoritative.
Pick E2B when sandboxing is the whole problem, you want a hosted product, and your concurrency fits inside the tiers.
Daytona
71,871 stars. Repository no longer maintained. No licence file since June 2026.
This one needs care, because the star count is the most misleading number in this post.
Daytona's public repository README states: "This repository is no longer maintained. As of June 2026, Daytona's core development has moved to a private codebase. This repository will receive no further updates, fixes, or releases." It goes on to say it remains public and free to use, fork and build on, "as is and without support or warranty." The last commit landed on 25 June 2026.
The licence went the same way, in three steps that are worth pinning to dates. The initial commit on 6 February 2024 was Apache-2.0. A commit on 28 April 2025 relicensed the project to AGPL-3.0, alongside the pivot to AI sandboxes, shipped as v0.100.0. A commit on 23 June 2026 deleted the LICENSE file entirely, and GitHub now reports the repository licence as none. The last open release, v0.190.0, is AGPL-3.0, and the README points forks at that tag. If you were planning to fork, fork the tag, not main.
One correction to an earlier version of this post: we described Daytona as microVM-class isolation. That is contested by Daytona's own materials. Their documentation says default sandboxes are Linux containers, with VM sandboxes offered as a separate option, while the README claims each sandbox has "a dedicated kernel, filesystem, network stack". We are reporting both rather than picking one. For untrusted, model-generated code, get that answered in writing before you commit to it.
Two things follow from the maintenance notice, and they point in opposite directions.
If you were planning to self-host the open source build, you would be running an unmaintained snapshot, including for security fixes. For a sandbox product, whose entire job is to be a security boundary, that is a serious position to be in.
If you are a customer of Daytona's hosted product, none of this applies. The company continues to develop it, and the notice concerns the repository only. Daytona also documents sandboxes starting in under 90 milliseconds from code to execution, which is faster than most of this category, and their stateful snapshot support for persistent agent sessions is genuinely well developed.
Two things most write-ups of this miss. Daytona gave a reason, and it is a serious one for a sandbox vendor: publishing your isolation layer, kernel boundaries and orchestration logic hands the exact blueprint of that boundary to anyone who wants to probe it with an AI. Disagree if you like, but it is not a pretext.
And there is a middle path. Bring Your Own Compute lets sandbox workloads run on your own runner nodes, with official Helm charts, while Daytona's control plane, dashboard and database stay hosted by them. If your constraint is where code executes, that may be enough. If your constraint is that no vendor sits in the path at all, it is not.
One correction to the isolation story, since roundups keep repeating "microVM" for Daytona: their own isolation docs describe the default sandbox class as a Linux container with namespaces and enforced resource limits. Full VM isolation with its own kernel exists, but as an opt-in class. gVisor, Firecracker and Kata are named nowhere on that page. The sub-90ms figure is attached to the default container class, which is the one that is not a microVM.
Pick Daytona when you want their hosted product, or cold start is your binding constraint, or BYOC satisfies your requirement. Do not pick the frozen open source build to self-host as a security boundary.
Modal
Not open source. Not self-hostable. Serverless compute with GPUs.
Modal is on this list because it appears in every one of these searches, and because for a large class of workloads it is the better answer than anything else here.
It is general serverless compute rather than an agent sandbox specifically, with first-class GPU support and published per-second rates.
Price it off the Sandbox rate, not the headline one. Modal bills Sandboxes and Notebooks at $0.00003942 per core per second and $0.00000667 per GiB per second, roughly three times its standard compute rate of $0.0000131 and $0.00000222. Since this post is about sandboxes, the sandbox rate is the one that applies, and an earlier version of this post quoted the standard rate by mistake. A core means a physical core, about 2 vCPU, with a 0.125 core minimum. GPUs run from $0.000164 per second for an Nvidia T4 up to $0.001972 for a B300. Volumes are $0.09 per GiB per month with 1 TiB free. Starter is $0 plus compute with $30 monthly credits; Team is $250 plus compute.
Isolation is gVisor. Modal states that compute jobs are containerized and virtualized using gVisor, the sandboxing technology developed at Google. Its network controls deserve credit too, and they are better than most of this category: block_network=True drops all outbound traffic, outbound_cidr_allowlist restricts egress by CIDR, and Modal states that Sandboxes are not authorized to access other resources in your Modal workspace. One default to set deliberately rather than discover: a Sandbox lives five minutes unless you configure a longer lifetime, up to 24 hours.
Its pricing page describes no self-hosting or on-premises option.
Pick Modal when you need GPUs, or when you want general serverless compute rather than an agent-specific sandbox. Nothing else on this list offers managed GPU compute, so this is not a close call.
Beam
Beam positions itself as an open-source E2B alternative with Docker-based sandboxing, GPU support for both Python and Node.js, and no session time limits, with a self-hostable option.
We are flagging that as reported rather than verified: we did not check Beam's licence file or pricing page directly for this post, and everything else here was. Treat the summary above as a starting point for your own check rather than as a fact we are standing behind. If Docker-based isolation is accurate, weigh that against microVM alternatives for untrusted code.
Microsandbox and the smaller projects
There is a long tail here (microsandbox, OpenComputer, PandaStack and others) that shows up in roundups. We have not verified their licences, maintenance status or isolation guarantees, so we are not going to rank them.
One piece of advice that applies to all of them: check the commit history before the star count. Daytona is the cautionary example, and it is not the only project in this category that has gone quiet while its README still reads as if it has not.
Everstack
Apache-2.0, Docker, Firecracker and Kubernetes backends.
We build this, so judge the specifics rather than the source.
The checkable claims: self-hosting is the default supported path rather than a separate documented one, concurrency is bounded by the capacity you provision rather than a plan tier, and there is no separately licensed enterprise directory.
The structural difference is what surrounds the sandbox. Debugging an agent that wrote bad code means seeing the prompt, the completion and the execution together. On Everstack those share one trace, because the gateway that produced the code, the agent runtime that orchestrated it and the sandbox that ran it are one control plane. With separate systems, that correlation is a join you build and maintain.
Do not pick it for sandboxing alone. E2B has the more mature sandbox developer experience and a larger community, and buying a platform to get a sandbox is over-buying. The case needs at least two of these problems at once.
The four questions, in order
1. What is the isolation primitive? For untrusted, model-generated code, containers alone are a weaker boundary than most teams assume. MicroVMs are the current default for good reason.
2. Can you actually self-host, or only in principle? There is a meaningful difference between "documented with Terraform, but the commercial product is hosted-only" (E2B), "the repository is abandoned and the licence file has been deleted" (Daytona OSS), and "this is the default supported path" (Everstack). All three get described as self-hostable in roundups.
3. How is concurrency priced? This is the constraint teams hit first. A tiered ceiling turns a scaling event into a procurement event.
4. Is the project still shipping? Check the commit history and the LICENSE file, not the star count. A README written eighteen months ago says nothing about whether anyone is fixing CVEs today, and Daytona is proof that a licence can disappear without the README noticing.
Get those four right and the feature grid mostly stops mattering.
We publish side-by-side comparisons for E2B, Daytona and Modal that go deeper on each.