Architecture: How to implement self-hosted sandbox infrastructure replacin...

Documentation for Sessions

πŸ—οΈ Architecture: How to implement self-hosted sandbox infrastructure replacin...

Date: 2026-02-27
Time: 13:48:10 UTC
Session: gspace1-150.2
Agent: orchestrator
Confidence: 92%
Status: βœ… Documented


πŸ“‹ Decision Context

Question:

How to implement self-hosted sandbox infrastructure replacing E2B Cloud for Computer Use?

Task: Build self-hosted Firecracker sandbox infrastructure replacing E2B Cloud


🎯 Decision Made

Chosen:

Firecracker microVM-based Sandbox Orchestrator: NestJS API (APIs/sandbox-orchestrator/) managing Firecracker VMs with SSH-based xdotool/scrot commands, TAP bridge networking (172.16.0.0/24), VNC streaming proxy, API key auth, TTL cleanup, Prometheus metrics. Rootfs built via Dockerfile→ext4 export. Deployed on Hetzner AX41-NVMe bare metal ($46/mo).

Options Considered:

  1. Firecracker microVMs with SSH (chosen)
  2. Docker containers with docker exec
  3. QEMU/KVM full VMs
  4. Kata Containers (VM-level isolation, Docker interface)
  5. Keep E2B Cloud

πŸ’­ Reasoning

  1. SandboxProvider abstraction (Session 144) makes backend completely agnostic β€” zero changes to ComputerUseLoopService needed. 2. SelfHostedProvider HTTP client was already implemented, just needed API key auth + retry logic. 3. Firecracker chosen over Docker per user preference β€” stronger isolation (AWS Lambda uses it), custom kernel, hardware-level VM boundaries. 4. SSH for VM communication is pragmatic v1 (can optimize to vsock later). 5. Bridge+TAP networking gives VMs internet access while isolating from host. 6. Per-session VM model (Session 140) carried forward β€” each Computer Use session gets isolated Firecracker VM. 7. $46/mo flat vs $150+/mo E2B Pro, unlimited sessions, custom Chrome extensions, full data sovereignty.

πŸ“ Files Involved


πŸ”— Related


Auto-generated by MCP Smart Consolidation