E2B Self Host: Deployment Requirements and Real Costs

Do not index

You can self-host E2B with E2B Embed, its open-source package for running the sandbox stack on one Linux machine with hardware virtualization. This E2B self host guide explains the deployment choices, operating responsibilities, and costs to check before committing. If your goal is inexpensive hosted agent execution rather than operating E2B itself, Agent37 is another option, with separate standard sandbox and full VM runtimes.

The decision starts with what you need to own. Keeping the E2B API inside your environment is different from buying a low-cost machine where your agent can execute code. Both are valid goals, but they lead to different infrastructure and different bills.

Sources checked November 4, 2026. The deployment guidance below follows current upstream documentation; it is not a report of an installation or performance benchmark we ran.

E2B self host: choose the deployment you actually need

E2B's current Embed guide packages the control plane, sandboxes, storage, and telemetry on one node. It supports Docker Compose, Terraform paths for AWS, Google Cloud and Azure, and a Kubernetes installation. The runtime is Apache-2.0, and Embed does not require an E2B account or license key.

That makes self-hosting a real option. You can retain the E2B integration while taking responsibility for its infrastructure. It does not mean every deployment choice has the same operational model.

Choice	Who operates it?	What you are choosing
E2B Embed	Your team	The E2B stack on one machine you control
E2B BYOC	E2B	Sandboxes in your cloud account with E2B operating the service
E2B Cloud	E2B	A managed service without your own sandbox host
Agent37	Agent37	Hosted sandboxes or VMs through a different API

E2B's enterprise deployment page distinguishes BYOC from Embed and lists private cloud separately as in development. Do not treat a self-run node, vendor-operated BYOC, and a fully private multi-node deployment as interchangeable offers.

For an existing E2B application, preserving SDK behavior can matter more than a small difference in compute rates. For a new application, first decide whether you need E2B compatibility at all.

Check the host before writing an install script

Docker being installed is only one prerequisite. Embed runs Firecracker microVMs, so the underlying machine must expose hardware virtualization. A general application container does not become a suitable host simply because it can start another process.

The current Compose requirements recommend 12 GiB RAM and 20 GiB free disk, with Docker Engine 27 or newer and Compose 2.24 or newer. They require Linux, KVM, a 4 KiB-page kernel, and the host devices and tools listed upstream. Architecture matters: arm64 has additional kernel requirements.

These read-only checks can help you inspect a candidate Linux host:

uname -m
uname -r
getconf PAGESIZE
ls -l /dev/kvm /dev/net/tun
docker version
docker compose version
free -h
df -h /

Passing them is not a complete compatibility test. Missing KVM is a reason to revisit the host choice before spending time on application configuration.

Use a dedicated host or VM that your team is allowed to modify. The installer prepares host networking, kernel modules, memory reservations, and data directories. Record those changes in your infrastructure plan so another service does not unexpectedly inherit them.

Size for peak concurrency, including the runtime's own services. Adding together your agents' nominal RAM requests is only a starting point. Template builds, snapshots, caches, and logs also need room.

Pick Compose, Terraform, or Kubernetes deliberately

For a first evaluation on a suitable Linux server, start with the official Compose installation. Keep its Compose file and environment file together. Review a specific upstream revision and retain that revision for reproducibility instead of letting a later download silently change your installation.

The cloud modules provision the host as well as the stack. E2B's AWS module creates one EC2 machine in an Auto Scaling group of one and requires client CIDR restrictions. The GCP module also provisions a single machine. Read the actual resources in the Terraform plan, including storage and networking, before applying it.

Kubernetes fits teams that already operate an appropriate cluster. The Kubernetes guide describes a StatefulSet pinned to one suitable node, with its databases on that node's disk. It is a single-node package. Putting it in Kubernetes does not automatically create a highly available sandbox fleet.

Choose the path your team can recover most confidently. Familiar tooling is useful when an upgrade fails or a host disappears. A successful initial deployment is only the first part of operating the service.

Keep the control plane inside a trusted boundary

Network access deserves its own review before the first external client connects. Embed serves plain HTTP by default. E2B's networking reference identifies ports 3000 and 3002 for SDK access and 3001 for the dashboard; other host-network listeners must remain inaccessible to untrusted peers.

An API key does not protect every service listening on a host. Scope firewall rules to the specific client addresses that need access, and follow the upstream tunneling guidance for remote administration. If traffic must cross an untrusted network, design and validate a protected transport path rather than publishing the default HTTP endpoints directly.

Also separate deployment containment from workload behavior. Running the stack on your machine does not prevent an agent from calling an external model or sending data to a tool you configured. Map those destinations alongside the runtime's download dependencies and your telemetry configuration.

Before serving real users, try an unauthorized connection from outside the allowed network. Confirm that it fails. Then verify the intended SDK path still works. Keep credentials out of support transcripts and shared logs, including installation output that contains an API key.

Prove the lifecycle, not just the dashboard

A dashboard loading in a browser proves very little about an agent execution service. Your acceptance test should exercise the operations your application will depend on.

Start with upstream's packaged smoke test. Then run a representative task: create a sandbox, execute a command, write a file, retrieve the result, and end the sandbox. If your application needs pause and resume, verify both the file and the relevant process state after resuming. If it needs custom templates, test a build and a sandbox created from that build.

The E2B runtime overview explains its snapshot-based lifecycle and the separation between API placement and node execution. Use that architecture to think through failure: the API responding does not guarantee a node can allocate another sandbox.

Try a small burst matching expected concurrency. Measure successful jobs, queueing, memory pressure, and disk growth. Record failures and retries as part of the result. A single successful command is not evidence that a node can serve your production peak.

Make recovery equally concrete. Decide what must survive a restart, what must be backed up off the node, and how you would rebuild after losing its disk. A snapshot on the same failed machine is not an independent backup. Set a recovery objective your team can actually test.

The AWS and GCP module guides explicitly say a replacement instance starts with a fresh disk and rebuilds the base template. Account for your custom templates and saved state before relying on automatic replacement. Plan upgrades around interruption too: restarting Embed's orchestrator ends its running sandboxes. A recovery mechanism can restore service without restoring your application data.

Calculate self-hosting costs at useful capacity

An open-source license removes a software license charge; it does not remove the host bill. Budget the machine, retained disks, backups, network transfer, observability, and the engineering time required to operate them.

Use this planning equation:

Monthly self-hosting cost =
  host compute + retained storage + backups + network + monitoring
  + operating hours x your internal hourly cost

Cost per completed job = monthly cost / successful completed jobs

For illustration, a $100 infrastructure bill plus two hours of work valued at $75 per hour totals $250. At 10,000 successful jobs, that is $0.025 per job. These are hypothetical inputs, not an E2B quote. Substitute your actual cloud estimate and your own operating costs.

Utilization changes the answer. A dedicated node can spread its cost across many concurrent jobs, but empty capacity still costs money. Include peak headroom and failed work. Compare systems using the same completed workload and acceptable latency, rather than assuming identical vCPU counts deliver identical throughput.

For a managed baseline, E2B's published pricing lists $0.000014 per vCPU-second and $0.0000045 per GiB-second. Two vCPUs and 4 GiB total about $9.94 for 60 aggregate running hours, or $120.89 for 730 hours, before plan fees and other charges. Pro adds $150 per month. Its $100 Hobby credit is a one-time allowance, not a recurring infrastructure discount.

Those hosted rates do not become an Embed invoice. For self-hosting, your cloud resources and operating work determine the cost. Our E2B pricing guide examines the managed-service budget in more detail.

When a managed sandbox is the better fit

If you need your agent to run code cheaply and keep its files, operating an entire E2B deployment may add work you do not need. Agent37 provides hosted sandbox infrastructure, including standard gVisor instances and full VMs with their own Linux kernel.

The table below prices one agent workspace, not an E2B Embed host. Both rows use 2 vCPU, 4 GB RAM, and 4 GB disk retained for a full 730-hour month. The 60-hour column assumes compute is stopped or asleep for the remaining hours.

Agent37 runtime	60 running hours, disk retained all month	730 running hours, disk retained all month
Standard gVisor	$0.72	$4.76
Full VM	$1.26	$11.36

Current rates are $0.80 per vCPU, $0.70 per GB RAM, and $0.09 per GB disk per 730 hours. VM compute costs 2.5 times standard compute; disk uses the same rate. Compute bills while awake, including CPU-idle time. Retained disk continues billing during sleep or stop, and model and tool usage is separate.

Standard gVisor instances cannot run a Docker daemon. Full VMs support Docker and KVM, but those capabilities alone do not establish that an untested Embed installation will meet all of its host requirements. The VM documentation also notes that VM entrypoints do not use systemd. The Ubuntu VM template defaults to 12 GB disk, making its 2 vCPU/4 GB example $12.08 for 730 running hours. VM creation requires a funded workspace.

Choose the runtime for your application. Agent37 uses its own API; it is not a drop-in E2B endpoint. Check the instance API, then create a sandbox and measure one representative job before migrating a fleet.

E2B self-hosting questions

Is E2B self-hosting free?

Embed's runtime is Apache-2.0 and does not require an E2B license key. Your server, storage, network, and maintenance still have costs. Compare the complete operating budget with managed service usage.

Can I run it on any VPS?

No. Check the current host requirements, especially KVM, nested virtualization, kernel compatibility, memory, and available disk. A VPS description that says Linux and Docker is not enough evidence.

Does self-hosting preserve the E2B SDK?

Embed is designed to use the same SDK and API as E2B Cloud. Validate your application's actual templates, endpoint configuration, files, and lifecycle operations against your deployment before switching production traffic.

Should I choose Embed or hosted infrastructure?

Choose Embed when controlling the E2B stack is a requirement your team can operate. Choose managed infrastructure when the priority is executing your agents with less infrastructure work. Price the job you need completed, including recovery and maintenance, before choosing either path.