← All decisions

API + admin portal deploy to Railway

accepted

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.