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.

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).

PlanBase priceOne-time creditsMax continuous runtimeConcurrent sandboxes
Hobby$0/mo$1001 hour20
Pro$150/moNone24 hours100, expandable to 1,100
EnterpriseCustomCustomCustom1,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 assumptionUsage costPro 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).

DimensionE2B 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. 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).

References