Four service layers turn Firecracker into an agent sandbox
E2B Infra is the control plane behind E2B's code-execution sandboxes. A request passes through the client proxy and API to an orchestrator, which manages Firecracker microVMs. Each guest runs envd, a daemon that handles processes and files. PostgreSQL stores primary data, Redis carries state, ClickHouse holds analytics, and object storage contains templates and builds. Terraform and Nomad place those pieces in a cloud account.
This is more than a wrapper around Firecracker. The measured checkout contained 2,529 files, roughly 397,845 lines of source, and occupied 16.4 MB. Go services implement the API, proxy, orchestrator, and guest daemon. The repository also includes infrastructure definitions, image builders, database migrations, generated protocols, observability plumbing, and Python release tooling. A team adopting it takes responsibility for a small cloud platform, including upgrades and failure recovery.
GCP self-hosting starts with 24 CPUs and 2,500 GB of SSD quota
The supported GCP guide asks for quota covering at least 24 CPUs and 2,500 GB of persistent SSD. It also requires Packer, Terraform 1.7.5, Go, Docker, Buildx, npm, a GCP project, Cloudflare, a managed domain, and an IPv4-compatible PostgreSQL connection. The workflow enables several Google APIs, builds and uploads images, copies public Firecracker artifacts, fills secret-manager entries, applies Terraform in stages, migrates the database, and seeds an initial user, team, and base template.
AWS follows a similar 11-step path and is labeled beta. Its documented default pools include 3 control servers, an API node, Firecracker clients, a template builder, and a ClickHouse node. The client and build instances need nested virtualization. Azure and a general Linux machine remain unchecked in the README. That cloud boundary should settle the first purchasing question: this is for an infrastructure team, not someone seeking a local Docker Compose file.
What happened when we ran it
Our sandbox installed the Python project under firecracker/fc-versions in 32 seconds. It added 49 packages and consumed 52 MB on disk. The build completed successfully in 20 seconds, then pytest passed 49 of 49 tests in 18 seconds. Pip-audit found 0 known vulnerabilities. We used commit 8a3f69d in a fresh unprivileged Debian container with 3 CPUs, 8 GB of RAM, Python 3.12, and no secrets.
That is a clean result with a narrow boundary. The subproject describes itself as tooling for building and releasing custom Firecracker versions, and its pytest configuration points at the scripts directory. Our run did not provision GCP or AWS, execute Terraform, start Nomad, create a microVM, test nested virtualization, or exercise the API and storage services. The repository's 15 CI workflow files and broader tests directory indicate other validation surfaces, but the supplied 49-test result applies only to the measured project path.
Firecracker source builds depend on a separate repository
The fc-versions build script takes a commit, version name, and either amd64 or arm64. It requires Linux and a FIRECRACKER_REPO_TOKEN, then clones a source repository, builds production and debugging binaries, and checks that the debugging feature is present. By default it targets e2b-dev/e2b-firecracker. The GitHub API returned Not Found for that repository with the credential used for this review.
Open issue 3612 asks whether prebuilt binaries are now the intended self-hosting path because the default source repository is not publicly accessible and the older e2b-dev/firecracker fork is archived. That issue was still open when checked. This does not stop the documented make copy-public-builds path, which copies published kernels and Firecracker versions into your bucket. It does block a clear public-source route for teams that insist on rebuilding the customized microVM runtime themselves.
Current issues expose the cost of operating the whole stack
Issue 3619 reports that flock() on an E2B mounted volume can block forever because the NFS path lacks locking support, while local disk locking works. The report says the stuck process cannot be killed and the sandbox must be destroyed. Issue 3615 describes an orchestrator taking 20 to 30 minutes to bind its gRPC port while it serially cleans thousands of leftover network namespaces after a drained node. Both reports concern self-hosted runtime behavior rather than the small Python project we tested.
These are specific failure modes in file locking and node recovery, not proof that every deployment has them. They show what the operator owns once workloads depend on microVMs, NFS, network namespaces, and a scheduler. The self-hosting guide points users to the Nomad interface and cloud secret manager for inspection. Teams should test volume semantics, readiness during restarts, template builds, and sandbox teardown against their own agent workloads before exposing the service.
Release 2026.29 is older than the September activity
GitHub listed 1,359 stars and 195 combined issues and pull requests when fetched. Release 2026.29 arrived on July 28, 2026, with sandbox forking, storage, template, networking, and envd changes. The repository was pushed on September 4, and recent issues and pull requests addressed mounted-volume locking, orchestrator startup, guest readiness, and network behavior. The newer activity matters more than the release date alone when judging maintenance.
E2B Infra is a credible base for organizations that want an E2B-compatible sandbox cloud and have the staff to run it. The 49 passing tests make its Firecracker release tool reassuring to change, while they say little about a production cluster. GCP has the clearest route. AWS adopters accept beta status, and Azure users need another project. The deciding cost is operational ownership: cloud quotas, image pipelines, secrets, state stores, privileged networking, and microVM failures all become your problem.