I built exec-sandbox because I wanted VM-level isolation for AI-generated code on my Mac without running Linux in a VM first.
Most sandboxes (E2B, Hopx) use https://firecracker-microvm.github.io/, on macOS, you need nested virtualization. exec-sandbox uses QEMU with Apple's Hypervisor.framework (HVF) and runs natively on macOS, including Apple Silicon.
What makes it different:
- Native macOS + Linux, no Docker, no nested VMs, just brew install qemu
- 1-2ms warm start, pre-started VM pool beats E2B's 150ms cold start
- Port forwarding without network, expose localhost:8080 while blocking all outbound (DNS + IP)
- Domain allowlisting, allowed_domains=["api.github.com"] for granular control
- CLI for automation, sbx run *.py -j 10 --json with concurrency control
- Package validation, blocks typosquatting against PyPI/npm top 10k
- Self-hosted, no session limits, unlike E2B's 24-hour cap
clemlesne|1 month ago
Most sandboxes (E2B, Hopx) use https://firecracker-microvm.github.io/, on macOS, you need nested virtualization. exec-sandbox uses QEMU with Apple's Hypervisor.framework (HVF) and runs natively on macOS, including Apple Silicon.
What makes it different:
- Native macOS + Linux, no Docker, no nested VMs, just brew install qemu
- 1-2ms warm start, pre-started VM pool beats E2B's 150ms cold start
- Port forwarding without network, expose localhost:8080 while blocking all outbound (DNS + IP)
- Domain allowlisting, allowed_domains=["api.github.com"] for granular control
- CLI for automation, sbx run *.py -j 10 --json with concurrency control
- Package validation, blocks typosquatting against PyPI/npm top 10k
- Self-hosted, no session limits, unlike E2B's 24-hour cap
7-layer security: hardware virtualization, unprivileged QEMU, seccomp, cgroups v2, namespaces, AppArmor/SELinux, socket authentication.
https://github.com/dualeai/exec-sandbox