Dora NodaRailway's pricing FAQ now answers the question "I prefer to prepay. Is that possible?" with a single sentence: not anymore — as of March 30th, Railway requires the use of a post-paid card. No announcement tour, no migration guide, just a closed door where the low-commitment on-ramp used to be.
If you're running production workloads on Railway and have been vaguely meaning to evaluate owned infrastructure, this is the signal to stop being vague. Not because post-paid billing is bad — it isn't — but because of what it does to your switching cost: a prepaid balance is money you've already handed over, and leaving means walking away from it or grinding through a spend-down. A post-paid card is month-to-month freedom, so the same billing change that makes Railway harder to try casually makes it easier to leave deliberately — a window worth using on purpose.
Here is the part that decides whether this post earns your next five minutes. For a boring, typical workload — a Node.js API plus Postgres, 1GB RAM, under 1 vCPU, 5GB disk, 10GB egress — Railway bills roughly $26/month in metered usage, while the same workload fits on a flat-rate box for roughly $5/month. I recomputed that line by line in September's pricing census, so I won't redo the arithmetic here. The question this post answers is different: given that gap, what does the death of prepaid change about when you move — and what should you do this week?
The news in one paragraph
The current Railway billing picture, all from Railway's own pricing docs: new signups get a one-time $5 trial grant, then land on plans of Free ($0, with $1 of monthly usage credit), Hobby ($5/month including $5 of usage), or Pro ($20/month including $20 of usage). Metered rates run $10/GB-month of RAM, $20/vCPU-month of CPU, $0.05/GB of egress, and $0.15/GB-month of volume storage.
The prepaid change sits on top of that ladder. Customers still paying from a credit balance are on a wind-down path: when the balance hits zero, the subscription is cancelled, deployments stop, and nothing runs again until they top up and sign up for a new subscription. Railway only accepts credit cards for plan subscriptions now, with custom invoicing reserved for Enterprise. And the docs are candid about the enforcement machinery — partial-month charges exist to keep accounts "in good standing" and to "mitigate risk and fraud."
That last phrase is doing a lot of work. It also has a history.
Why vendors kill the on-ramp: abuse economics
Railway's entry funnel has been tightening in stages, and each stage has the same stated cause. The pattern is worth seeing whole:
| Stage | What changed | Stated cause |
|---|---|---|
| Heroku, Nov 2022 | Free dynos and free Postgres/Redis eliminated | Teams spending "an extraordinary amount of effort to manage fraud and abuse" |
| Railway, Jul 2023 | Original free tier killed; $5 one-time trial replaces recurring credits | Crypto miners and torrent bots abusing free compute |
| Railway, early 2026 | Prepaid credits removed; post-paid card required | Risk and fraud mitigation |
Heroku's 2022 announcement is the template: Salesforce's platform killed free plans on November 28, 2022, explicitly citing the cost of combating fraud and abuse. Railway followed the same arc a year later — by mid-2023 it had grown past 300,000 users on the back of its generous recurring $5 credits, and the abuse economy noticed. Crypto miners don't care about your deploy experience; they care that free compute exists. When SaaS Price Pulse's pricing history (verified against Railway's pricing page in March 2026) summarizes the arc as "from deploy anything free to a tiered usage-based platform where even the cheapest plan costs money," the through-line is that every low-commitment on-ramp eventually gets priced at exactly what it costs to keep miners out.
Prepaid credit is a subtler on-ramp than a free tier, but it has the same abuse surface: stored balances, topped up with stolen cards or promotional stacking, are harder to claw back than a post-paid charge you can decline to settle. A post-paid card on file means every dollar of abuse passes through a card network's fraud machinery before Railway eats it. From the vendor's side, this is unambiguously rational. From your side, it's information — the third row in a table that keeps growing in one direction.
The part that matters: your switching cost just changed shape
Here is the core argument, stated plainly: prepaid balances are lock-in, and post-paid billing is an exit ramp. Not intentionally — Railway isn't trying to make leaving easy — but structurally.
When your money sits in a vendor's credit balance, leaving has a psychological and financial tollbooth. The remaining balance is sunk cost: migrate now and you either forfeit it or keep a zombie project running to spend it down. Teams routinely delay migrations by a quarter or more "until the credits run out," which is another way of saying the vendor holds an interest-free loan that also functions as a retention mechanism. And the wind-down mechanics punish inattention — hit zero and workloads stop — so the rational move under prepaid is to keep topping up, which keeps the balance, which keeps the tollbooth.
A post-paid card inverts all of this. Your commitment horizon shrinks to the current billing cycle: no balance to protect, no spend-down to schedule, no forfeiture to dread. Leaving costs exactly one month's usage plus the migration work itself. If you were ever going to evaluate owned infrastructure, the billing model just removed the one friction that had nothing to do with engineering.
Now pair that with the cost anchor from the top of this post:
| Railway (metered) | Owned flat-rate box | |
|---|---|---|
| Same Node + Postgres workload | ≈ $26/mo | ≈ $5/mo |
| Billing commitment | Monthly, post-paid, walk away anytime | Monthly, flat, walk away anytime |
| What's bundled | Managed Postgres, TLS, deploys, someone else's pager | Raw capacity; operations are yours |
Two honest caveats before anyone screenshots that table. First, the $5 box buys capacity, not operations — backups, patching, TLS renewal, and the 3 a.m. page are yours, and that labor is real. Second, the meter earns its keep for bursty workloads: an app running 30% of the time drops Railway's bill toward the $5 floor, while flat pricing charges for capacity whether you use it or not. So the migration case is strongest for the modal small workload — steady-state, always-on, boring — where the meter taxes forgetting that capacity got cheap.
The synthesis: your exit friction just hit its structural minimum at the same time the price gap is public and quantified. Billing-model changes don't come with a "migrate now" banner. This is what one looks like.
A migration-timing checklist: is this your quarter to move?
Not every Railway team should migrate, and "someday" is where migrations go to die. Run these five checks honestly; each has a concrete threshold, not a vibe.
| # | Check | Threshold that says "move" |
|---|---|---|
| 1 | Your bill shape | Steady-state usage within ±30% month over month — the meter isn't saving you anything over flat capacity |
| 2 | Prepaid balance remaining | Under one month of usage, or already on post-paid — no sunk balance anchoring you |
| 3 | Data gravity | Volumes and databases you can snapshot and reimport in an afternoon; note Railway deletes volume data 30/60/90 days after plan expiry (Free/Hobby/Pro), so the clock is knowable, not scary |
| 4 | Deploy complexity | Git-push statics and containers with no exotic platform primitives — reproducible on any PaaS-shaped layer in a day |
| 5 | Pager readiness | Someone on the team has been on call before, or the workload can tolerate best-effort availability while you learn |
Score it simply: 3 or more "move" answers means start the migration spike this month, not this half. Five for five means you're paying a premium for inertia and should time-box the move to two weeks. One or zero means Railway's bundled operations are genuinely earning their margin for you right now — re-run the checklist the next time the bill jumps or the funnel tightens again, because the pattern in the table above says it will.
The checklist is deliberately asymmetric: it takes only one structural reason to stay (real burstiness, real pager risk) but a preponderance of small reasons to go. That matches the actual risk profile. Migrating a boring workload to owned infrastructure is reversible in an afternoon; staying on a meter out of inertia compounds every month.
What to do this week
Whatever the checklist says, these four steps take a few hours and expire nothing. Do them before the quarter's urgency arrives:
- Pull a week of real usage. Deploy nothing new — open your workspace's Usage section, let a normal week accumulate if needed, and extrapolate the month. Railway's own cost guidance recommends exactly this: one week of metrics, then extrapolate. You want your actual RAM/CPU/egress split, not the plan name you remember buying.
- Snapshot everything portable. Export environment variables, snapshot volumes, and dump databases while the account is in good standing — not during a cancellation flow. Know your retention window (30 days on Free/Trial, 60 on Hobby, 90 on Pro) and put the expiry date on a calendar you actually read.
- Spike the owned-infra path on one staging service. Not production, not the database — one stateless staging service, git-push to a box you own, TLS terminating, deploy hook wired. Time it. The spike's output isn't a migration; it's a measured number for step 4's decision: "the mechanical path takes N hours per service."
- Set a calendar decision date. The checklist above, re-run on a specific date with the spike's numbers in hand. "We'll evaluate owned infra" without a date is a wish. With a date, it's a plan — and the post-paid billing cycle gives you a natural monthly cadence to attach it to.
None of this requires leaving Railway, cancelling anything, or telling anyone. It converts a vague intention into measured inputs, which is the only thing that ever actually moves a migration forward.
The signal, not the noise
Outages and price hikes are loud migration signals — everyone notices them, everyone writes the postmortem-tweet thread. Entry-funnel tightening is quiet: a FAQ sentence changes, a payment option disappears, and nothing about your running workloads changes at all. But it tells you something an outage never does — the direction the vendor's business is moving, and therefore the direction your future bills are moving.
Railway went from recurring free credits to a one-time trial to post-paid-only in three years. Each step was rational, each step was about abuse, and each step raised the floor under small teams. Your switching cost, meanwhile, just hit its minimum. Use the window deliberately: run the checklist, time the spike, and make the decision on purpose rather than discovering it made itself at the next billing change.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.
