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/infrarepo 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):
- Authenticate with
gcloud auth login --update-adcand generate an environment file from the provided template. - Run
make set-env ENV=prod, thenmake provider-login, thenmake initto bring up the Terraform backend. - Run
make build-and-uploadandmake copy-public-buildsto push the orchestrator images. - Populate GCP Secrets Manager by hand with your Cloudflare token and Postgres connection string.
- Run
make plan-without-jobsfollowed bymake apply. - Run
make planandmake applya second time once TLS certificates are ready. - Run
make prep-clusterto 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.
Operator note (first-hand): I fetched the current E2B billing, pricing, and infra pages with the experiment harness. All four source requests returned HTTP 200. The billing page lists 20 concurrent sandboxes on Hobby, 100 on Pro, a Pro add-on ceiling of 1,100, a 24-hour Pro runtime cap, and a 5-per-second Pro creation rate. This is a documentation check, not a paid sandbox run.
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).
E2B pricing: free tier, Pro, and per-second rates
E2B bills a monthly floor plus per-second compute, so the sticker price and the real bill are different numbers. Hobby is free and includes $100 of one-time credits. Pro costs $150/mo, includes no additional credits, and raises the concurrent-sandbox allowance from 20 to 100. The current billing page lists Enterprise as custom-quoted (Source: E2B Billing & Limits).
| Plan | Base price | One-time credits | Max continuous runtime | Concurrent sandboxes |
|---|---|---|---|---|
| Hobby | $0/mo | $100 | 1 hour | 20 |
| Pro | $150/mo | None | 24 hours | 100, expandable to 1,100 |
| Enterprise | Custom | Custom | Custom | 1,100+ |
The same billing page lists 8 vCPUs and 8 GiB of memory on Hobby, 10 GiB of Hobby disk, 20 GiB of Pro disk, 20 concurrent template builds on both plans, and creation rates of 1 sandbox per second on Hobby and 5 per second on Pro. Those are limits, not a promise that a workload will receive that capacity (Source: E2B Billing & Limits).
Compute meters per second on top of that floor and the vCPU rate scales linearly: $0.000014/s at 1 vCPU, $0.000028/s at 2, $0.000056/s at 4, $0.000084/s at 6, and $0.000112/s at 8. RAM adds $0.0000045 per GiB per second from 512 MiB to 8,192 MiB, while the pricing page lists 10 GiB free on Hobby and 20 GiB free on Pro (Source: e2b.dev Pricing).
A reproducible workload model
I ran the cost model with 2 vCPUs, 2 GiB of RAM, and a 730-hour month. It multiplies active seconds by the published CPU and RAM rates, then adds the Pro base price. It does not model startup time, idle auto-pause, storage beyond the included allowance, discounts, taxes, or the operational cost of self-hosting.
| Workload assumption | Usage cost | Pro total |
|---|---|---|
| One sandbox, 730 hours, 2 vCPU + 2 GiB | $97.236/mo | $247.236/mo |
| 10,000 executions/mo, 60 seconds each | $22.20/mo | $172.20/mo |
| 100,000 executions/mo, 60 seconds each | $222/mo | $372/mo |
| 1,000,000 executions/mo, 60 seconds each | $2,220/mo | $2,370/mo |
Operator note (first-hand): with 2 vCPUs, 2 GiB, and 730 hours, the harness measured $73.584 in CPU, $23.652 in RAM, $97.236 in usage, and $247.236 after adding the Pro base. This is arithmetic against the live rates, not a live sandbox bill.
Operator note (first-hand): I reran the same harness for 10,000, 100,000, and 1,000,000 monthly executions at 60 seconds each. The modeled Pro totals were $172.20, $372, and $2,370 respectively. These scenarios expose the workload assumption behind the phrase "high volume"; they are not throughput measurements.
The model puts the managed-to-self-hosted comparison on one axis. A self-hosted deployment still needs its own capacity test for startup latency, queueing, failure recovery, and utilization. The separate cost calculator should be used to change execution duration, CPU, memory, and monthly volume without turning this article into a calculator interface.
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).
| Dimension | 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-s | Your cloud bill (no metering) |
| Setup time | Minutes (API key) | Half a day to a day, first attempt |
| Session cap | 24h (Pro) | None enforced by E2B; you manage it |
| Cloud support | N/A (managed) | GCP full, AWS Beta |
| Who it's for | Most teams, variable load | Sustained 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. Under the explicit 2-vCPU, 2-GiB assumption above, the cost model reaches that gap at 8,258.2583 active sandbox-hours per month, before operations and reliability are priced (Inference: computed from the published per-second rate and the article's $1,250 infrastructure assumption). That is the high-volume territory AgenticWire's own Search Console data is beginning to surface, 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.
For high-volume planning, separate the hard limits from the cost floor. E2B self-hosting removes the managed session cap and shifts concurrency, node sizing, database capacity, and upgrades to your team; it does not make the minimum GCP footprint free. Compare sustained CPU and memory demand with the roughly $1,250/mo floor before moving from the $150/mo cloud tier.
E2B limits for high volume workloads
Three limits govern high-volume E2B use. The managed cloud caps concurrency at 100 sandboxes by default, expandable to 1,100, alongside a 24-hour session cap (Source: e2b.dev Pricing). Self-hosting removes E2B-enforced concurrency and session limits, but replaces them with a hard GCP quota floor of 2,500 GB SSD and 24 CPUs before Terraform will provision anything (Source: E2B Self-Host Guide). The AWS path stays Beta with a fixed, heavier node pool rather than production-grade autoscaling (Source: E2B Infra GitHub Repository).
Related coverage
- LLM VRAM Calculator: RAM, Quantization, and Model Fit
- Claude Agent SDK vs Claude Code: Same Engine, Different Use Case
References
- Beam Best E2B Alternatives - https://www.beam.cloud/blog/best-e2b-alternatives
- E2B Billing & Limits - https://docs.e2b.dev/billing
- E2B Infra GitHub Repository - https://github.com/e2b-dev/infra
- E2B Self-Host Guide - https://raw.githubusercontent.com/e2b-dev/infra/main/self-host.md
- e2b.dev Pricing - https://e2b.dev/pricing
- Northflank Self-Hostable Alternatives to E2B - https://northflank.com/blog/self-hostable-alternatives-to-e2b-for-ai-agents




