E2B vs semantic
E2B runs each sandbox in a Firecracker microVM with its own kernel. [1] You can use E2B Cloud, a BYOC deployment in your AWS, GCP or Azure account, or Embed, which runs the full stack on one Linux machine. [2][3]
Both products isolate agents in microVMs and keep credentials out of the sandbox: E2B's egress proxy injects secrets into outbound HTTPS requests outside the sandbox. [5] The difference is what happens inside: Semantic decides which paths, repos, branches and SSH hosts the agent may use, and records every action and refusal in a hash-chained log.
| E2Bmanaged cloud · BYOC · Embed | Semantic (smx)microVM + policy on your machines | |
|---|---|---|
| Isolation | Firecracker microVM, own kernel [1] | One microVM per agent, own kernel |
| Where it runs | E2B Cloud; BYOC on AWS, GCP, Azure; Embed on one Linux host [2][3] | Managed private beta; on-prem for enterprise (contact us) |
| Egress rules | allowOut / denyOut lists of domains, IPs and CIDRs [4] | Security profiles enforced by host firewall; metadata and link-local always closed |
| Credentials kept out | Egress proxy injects secrets outside the sandbox [5] | Git tokens, SSH keys and model sign-ins stay on the host |
| File, Git, SSH permissions | not documented | Per path, repo, branch and SSH host; deny beats allow; enforced on the host |
| Tamper-evident agent log | not documented (sandbox logs and events) [6] | Hash-chained log of runs, events and refusals; read with smx agent logs |
| Snapshots, pause/resume | Pause keeps filesystem and memory; snapshots and fork [7] | Snapshot, pause and resume with memory, disk and running processes |
| Local hosts (Linux / WSL2 / macOS) | Linux with KVM via Embed; WSL2 and macOS — [3] | Linux (KVM) and Windows via WSL2; macOS planned |
| License | Runtime and Embed under Apache-2.0 [3] | Proprietary (private beta) |
Which one fits
When E2B fits better
- You want a runtime that self-hosts on one Linux machine with no account. [3]
- You want paused sandboxes that keep memory, and forks of a running sandbox. [7]
- You want E2B to run the fleet for you, in their cloud or your VPC. [2]
When Semantic fits better
- Agents work on your repos and you need branch-level Git and per-path file permissions enforced outside the agent.
- You need a tamper-evident log of what the agent did inside the sandbox, including refusals.
- Developers run sandboxes on WSL2 as well as Linux.
Egress and secrets
E2B filters egress with allow and deny lists; allow rules win over deny rules, and domain filtering covers HTTP on port 80 and TLS on port 443. [4] Secrets are injected by the egress proxy, so the sandbox never holds them. [5]
Semantic sets egress with security profiles enforced by host firewall rules outside the microVM, with a floor (cloud metadata, link-local, other sandboxes) that no profile can open. Git tokens and SSH keys stay on the host; the host performs the allowed Git or SSH action for the agent.
What gets logged
E2B exposes sandbox logs and lifecycle events through its API. [6] Semantic appends every agent run, event, session and control action to a hash-chained log; smx agent logs shows each run's events and refusals.
Questions
Is E2B open source?
Yes. The runtime and Embed are Apache-2.0 and need no account or license key. [3]
Can E2B run locally?
Yes, on a Linux host with KVM through Embed. [3] Semantic runs on Linux and Windows via WSL2 today; macOS is planned.
Does E2B restrict which Git branches an agent may push to?
Its Git integration docs describe no such policy. [8] In Semantic, a policy like push: {branches: ["agent/**"]} refuses a push to main and logs the refusal.
Sources
- E2B security and compliance · last verified 2026-10-27
- E2B BYOC · last verified 2026-10-27
- Introducing E2B Embed · last verified 2026-10-27
- E2B internet access · last verified 2026-10-27
- E2B secrets · last verified 2026-10-27
- E2B sandbox events API · last verified 2026-10-27
- E2B persistence · last verified 2026-10-27
- E2B Git integration · last verified 2026-10-27