What you gain and what you give up
The gain is legibility. Railway publishes per-second metering, its pricing page lists $0.00000772 per vCPU-second, $0.00000386 per GB-second of memory, $0.00000006 per GB-second of volume storage and $0.05 per GB of egress, and shows a projected cost before you deploy rather than after the month closes. The loss is equally concrete: preview environments are less polished than a frontend-first platform, and there is no equivalent global edge network. Decide whether your team uses previews every day or merely has them, because that single answer decides most of this migration.
The plan structure, so you can model it
Railway's pricing page lists a Free plan at $0 a month including $1 of monthly usage credits, Hobby at $5 a month including $5 of credits, and Pro at $20 a month per workspace including $20 of credits, with a 30-day trial carrying $5 in credits. Note the shape: the plan fee includes the same value back as usage, so for small workloads the subscription is effectively a floor rather than an addition. That is a materially different structure from a per-seat subscription with meters stacked on top of it, and it is why small teams often see the difference immediately.
Step one: get the application building
Connect the repository and let the platform detect the stack. Applications with a Dockerfile build from it; most common frameworks are detected automatically without one. Confirm the build command and start command are what you expect, because this is where inherited platform-specific configuration surfaces. If your application depends on a build step that a previous platform performed implicitly, this is the moment it becomes visible, and it is far better to find it here than after DNS moves.
Step two: environment variables and services
Export the full variable set from the old platform and import it, then read it once with fresh eyes: migrations are the best opportunity you will get to delete credentials nobody uses and rotate the ones that have been sitting in a dashboard for two years. Attach databases and caches as services in the same project so internal networking connects them without traversing the public internet, which matters because egress is billed per gigabyte and internal traffic between services is not the same thing as traffic leaving the platform.
Step three: the things the old platform did invisibly
This is where migrations actually stall, and it is never the application. Scheduled jobs, background workers, queue consumers, and anything that ran because a previous platform offered it as a feature all need explicit homes. Inventory them before cutting over by asking what runs without a request triggering it. A cron job nobody documented is the single most common cause of a migration that appeared complete and was not.
Step four: domains, certificates and the cutover
Add the custom domain, let certificates issue, and verify the application answers correctly on the new hostname before changing anything in DNS. Lower the DNS time-to-live a day in advance so the switch propagates quickly and a rollback is equally quick. Then move traffic and watch error rates rather than watching the dashboard, because the failures that matter show up as exceptions in your application, not as red text in a console.
Step five: right-size, because per-second billing rewards it
Once traffic is stable, revisit resource allocation. Continuous metering means an over-provisioned service bills for capacity every second it is idle, and it also means scaling down is immediately reflected rather than waiting for a billing boundary. Development and staging environments are the obvious first target: environments that spend most of their lives asleep are exactly where per-second billing pays for the migration.
When Railway is not the right destination
If your site is mostly static and served worldwide, a platform built around an edge network will serve it better and often cheaper, and if your priority is the absolute lowest bill rather than a managed experience, a self-hosted open-source platform on a fixed-price server goes further. Railway is the strongest answer for a compute-bound application whose owner wants a predictable, legible invoice without becoming an operations team.
Reader comments
No account needed. Share what worked, what did not, and what you would add.
Add a quick note with the form below. Short, specific tips help the next reader most.