Architecture: How should the Vitto API Railway deployment be fixed after d...

Documentation for Sessions

🏗️ Architecture: How should the Vitto API Railway deployment be fixed after d...

Date: 2026-02-07
Time: 21:52:35 UTC
Session: editor2-98.3
Agent: backend
Confidence: 95%
Status: ✅ Documented

📋 Decision Context

Question:

How should the Vitto API Railway deployment be fixed after discovering all wrong values from backend-ai-api?

Task: Vitto API Railway Production Deployment Audit

🎯 Decision Made

Chosen:

Write comprehensive v2 handoff with 3 blockers (railway.toml wrong values, main.ts PORT bug, env vars wrong/missing) + 7 additional issues, organized by priority with exact copy-paste configs

Options Considered:

Quick fix just railway.toml
Fix railway.toml + main.ts only
Comprehensive handoff with all issues and exact configs

💭 Reasoning

Full Railway dashboard audit revealed the railway.toml on deploy/vitto-api branch was copied directly from backend-ai-api with ALL wrong values: wrong Dockerfile path, wrong start command, wrong healthcheck, wrong watch paths. Additionally, env vars in the dashboard are from backend-ai-api (e.g., MONGODB_CONNECTION_STRING instead of VITTO_MONGODB_URI) and critical vars are missing (RAILWAY_ENVIRONMENT, SYSTEM_TOKEN). The main.ts also needs isRailway detection for PORT binding. Organized as 3 BLOCKERS that must be fixed before deployment can succeed, plus 7 additional issues for infrastructure completeness.

📁 Files Involved

docs/english/Handoffs/HANDOFF-VITTO-RAILWAY-PRODUCTION-SETUP.md
apis/backend-vitto-api/src/main.ts
railway.toml
.railway/projects.json

🔗 Related

Decision ID: dev_1770501155735_44by15c
Session: 98
Workspace: editor2

Auto-generated by MCP Smart Consolidation