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:

  1. Per-user persistent Home Machine with snapshots (v1 recommended)
  2. Per-session only (current, Session 140)
  3. Dual-layer Home + Task VMs from day one
  4. 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


🔗 Related


Auto-generated by MCP Smart Consolidation