Architecture: Where should sandbox VM operations run for Vitto — HTTP dele...

Documentation for Sessions

🏗️ Architecture: Where should sandbox VM operations run for Vitto — HTTP dele...

Date: 2026-03-26
Time: 17:56:06 UTC
Session: gspace1-271.31
Agent: backend
Confidence: 92%
Status: ✅ Documented


📋 Decision Context

Question:

Where should sandbox VM operations run for Vitto — HTTP delegation to backend-ai-api or in-process in backend-vitto-api with shared @libs-api/sandbox-orchestration?

Task: Record institutional knowledge for commit 00005f89 retrospective


🎯 Decision Made

Chosen:

Extract @libs-api/sandbox-orchestration; remove sandbox proxy from ai-api; implement InfrastructureExecutionModule on vitto-api with VittoSandboxProviderFactory (fleet SANDBOX_SERVERS_JSON or SANDBOX_SERVER_URL) and local VmApiClient → SandboxVmOperationsService.

Options Considered:

  1. Keep VmApiClientService calling BACKEND_AI_API_URL/infrastructure/sandbox with internal Bearer token
  2. Shared lib only; still proxy HTTP through ai-api
  3. Extract @libs-api/sandbox-orchestration; host SandboxProxyController + SandboxVmOperationsService on vitto-api; VmApiClient delegates locally (commit 00005f89)

💭 Reasoning

Root cause of prior pain: duplicate orchestration and an extra network hop between Vitto and ai-api increased latency, token/env coupling, and drift. Single shared types in sandbox-orchestration keep SelfHostedProvider and SandboxPlacementRouter consistent; colocating the proxy with Vitto aligns the agent runtime with the VM boundary it owns. ai-api retains E2B/Playwright/Computer Use factory without hosting the vitto-facing HTTP proxy. Documented risk: snapshot route uses sandboxId while placement may key by sessionId — needs reverse lookup if multi-server snapshot is required.


📁 Files Involved


🔗 Related


Auto-generated by MCP Smart Consolidation