🏗️ Architecture: Should backend-ai-api move from Railway to Hetzner to elimin...

Date: 2026-03-20
Time: 18:33:13 UTC
Session: gspace1-246.8
Agent: backend
Confidence: 88%
Status: ✅ Documented

📋 Decision Context

Question:

Should backend-ai-api move from Railway to Hetzner to eliminate the ~850ms RTT on every VM operation?

Task: Not specified

🎯 Decision Made

Chosen:

Not now. Use command batching to reduce HTTP round-trips first (3-7s savings per task, ~80 lines of code). Revisit Hetzner migration after AX102-U is stable and VM-heavy features (self-healing, visual debugging) prove the latency is a real bottleneck at scale.

Options Considered:

1. Move backend-ai-api to Hetzner now
2. Move ALL backends to Hetzner now
3. Implement command batching first, migrate later (chosen)
4. Do nothing (keep 850ms RTT)

💭 Reasoning

Moving backend-ai-api to Hetzner eliminates ~850ms RTT per VM call (425x improvement if all backends co-locate). BUT: it adds operational burden (self-managed SSL, Redis, monitoring, deployment), loses Railway's zero-ops benefits, and the latency only affects VM operations (not generation, chat, or platform CRUD). Command batching achieves 80% of the benefit with 1% of the effort. Railway → Hetzner migration should be a considered decision after proving the need, not a premature optimization. MongoDB Atlas works from either location (just whitelist IPs).

📁 Files Involved

• APIs/backend-ai-api/src/main.ts
• APIs/backend-vitto-api/src/app/engine/vm/sandboxed-tool-proxy.service.ts
• APIs/backend-vitto-api/src/app/engine/vm/vm-api-client.service.ts
• APIs/backend-ai-api/src/app/infrastructure/services/sandbox/self-hosted.provider.ts

🔗 Related

• Decision ID: dev_1774031593570_bp1vyz6
• Session: 246
• Workspace: gspace1

Auto-generated by MCP Smart Consolidation