Repair
The target
- Railway Hobby: 5 USD a month, and that 5 USD is spent as usage credit first (published). Past it, you pay for RAM, CPU and volume by the minute. It is a floor you can predict, not a cap you can hit.
- One service,
cms, in its own project for OS-wide services. It is built from the monorepo’smainbranch on every push, as a Node 22 standalone image. - The data stays on Neon. The service’s
DATABASE_URLpoints at the same database as before.
The cutover, in the order it ran
- Run both side by side. The Railway copy served the same database as the Vercel copy. We compared them response by response — health, users, videos, workshops, auth — and they were byte-identical. Media differed only in the host name inside each URL.
- Give the build a dead database. The build step gets an address that goes nowhere on purpose. If a build ever tries to open a database, it fails at once instead of reaching production.
- Repoint the readers one at a time. The flowingkhaos API, clevrstart, the flowingkhaos site, khaosmedia, luke-sidney, one background task and a few code fallbacks — each moved to the new host, each checked.
- Keep the old copy as a rollback. The Vercel project still builds from
main, idle, until a quiet week has passed.
The rule that changed
Migrations have one runner: a person, by hand, before the deploy. Railway never runs them. The database is shared by every app in the fleet, so an automatic migration on deploy is the wrong default. An additive migration must land before the code that reads the new columns, or every read of that collection fails.
What it cost
| Line | Monthly | Grade |
|---|---|---|
| Railway Hobby plan, usage credit included | 5 USD | published |
| The CMS container’s usage beyond the credit | not yet billed at the time of writing | to be measured |
| The whole box (CMS, API, Postgres, cache) at idle | ≈ 13–19 USD | estimate |
| Neon database | 0 USD | measured |
| Vercel for the CMS | 0 USD, and a pool the other apps get back | measured |