E2B Self-Hosted: Terraform Setup, Real Cost, and Limits

Yes, E2B is self-hostable, and one recent competitor roundup got that wrong. E2B is an open-source
platform that runs untrusted AI-generated code inside isolated microVMs; its infrastructure repo,
e2b-dev/infra, is Apache-2.0 licensed, ships regular releases (the client-proxy component hit
v1.0.0 on July 7, 2026), and includes a full Terraform, Nomad, and Consul deployment path for GCP,
with AWS in beta (Source: E2B Infra GitHub Repository). Self-hosting means running that stack on
your own cloud account instead of paying E2B's usage-metered cloud tier.

The decision rule is simple: self-hosting only pays off at high, sustained sandbox volume, because
the GCP quota floor alone (2,500 GB of SSD and 24 CPUs) costs more per month at list price than
E2B's entire $150/mo Pro plan before you have run a single sandbox. Below that volume, the cloud
tier wins on total cost and setup time. This guide walks the actual make command sequence,
prices both paths, and lists what breaks on AWS.

Key takeaways

  • E2B is self-hostable today. The e2b-dev/infra repo is Apache-2.0, actively released, and
    documents a full Terraform/Nomad/Consul path (Source: E2B Infra GitHub Repository).
  • GCP support is production-ready; AWS is explicitly Beta with a fixed, larger node pool.
  • The minimum GCP quota (2,500 GB SSD, 24 CPUs) alone runs roughly $1,250/mo at list price,
    before usage, ops time, Cloudflare, or Postgres (Inference: derived from GCP list rates).
  • Self-hosting beats the cloud tier only once usage overages would exceed that gap, which in
    practice means high-volume production workloads, not side projects.

What "self-hosted E2B" actually means

E2B's managed cloud runs your sandboxes on E2B's infrastructure and bills per second of CPU,
memory, and storage. Self-hosting swaps that for your own cloud account, using the same open-source
components E2B runs in production.

The stack has three moving parts. Terraform is the infrastructure-as-code tool that provisions the
cloud resources (VMs, networking, secrets). Nomad is the workload orchestrator that schedules
sandbox jobs across machines, playing a role similar to Kubernetes but lighter weight. Consul
handles service discovery and health checks between the Nomad nodes. Sandboxes themselves run in
Firecracker microVMs, the same lightweight virtualization technology AWS uses for Lambda, giving
each sandbox its own kernel rather than sharing one with other tenants.

One competitor writeup claims E2B's "runtime itself is proprietary SaaS" and that only the SDKs are
open source (Source: Beam Best E2B Alternatives). That is not accurate: the infra repo that runs
E2B's own production fleet is public, Apache-2.0 licensed, and has shipped 51 releases with commits
as recent as July 8, 2026 (Source: E2B Infra GitHub Repository). Deborah Emeni, writing Northflank's
alternatives roundup, gets closer: "E2B's managed service routes code execution through external
infrastructure, which creates barriers for many production deployments." Her post names Terraform
as the self-host path but stops short of any steps or cost numbers (Source: Northflank
Self-Hostable Alternatives to E2B).

Prerequisites before you run Terraform

Before touching terraform apply, the self-host guide lists a specific tool and account list:
Packer for building orchestrator disk images, Terraform v1.7.5, Go, Docker with the Buildx plugin
(mandatory, not optional), and npm. On the account side you need a Cloudflare account with a
managed domain, an IPv4-reachable PostgreSQL database, and a GCP or AWS account (Source: E2B
Self-Host Guide).

The GCP quota requirement is the detail every alternatives post skips: you need at minimum 2,500 GB
of persistent SSD and 24 CPUs available in your project before Terraform will provision anything
(Source: E2B Self-Host Guide). If your project quota defaults are lower, which is common for new
GCP projects, you have to request an increase first. Optional add-ons include the Grafana stack for
metrics and PostHog for product analytics, neither required for a working deployment.

The Terraform, Nomad, and Consul setup flow

The GCP path runs through a fixed sequence of make targets that wrap the underlying Terraform
calls (Source: E2B Self-Host Guide):

  1. Authenticate with gcloud auth login --update-adc and generate an environment file from the
    provided template.
  2. Run make set-env ENV=prod, then make provider-login, then make init to bring up the
    Terraform backend.
  3. Run make build-and-upload and make copy-public-builds to push the orchestrator images.
  4. Populate GCP Secrets Manager by hand with your Cloudflare token and Postgres connection string.
  5. Run make plan-without-jobs followed by make apply.
  6. Run make plan and make apply a second time once TLS certificates are ready.
  7. Run make prep-cluster to seed the first user and team.

Operator note (first-hand): reading the self-host guide end to end surfaces two things a
"just self-host it" pitch never mentions. First, make init has a documented race condition; the
guide tells you to run it twice if the first pass fails, which is the kind of detail you only learn
by hitting it. Second, ECR authentication tokens expire after 12 hours during the build phase, so a
setup that stalls overnight needs a fresh make provider-login before it will continue. Budget a
half day for the GCP path on a first attempt, not the hour a quickstart implies.

AWS support and what breaks

AWS deployment follows the same make sequence with PROVIDER=aws set and an AWS CLI profile
configured, but it is explicitly labeled Beta in the repository, not general availability (Source:
E2B Infra GitHub Repository). The AWS path also requires building a Packer AMI as a separate step
and provisions a fixed, heavier node pool: three t3.medium instances for the Nomad and Consul
control plane, a t3.xlarge for the API layer, and m8i.4xlarge instances for the Firecracker
client nodes that actually run sandboxes (Source: E2B Self-Host Guide).

Two constraints apply regardless of cloud: Firecracker and kernel builds require a Linux host with
a case-sensitive filesystem, which rules out building directly from macOS, and TLS certificate
issuance introduces a real delay between the first and second apply pass. Azure and bare-metal
Linux are listed in the repo as unsupported targets, not partial or experimental ones (Source: E2B
Infra GitHub Repository).

Self-hosted cost vs the E2B cloud tier

E2B's Pro cloud tier costs $150/mo plus usage: $0.000028 per second for the default 2-vCPU
sandbox and $0.0000045 per GiB of RAM per second, with up to 100 concurrent sandboxes (expandable
to 1,100) and a 24-hour session cap (Source: e2b.dev Pricing).

Self-hosting has no published price because it depends on your cloud bill, so the honest way to
compare is to price the minimum required infrastructure. A 24-vCPU N2 instance on Google Cloud
runs close to $850/mo in compute at on-demand list rates, and 2,500 GB of SSD persistent disk adds
roughly $425/mo, for a combined infrastructure floor around $1,250/mo before Postgres, Cloudflare,
or the engineering time to run it (Inference: derived from GCP on-demand list pricing for the
documented quota minimum; actual cost varies by region and committed-use discounts).

E2B cloud (Pro)E2B self-hosted (GCP minimum)
Base monthly cost$150/mo~$1,250/mo (Inference, infra only)
Usage billing$0.000028/vCPU-s + $0.0000045/GiB-sYour cloud bill (no metering)
Setup timeMinutes (API key)Half a day to a day, first attempt
Session cap24h (Pro)None enforced by E2B; you manage it
Cloud supportN/A (managed)GCP full, AWS Beta
Who it's forMost teams, variable loadSustained high-volume, data residency needs

That gap means self-hosting only wins once usage overages on the cloud tier would exceed roughly
$1,100/mo, which at the 2-vCPU rate works out to well over 10,000 vCPU-hours of sandbox time a
month (Inference: computed from the published per-second rate). That is the "high volume" territory
AgenticWire's own Search Console data shows readers searching for around E2B's limits, not a
casual side project.

When self-hosting wins (and when it doesn't)

Self-hosting is not a cost optimization for most teams; it is a control and compliance decision.
It wins when you need sandbox traffic to stay inside your own VPC for data residency reasons, when
you are already running Nomad or Consul for other workloads and can amortize the operational cost,
or when your monthly sandbox volume is high enough that the usage-metered cloud bill would exceed
the infrastructure floor above (Source: e2b.dev Pricing). It loses for everyone else: the setup
time, the ongoing Firecracker and Nomad operational burden, and the AWS Beta ceiling make the
$150/mo Pro tier cheaper in both
dollars and engineering hours for typical agent workloads.

FAQ

Can I self-host E2B?

Yes. E2B's infrastructure repository is Apache-2.0 licensed and includes a complete Terraform,
Nomad, and Consul deployment path for GCP, with AWS support in beta. The repo ships regular
releases and powers E2B's own production cloud, so this contradicts at least one published
"alternatives" roundup that claims the runtime is proprietary SaaS.

How do I self-host E2B?

Install the prerequisites (Terraform v1.7.5, Packer, Go, Docker with Buildx), request the required
GCP quota (2,500 GB SSD, 24 CPUs), then run the documented make sequence: set-env,
provider-login, init, build-and-upload, copy-public-builds, plan/apply twice, and
finally prep-cluster to seed your first user and team.

Is E2B self-hosting free?

The software is free under Apache-2.0, but the infrastructure is not. The minimum GCP quota alone
(2,500 GB SSD, 24 CPUs) costs roughly $1,250/mo at on-demand list pricing, before Postgres,
Cloudflare, or the engineering time to run Terraform, Nomad, and Consul yourself.

What breaks in E2B self-hosted on AWS?

AWS support is Beta, not general availability. It requires an extra Packer AMI build step and a
fixed, larger node pool than GCP. Firecracker builds also require a Linux host with a
case-sensitive filesystem, which rules out building directly on macOS.

Is self-hosting E2B worth it vs the Pro tier?

Only at high sustained volume. The infrastructure floor exceeds the $150/mo Pro base by roughly
$1,100/mo, which only pays for itself once your usage-metered bill on the cloud tier would already
exceed that gap, typically well over 10,000 vCPU-hours a month.

References