[opensourcedex]

runtime is a free, open source frameworks & platforms project written in Go and released under Apache-2.0. It has 1,677 GitHub stars, 461 forks and 212 open issues, and was last pushed 2 days ago. On this registry it ranks #81 of 103 tracked projects in Frameworks & Platforms, with 5 head-to-head comparisons available.

What is runtime?

E2B Runtime is the open-source Go backend — control plane, Firecracker orchestrator, in-VM agent, edge router, and template builder — that powers E2B's AI agent cloud and can be run by anyone on their own hardware.

What it is

E2B Runtime is the complete backend behind E2B Cloud: the control-plane API, the per-node orchestrator that drives Firecracker, the agent that runs inside every VM, the edge router for sandbox traffic, and the template builder. It is written in Go, licensed under Apache-2.0, and built by E2B. The same code serves the public cloud, dedicated enterprise deployments, and the single-machine Embed package you can run on your own hardware.

It solves the problem of giving every AI agent session its own isolated Linux machine that boots from a snapshot, runs whatever untrusted code the agent asks it to, and can be paused and resumed as if nothing happened. Concretely it replaces the pattern of provisioning a fresh container or VM per request: templates are pre-booted VMs stored in object storage, so "creating" a sandbox means restoring one rather than booting a kernel, with memory pages served lazily on page fault through userfaultfd and the root filesystem as a copy-on-write overlay over a read-only image. The control plane and data plane are kept separate: the API records that a sandbox runs, the node orchestrator owns how it runs, and sandbox traffic goes straight from the edge to the node without passing through the API.

Key capabilities

  • One Firecracker microVM per sandbox, each in its own cgroup and network namespace, with a per-sandbox nftables egress firewall and SNI/Host-inspecting domain allow and deny lists.
  • Pause and resume that diffs memory and disk against the template and ships the diff to object storage, with resume preferring the node that still has it cached, idle sandboxes auto-pausing, and incoming traffic waking them transparently.
  • Forking a running sandbox by checkpointing it in place and starting up to a hundred new sandboxes per request while the original keeps running untouched.
  • Template builds layered from Docker images and build steps, each layer hashed and cached, followed by an optimize pass that records which pages a boot actually touches.
  • An envd API inside every VM exposing processes, PTYs, filesystem operations, file watchers, and port forwarding over Connect RPC and REST, live-upgradable inside a running sandbox without dropping the workload.
  • Sandbox URLs that reach any port a process inside the sandbox is listening on.
  • A hard split between the control plane, which decides where a sandbox runs, and the per-node orchestrator, which owns the Firecracker process, network namespace, block device, and cgroup.

Who uses it and how

  • Operators of E2B Cloud, where the public AI agent cloud runs this exact codebase across many nodes.
  • Enterprises running a dedicated deployment of the same control plane and orchestrator on their own infrastructure.
  • Teams shipping AI agents and code interpreters that need one isolated Linux machine per session to execute untrusted model-written code.
  • Single-machine users who deploy the Embed package on their own hardware instead of using the hosted cloud.
  • Workloads that fan out by forking a live sandbox into many children per request while the original continues running.

Getting started

The README points to the Embed package documented in embed/README.md ("Run it yourself") for running the runtime on your own machine, alongside the docs at docs.e2b.dev, the architecture notes in docs/ARCHITECTURE.md, and the separate SDKs and CLI repository at github.com/e2b-dev/E2B.

How it compares

It stands alone in this registry.

When to use it — and when not

A self-hoster must operate a multi-node environment with KVM-capable hosts for Firecracker, object storage for templates and pause diffs, the control-plane API, and the edge router that terminates sandbox traffic. It is a poor fit for anyone who simply wants to run ordinary containers, since the value here is snapshot-resumed hardware-isolated sandboxes for untrusted agent code, and the project currently carries 212 open issues.

project readme (upstream, from github) — read inline

E2B Runtime

The open-source runtime behind E2B, the AI agent cloud. Firecracker microVMs that resume from a snapshot, run untrusted agent code, and pause when the agent stops.

License: Apache-2.0 Go GitHub stars Discord X

Docs | Architecture | Run it yourself | SDKs & CLI | Cookbook | Contributing

What is E2B Runtime?

E2B Runtime is the complete backend that powers E2B Cloud: the control-plane API, the per-node orchestrator that drives Firecracker, the agent that runs inside every VM, the edge router for sandbox traffic, and the template builder. It gives every agent session its own isolated Linux machine that boots from a snapshot, runs whatever the agent asks it to, and can be paused and resumed as if nothing happened.

It is written in Go, licensed under Apache-2.0, and built by E2B. The same code serves the public cloud, dedicated enterprise deployments, and the single-machine Embed package you can run on your own hardware.

Why it's fast

Two ideas drive the design.

A sandbox is a resumed snapshot. Templates are pre-booted VMs (memory, disk, and machine state) stored in object storage. "Creating" a sandbox means restoring one, not booting a kernel. Memory pages are served lazily on page fault through userfaultfd, and the root filesystem is a copy-on-write overlay over a read-only image, so only the data a sandbox actually touches is ever fetched. Fresh creates, resumes after a pause, and forks all take the same path.

Control plane and data plane never mix. The API decides where a sandbox runs and records that it runs. The orchestrator on each node owns how it runs: the Firecracker process, the network namespace, the block device, the cgroup. Sandbox traffic goes straight from the edge to the node and never passes through the API.

What you get

  • Hardware-isolated sandboxes. One Firecracker microVM per sandbox, in its own cgroup and network namespace, with a per-sandbox nftables egress firewall and SNI/Host-inspecting domain allow and deny lists.
  • Pause and resume. Pause diffs memory and disk against the template and ships the diff to object storage. Resume prefers the node that still has it cached. Idle sandboxes auto-pause, and incoming traffic wakes them transparently.
  • Fork a running sandbox. Fork checkpoints a live sandbox in place and starts new sandboxes from that snapshot, up to a hundred per request, while the original keeps running untouched. A paused sandbox has the same artifact shape as a template, so resuming one takes the same fast path as creating one.
  • Templates built from your recipe. Layered builds from Docker images and build steps, each layer hashed and cached, with a final optimize pass that records which pages a boot actually touches.
  • A real API inside every VM. envd exposes processes, PTYs, filesystem operations, file watchers, and port forwarding over Connect RPC and REST. It is what the SDKs talk to when they "run code", and it can be live-upgraded inside a running sandbox without dropping the workload.
  • Sandbox URLs for anything that listens. https://-. reaches any port a process opens, routed at the edge with per-sandbox access tokens.
  • Persistent volumes, secrets, workload identity. Volumes outlive sandboxes. Secrets are metadata-only on the control plane: no value ever crosses the API, a log, or a span. Workload identity gives a sandbox short-lived tokens without the API ever minting a credential.
  • Observability built in. Everything exports OpenTelemetry. Sandbox lifecycle events, host stats, and metrics land in ClickHouse.

Run it

On E2B Cloud. The fastest way to use the runtime is to not run it. Grab an API key at e2b.dev and start a sandbox from the JavaScript or Python SDK:

from e2b import Sandbox

with Sandbox.create() as sandbox:
    result = sandbox.commands.run('echo "Hello from E2B!"')
    print(result.stdout)

On one machine you own. E2B Embed is the whole stack, real Firecracker sandboxes included, on a single Linux host with KVM. Two files and one command:

mkdir e2b && cd e2b
curl -fsSL --remote-name-all "https://raw.githubusercontent.com/e2b-dev/runtime/main/embed/compose/{compose.yaml,.env}"
docker compose up -d --wait

The same package ships as Terraform for GCP and as a Kubernetes manifest. It is an evaluation package, not a production deployment pattern.

In your own cloud, for production. E2B runs the runtime as a dedicated deployment inside your account, with your data staying there. See e2b.dev/enterprise.

How it fits together

SDK / CLI ──REST──▶ API ──gRPC──▶ orchestrator ──▶ Firecracker microVM ──▶ envd ──▶ your processes
                     │                 │
                     ├── PostgreSQL    ├── object storage (templates, snapshots)
                     ├── Redis         └── ClickHouse (events, metrics)
                     └── ClickHouse

browser ──https://<port>-<sandbox>.<domain>──▶ client-proxy ──▶ orchestrator proxy ──▶ envd
Service Package Runs on Purpose
API packages/api control plane Public REST API: sandbox lifecycle, placement, auth, quotas
Orchestrator packages/orchestrator every sandbox node Runs Firecracker VMs: create, pause, resume, kill, checkpoint
Template manager packages/orchestrator (role) build nodes Builds templates from Docker images and build steps
Client proxy packages/client-proxy control plane Edge router: sandbox URL to the right node, auto-resume on traffic
Envd packages/envd inside every VM Process, filesystem, and port API the SDKs use
Dashboard API packages/dashboard-api control plane Backend for the web dashboard

docs/ARCHITECTURE.md has the full picture: sequence diagrams for creation, traffic, pause and resume, and template builds, plus the data stores and the deployment topology. Read it first.

Who is this for?

  • Teams building agents who want to know exactly what their sandbox is, down to the kernel, and to run the same runtime locally that they run in production.
  • Platform teams who need agent execution inside their own cloud account, on infrastructure they control, without a black box.
  • Infrastructure engineers interested in Firecracker, lazy memory restore, copy-on-write block devices, and snapshot-based scheduling at scale.

Developing

The runtime needs Linux with KVM. DEV-LOCAL.md walks through the host prep, the local stack, and running services from source.

make local-infra        # PostgreSQL, Redis, ClickHouse, monitoring
make test               # unit tests across packages
make test-integration   # against a live deployment
make generate           # OpenAPI, proto, sqlc
make fmt lint tidy

Releases are per package and follow conventional commits; see docs/RELEASING.md.

Contributing

Bug fixes and docs fixes are welcome as pull requests. For anything larger, open an issue first so we can agree on direction before you write code. CONTRIBUTING.md has the details, including what we are unlikely to merge and why.

Community

License

Apache-2.0. See LICENSE.

Frequently asked questions

Is runtime free to use?

runtime is open source under the Apache-2.0 licence. There is no licence fee and no seat count — you can self-host it or, where the project offers one, pay a vendor for a managed version instead.

What does runtime do?

The runtime behind every E2B stack: Cloud, Enterprise, and your own machine.

What is runtime written in?

runtime is primarily written in Go. Its source is publicly available at https://github.com/e2b-dev/runtime, and it has 1,677 GitHub stars.