E2B self-hosting now has two materially different routes. E2B Embed is an open-source, single-machine evaluation stack you can run with Docker Compose on a Linux host with KVM. Bring Your Own Cloud (BYOC) is an enterprise deployment operated with E2B in your AWS or Google Cloud account. The Embed README says explicitly that Embed is for evaluation, not E2B's recommended production pattern. The older Terraform, Nomad, and Consul instructions still found in search results describe a retired repository path; do not use them as the current quickstart.
Which route fits depends on the workload. With variable traffic and no residency requirement, compare E2B pricing for the managed Cloud first: Hobby is free plus usage, while Pro is $150 per month plus usage. A developer proving sandbox behavior should start with Embed on an isolated host, and a production workload that needs a specific cloud account or region should ask E2B about BYOC and its support boundary. These options have different operational and commercial terms, so “self-hosted is cheaper” cannot be inferred from the software license alone.
Which E2B deployment should you choose?
| Route | Intended use | Who operates it | Published price |
|---|---|---|---|
| E2B Cloud Hobby | Small trials, one-hour sessions | E2B | $0 base, $100 one-time credits, then usage |
| E2B Cloud Pro | Managed production with longer sessions | E2B | $150/month plus usage |
| E2B Embed | Local evaluation of the full stack | You | Open-source software; host and operations extra |
| E2B BYOC | Enterprise deployment in your AWS or GCP account | Contract-dependent, confirm with E2B | Custom quote plus usage |
The table separates the two meanings of “self-hosting” that competing guides often collapse. Embed gives you a runnable stack for evaluation, but it is not an endorsed production substitute for BYOC. Cloud gives you a managed service. The public Enterprise page names AWS and GCP BYOC; it does not publish a standard monthly BYOC tariff or a universal support agreement. Ask for those terms in writing before making a cost comparison.
E2B Embed requirements and setup
The current Embed documentation calls for a Linux x86-64 or arm64 host with KVM and 4 KiB memory pages, Docker Engine 27 or newer, and Docker Compose 2.24 or newer. It recommends 12 GiB of memory and 20 GiB of disk. KVM access is the gating requirement: a laptop or cloud VM that lacks nested virtualization may run Docker but fail to launch sandbox microVMs. Verify /dev/kvm and its permissions before spending time on API configuration.
The official Compose quickstart downloads compose.yaml and .env from the current runtime repository and starts the stack with docker compose up -d --wait. For a reproducible evaluation, review those files, pin them to a specific repository commit, and record that commit with the host architecture and Docker versions. Downloading main each time can silently change the stack between runs. The documentation also describes Terraform for GCP and Kubernetes deployment paths; those are separate from the single-host Compose trial.
Before the first sandbox, limit network exposure. The Compose guide warns that multiple ports listen on all interfaces. Only ports 3000, 3001, and 3002 should be reachable by trusted clients; its unauthenticated gRPC service on port 5008 must remain private. Put the host behind a firewall or private network, check actual bound ports, and avoid treating the supplied development configuration as an internet-facing production setup.
All of the above comes from E2B's documentation, so treat it as the starting point for your own proof of concept. A useful one records whether a sandbox starts, executes a command, persists or discards files as expected, and terminates cleanly. It should also measure concurrent starts, host memory, startup latency, and recovery after service restart on your hardware. Those results determine whether the deployment meets your workload; the README alone cannot.
What happened to the Nomad self-hosting guide?
The former E2B infrastructure repository and its archived self-hosting guide documented Terraform, Nomad, Consul, Cloudflare, PostgreSQL, GCP quotas, and an AWS beta path. That guide is useful as history but is not the current Embed procedure. In particular, its 2,500 GB SSD and 24 CPU quota was a requirement for that historical deployment recipe, not a minimum for today's single-host Embed. A cost calculation that turns those quotas into a universal $1,250 monthly floor is misleading.
If an old tutorial tells you to run make set-env, make provider-login, or make prep-cluster, check its repository revision before following it. The present repository puts Embed documentation under runtime/embed. Keep historical deployment assumptions out of a new budget or security review.
E2B Cloud pricing versus self-hosting
E2B's published Cloud pricing separates the plan fee from runtime. Hobby includes a $100 one-time credit, one-hour maximum sessions, and 20 concurrent sandboxes. Pro costs $150 monthly before usage, allows sessions up to 24 hours, and starts at 100 concurrent sandboxes, with paid expansion. Enterprise pricing is custom, with a published $3,000 monthly usage minimum, and BYOC is an Enterprise option. Published compute rates list 2 vCPUs at $0.000028 per running second and 2 GiB RAM at $0.000009 per second; storage and other terms need checking against the plan.
As a worked example, 10,000 sandbox executions lasting 60 seconds each at 2 vCPUs and 2 GiB amount to 600,000 running seconds. At the published CPU-plus-memory rate of $0.000037 per second, that is $22.20 in modeled usage, or $172.20 with the Pro base fee. It excludes storage overages, other charges, tax, discounts, idle time, and any time that falls outside the exact assumption. It is arithmetic, not an E2B invoice or throughput test.
Embed has no published monthly infrastructure floor. Your bill depends on the actual host, disks, networking, backups, and staff time. BYOC has custom commercial terms. To compare fairly, measure sandbox-hours and peak concurrency, then request a BYOC proposal and price an Embed host sized from a load test. Do not compare an untested single VM with a managed service-level commitment as though they provided the same reliability.
E2B limits, concurrency, and production readiness
The limits page sets them by plan: Hobby runs 20 sandboxes at once and creates 1 per second, Pro runs 100 and creates 5 per second, and paid add-ons lift Pro to 600 or 1,100 concurrent sandboxes. Each add-on costs $500 a month and adds 500 concurrent slots. Enterprise sets custom limits above that.
| Plan | Concurrent sandboxes | Sandbox creation rate | Max continuous runtime | Monthly fee before usage |
|---|---|---|---|---|
| Hobby | 20 | 1 per second | 1 hour | $0, with $100 one-time credit |
| Pro | 100 | 5 per second | 24 hours | $150 |
| Pro with one add-on | 600 | 5 per second | 24 hours | $650 |
| Pro with two add-ons | 1,100 | 5 per second | 24 hours | $1,150 |
| Enterprise | 1,100 and up | Custom | Custom | Custom, $3,000 minimum |
Two details change how you plan for high volume. The runtime limit is time a sandbox runs without being paused, not a cap on how long it can exist. Read API endpoints such as listing sandboxes are limited to 10 requests per second per endpoint on Hobby and 20 on Pro; over that, E2B returns HTTP 429 with a Retry-After header, and the SDKs retry automatically from version 2.49.1. Higher API limits come through support, and custom concurrency, creation rates, and API limits through Enterprise sales.
On production readiness, E2B's security FAQ states that it has a SOC 2 Type II report, runs managed sandboxes as Firecracker microVMs on Google Cloud, and offers an EU cluster from the Pro tier. I could not find a published uptime SLA on the pricing page or in the docs, so request one in writing before relying on E2B for a customer-facing workload.
Network controls matter for agents that run untrusted code. Every sandbox has outbound internet by default; the internet access docs show how to turn it off with allow_internet_access=False in Python or allowInternetAccess: false in JavaScript, or restrict it with allow and deny lists. Routing egress through your own SOCKS5 proxy is in private beta, and E2B does not offer static egress IPs on any plan.
A production evaluation checklist
Use the following questions in a proof of concept or BYOC sales discussion. They cover the gaps left by a simple “open source versus SaaS” comparison:
- Which route is supported for production, and who patches the host, microVM runtime, API, and database?
- Where do sandbox code, logs, templates, and secrets reside, and what crosses the E2B control plane? Ask E2B to document the exact BYOC boundary.
- Can the target host expose KVM and launch the required number of sandboxes under load? Record startup latency and failure rates.
- Which ports are reachable, especially the unauthenticated gRPC endpoint called out by the Compose guide?
- What are the contracted limits, support response, upgrade process, and full monthly charges at the expected sandbox-hours?
FAQ
Can you self-host E2B?
Yes. E2B Embed provides an open-source evaluation stack that runs on your Linux host with KVM. E2B also offers enterprise BYOC deployment, which its BYOC docs list for AWS, Google Cloud, and Azure. Embed's README says it is for evaluation, so production teams should confirm whether BYOC or another supported arrangement meets their security and operational requirements.
Is E2B self-hosting free?
The Embed software is open source, but a suitable KVM host, storage, network security, operations, and maintenance still cost money. There is no universal infrastructure price for Embed. BYOC is an enterprise offering with custom pricing; request the full commercial and support terms before comparing it with Cloud Pro.
Does E2B have a free tier?
Yes. The Hobby plan has no monthly fee, needs no credit card, and includes a one-time $100 usage credit. It allows up to 20 concurrent sandboxes and sessions of up to one hour. After the credit runs out you pay usage at $0.000014 per vCPU-second and $0.0000045 per GiB-second of RAM.
Related coverage
References
- Archived E2B Self-Host Guide - https://raw.githubusercontent.com/e2b-dev/runtime/36055e101aa61474312dda14134de4e33c5acfa1/self-host.md
- E2B Compose README - https://github.com/e2b-dev/runtime/blob/main/embed/compose/README.md
- E2B Embed README - https://github.com/e2b-dev/runtime/blob/main/embed/README.md
- E2B Enterprise - https://e2b.dev/enterprise
- E2B Limits - https://docs.e2b.dev/sandbox/rate-limits
- E2B Pricing - https://e2b.dev/pricing
