0006 — API + admin portal deploy to Railway

• Status: accepted
• Date: 2026-05-06
• Deciders: Derek

Context

The API and admin portal are stateful-ish (websocket-friendly, long-running connections, file streaming). They need a node host with predictable behavior, ergonomic deploys, and low ops overhead for a one-engineer team.

Internalize already runs on Railway and the operator experience has been good.

Decision

Single Railway project running the API + admin portal. Single instance to start. Auto-deploys from the main branch.

Consequences

Easier:

• Known-good ops experience (lifted from internalize)
• Long-running connections (realtime) work without edge-runtime adaptation
• Logs, metrics, env management all in one place
• A single instance is fine until we have ~100s of orgs

Harder:

• Single-region by default; tenants outside the region see slightly higher latency (mitigated: most ops are static-site-served on Cloudflare’s edge anyway)
• Scaling vertically up to a point, then we need to think about horizontal scaling (this is a future-tense problem)

Revisit if: API request volume sustains above 80% of vertical capacity for a week, or a tenant in a different region complains about latency.

Alternatives considered

• Fly.io / Render. Equivalent; Railway is what we know and the tooling is comfortable.
• Cloudflare Workers (edge runtime). Wrong shape for stateful realtime. Eliminated by ADR 0003.
• Self-managed VPS. More operational burden than a one-person team can carry while building features.