Architecture: Where should Vitto execute sandbox/VM operations — locally i...

Documentation for Sessions

🏗️ Architecture: Where should Vitto execute sandbox/VM operations — locally i...

Date: 2026-03-26
Time: 17:14:16 UTC
Session: gspace1-271.17
Agent: backend
Confidence: 90%
Status: ✅ Documented

📋 Decision Context

Question:

Where should Vitto execute sandbox/VM operations — locally in backend-vitto-api or via backend-ai-api?

Task: Retrospective merge 13836737

🎯 Decision Made

Chosen:

Route VmApiClientService through HTTP to backend-ai-api sandbox proxy (/infrastructure/sandbox/*) with service Bearer auth (BACKEND_API_INTERNAL_TOKEN), matching InfrastructureClientService; remove SandboxVmOperationsService and duplicate providers from vitto; delete libs/libs-api/sandbox-orchestration usage from this path and inline SandboxHandle in vm-api-client.

Options Considered:

Keep in-process SandboxVmOperationsService in vitto
Shared npm package only without HTTP boundary
HTTP delegation to backend-ai-api (chosen)

💭 Reasoning

Root cause: duplicated sandbox orchestration between vitto and ai-api increased drift and maintenance cost. Single owner for sandbox creation/exec on ai-api avoids inconsistent behavior and aligns with the existing sandbox-proxy controller relocation to backend-ai-api. Prevention: keep one HTTP contract for sandbox ops; document BACKEND_AI_API_URL + internal token for any new vitto↔ai sandbox callers.

📁 Files Involved

APIs/backend-vitto-api/src/app/engine/vm/vm-api-client.service.ts
APIs/backend-ai-api/src/app/infrastructure/services/sandbox/sandbox-provider.factory.ts
libs/libs-api/sandbox-orchestration/

🔗 Related

Decision ID: dev_1774545256766_nd4nqp4
Session: 271
Workspace: gspace1

Auto-generated by MCP Smart Consolidation