Go 1.26 services turn each sandbox into a small machine
E2B Runtime is a Go 1.26 backend for giving an agent a Linux machine rather than a process in the main application. The API places a sandbox, an orchestrator manages its Firecracker microVM, envd handles commands and files inside the guest, and a proxy routes traffic to open ports. A sandbox can pause, resume, or fork from a snapshot. That isolation matters when an agent may execute faulty or hostile code.
Our commit da1ddd2 checkout contained 2,531 files and roughly 433,174 lines of source in 17.7 MB. The README describes PostgreSQL and Redis in the control plane, ClickHouse for events and metrics, object storage for snapshots, plus node-level networking and block devices. Adopting it means owning an execution platform. It is a poor trade if your requirement ends at one short command in an existing container.
The 49 passing tests cover a Python helper, not the runtime
All 49 pytest cases passed in our sandbox, but the measured project lives under firecracker/fc-versions. Its pyproject.toml identifies a Python 3.12 tool for Firecracker build and release work, with Anthropic as its sole runtime dependency and pytest in the development group. The main product is a Go control plane and node runtime. A green helper suite cannot tell you whether KVM, snapshot storage, network routing, or sandbox lifecycle operations work on your host.
The 4-second build confirms that the targeted helper built in a fresh Debian container. It does not prove that a Firecracker guest started, because our container was unprivileged and carried no secrets. E2B's development guide requires /dev/kvm, NBD devices, huge pages, downloaded kernels, custom Firecracker binaries, and root access for the orchestrator. Those steps sit outside the result we measured.
What happened when we ran it
Our sandbox installed 49 Python packages in 26 seconds and occupied 52 MB on disk. The build completed in 4 seconds. We ran commit da1ddd2 on 3 CPUs with 8 GB of RAM in an unprivileged Debian container, using the Python project in firecracker/fc-versions. The repository scan found 12 CI workflow files and a tests directory, but no Dockerfile.
Pytest finished in 5 seconds with 49 passed and 0 failed. Pip-audit reported 0 known vulnerabilities in the installed Python packages. Those are clean results for the versioning helper. Our test method did not run a sandbox VM, test pause or resume, expose a sandbox URL, or exercise the Go services. Claims about guest startup, isolation, or throughput need a privileged deployment.
Embed is an evaluation package with 11 listening ports
E2B Embed offers Compose, GCP Terraform, and Kubernetes routes for a single machine, but its guide calls all of them evaluation packages. The Compose path requires Linux with KVM, Docker Engine 27 or newer, Compose 2.24 or newer, and a host the installer may modify. Current guidance recommends 12 GiB of RAM and 20 GiB of free disk. E2B directs production deployments to its enterprise offering.
Security depends on the host boundary. Embed binds 11 ports on every interface and says only ports 3000 and 3002 should be reachable by trusted clients. Port 5008 is an unauthenticated gRPC control API that can create and kill sandboxes or start template builds. Four other ports accept redirected sandbox egress traffic without their own client authentication. If your network policy cannot keep those 9 internal ports unreachable, the two-file quick start is unsafe.
Full development needs root, KVM, and three core stores
The source guide sets an 8 GB minimum and recommends 16 GB of RAM, with about 4 GB reserved as huge pages. PostgreSQL, Redis, and ClickHouse provide core state, while the local setup can also start Grafana, Loki, Tempo, Mimir, Memcached, an OpenTelemetry collector, and Vector. The orchestrator runs with sudo because it creates TAP devices, manages cgroups, mounts NBD devices, and opens /dev/kvm. WSL2 is explicitly unsupported for that path.
The fc-versions README requires Python 3.12 and FIRECRACKER_REPO_TOKEN to clone the customized source used for builds. Open issue 3612 asks what public source self-hosters should use after the older Firecracker fork was archived, and it had no reply when checked. Embed instead downloads public prebuilt binaries and verifies checksums. That may be acceptable, but it does not satisfy a policy that requires rebuilding every VM component from public source.
A September 2026 release is active, while lifecycle races remain open
GitHub showed 1,501 stars, 197 combined open issues and pull requests, and 106 open issues when fetched. The last push was September 16, 2026, one day after several lifecycle reports were updated. Release 2026.30 arrived on September 10 with changes across authentication, orchestration, observability, and sandbox resume behavior. This is current work rather than a dormant code dump, and the busy queue matches the size of the system.
Issue 3636 documents a race where DELETE returns HTTP 204 while an in-flight resume later returns 201 and leaves the sandbox running. Issue 3637 reports that a cancelled create can leave an unregistered VM on the node until reconciliation removes it after roughly 1 minute. Both reports include reproduction detail, but neither our 49-test helper run nor repository activity closes those risks. Test kill, timeout, and reconciliation behavior against the exact release you plan to operate.
The 52 MB helper result should start evaluation, not end it
The 52 MB installed footprint and 49 passing tests make the Firecracker release helper easy to inspect, but they say little about the surrounding runtime. A serious trial needs a dedicated KVM host, 9 unreachable internal ports, concurrent create and delete checks, and proof that failed requests leave no guest behind. If you need that control, E2B documents the machinery clearly. Otherwise, E2B Cloud avoids owning it.