Architecture: Should Firecracker VMs be per-session (current) or per-user ...
Documentation for Sessions
🏗️ Architecture: Should Firecracker VMs be per-session (current) or per-user ...
Date: 2026-02-27
Time: 18:35:29 UTC
Session: gspace1-150.9
Agent: storage
Confidence: 88%
Status: ✅ Documented
📋 Decision Context
Question:
Should Firecracker VMs be per-session (current) or per-user persistent (Jarvis vision) or dual-layer?
Task: Per-user vs per-session VM model for Jarvis-like Vitto experience
🎯 Decision Made
Chosen:
Recommended: Per-user persistent Home Machine with Firecracker snapshots for v1 (sequential tasks, Chrome profile persistence, snapshot-on-idle/restore-on-demand). Add ephemeral Task VM forking from Home snapshot in v2 for parallel execution. Per-session-only model (Session 140) was correct for solving concurrency isolation but wrong for the Jarvis product vision.
Options Considered:
- Per-user persistent Home Machine with snapshots (v1 recommended)
- Per-session only (current, Session 140)
- Dual-layer Home + Task VMs from day one
- Per-user persistent with task locking (no parallel)
💭 Reasoning
ROOT CAUSE: Per-session model (Session 140) solved a concurrency problem (parallel tasks fighting over same mouse/focus) but created a product problem — every task starts cold with no user context. For Jarvis-like experience, Vitto needs persistent Chrome profiles (saved logins, cookies, extension config), pre-warmed browsers, and accumulated browsing context. Firecracker natively supports VM snapshots (CreateSnapshot/LoadSnapshot API) which enables suspend-on-idle (releases RAM) and near-instant restore (2s). The v1 recommendation is per-user persistent VM with sequential task queuing — simpler than dual-layer, delivers 90% of the Jarvis value. Dual-layer (persistent Home + ephemeral Task forks) is v2 when parallel execution demand is proven. CAPACITY IMPACT: 64GB server supports ~30 active Home Machines or ~15-20 if dual-layer with parallel tasks. Snapshot storage: ~2GB per user on NVMe. SECURITY CONCERN: Persistent Chrome profiles are high-value targets — require at-rest encryption and strict Firecracker jailer isolation. WHAT WOULD MAKE THIS WRONG: If most users need heavy parallelism day-one → dual-layer becomes mandatory immediately.
📁 Files Involved
APIs/sandbox-orchestrator/src/app/sandbox/sandbox-manager.service.tsAPIs/sandbox-orchestrator/src/app/sandbox/firecracker.service.tsAPIs/backend-ai-api/src/app/infrastructure/services/e2b-desktop.service.ts
🔗 Related
- Decision ID:
dev_1772217329458_ydz6x0d - Session: 150
- Workspace: gspace1
Auto-generated by MCP Smart Consolidation