Railway's Hobby and Pro plans have cost $5 and $20 a month since July 2023. Not "roughly the same." Identical — same two numbers, three years running, through a funding round, a platform migration, and a wave of competitor repricing. Render, its closest comparison point, restructured its entire workspace pricing on April 23, 2026: per-seat fees gone, included bandwidth cut, a new per-GB overage rate installed underneath.
The obvious read is that Railway is the stable vendor and Render is the one moving the goalposts. That read isn't wrong, but it's incomplete — and the incomplete version is the one that gets a team burned. A sticker price is just the number printed on the plan page. Whether the bill stays stable depends on what's happening to the rate card underneath it, and that's a different question with a different, less reassuring answer.
The two timelines, side by side
Here's what actually changed, and when, at each vendor:
| Railway | Render | |
|---|---|---|
| Plan fee | Hobby $5/mo, Pro $20/mo — unchanged since July 2023 launch | Per-seat Professional ($19/user) and Organization ($29/user) → flat Hobby $0, Pro $25/mo, Scale $499/mo (April 23, 2026) |
| Compute rate | $20/vCPU-month, $10/GB RAM-month — unchanged since 2023 | Not part of the April repricing; compute rates untouched |
| Egress rate | $0.10/GB (2023 launch) → $0.05/GB today | Flat 100GB bundled → 5GB (Hobby) / 25GB (Pro) bundled, $0.15/GB overage above that |
| Forcing event | None | Aug 1, 2026 — every legacy workspace auto-migrates to the new plan whether the team opts in or not |
Two things are worth flagging before drawing conclusions from this table. First, Railway's rate card didn't just hold flat — the egress rate actually dropped by half. Second, "Render repriced twice" is a slight overstatement of what the record shows: April 23 was one dated announcement that bundled two distinct mechanisms — the seat-fee-to-flat-fee switch and the egress reallocation — into a single event, not two separate repricings months apart. That's a more precise framing, and it still supports the underlying point: it's one instance of a flat-fee vendor being forced to touch the page, against zero instances of Railway touching its rate card upward.
Why a flat-fee vendor has to touch the page and a metered one doesn't
The mechanism here isn't about which company is more disciplined. It's structural, and it comes down to where the price lives.
Render's Pro plan is a single number: $25 a month, however many seats, however much you deploy up to the plan's limits. If Render's own infrastructure costs shift — more bandwidth flowing through its network, more compute demand, a hosting bill of its own that moved — the only lever available is editing that number on the pricing page. That edit is visible by construction. It shows up in a changelog, gets tweeted about, gets written up by every PaaS-pricing blog watching the space (including this one, more than once). A flat-fee repricing is loud because the price is a single public artifact.
Railway's Pro plan isn't a number in that sense — it's a formula. $20/vCPU-month times however many vCPUs you actually run, $10/GB-month times however much RAM, $0.05/GB times however much you send out. If Railway's own costs rose, it doesn't need to touch the $20 plan fee at all. It can move the rate — $20/vCPU-month to $22, say — and that change is buried in a rate-card page most customers never open, expressed as a slightly bigger number on next month's invoice rather than an announcement anyone writes about.
Run the arithmetic on what that would look like. A typical Hobby project — half a vCPU, half a gig of RAM, light egress — runs about $10-15/month today. A 10% bump to the CPU rate alone adds roughly $1/month to that bill: invisible, easily absorbed, never explained. Scale that same 10% rate move up to a Pro-tier team running 4 vCPUs and 8GB of RAM around the clock — call it a $150/month baseline — and the same percentage move adds closer to $12-15/month, still with no announcement, no changelog entry, no page for a comparison blog to screenshot. The bigger the account, the more a quiet rate move is worth to the vendor, and the less likely anyone outside the billing team notices it happened.
That's the asymmetry the "no price increase" framing hides: a flat-fee vendor can only pass through rising costs in public. A metered vendor can pass through the identical cost increase privately, one line item at a time, and nothing on the plan page ever needs to change.
What it means for growth strategy, not just cost structure
The two models aren't just different risk profiles — they're different bets on how each company wants to grow.
Render's move trades per-seat revenue for adoption friction removed. Its own announcement framed the change as a customer-favorable simplification, claiming 75% of paying customers would see costs stay flat or drop. That's a sales-led argument: uncapping team size for a flat fee makes it easier to say yes to a growing team without a finance conversation about seat counts, which matters more once you're selling to teams with a budget owner instead of a single developer swiping a card. The flat Scale tier at $499/month reads the same way — a fixed number a procurement process can approve once, rather than a per-seat line that grows every time headcount does.
Railway's model is built for the opposite motion: self-serve growth that scales with usage automatically, with no renegotiation required on either side. A Hobby account that grows into a real workload just starts consuming more compute credit and paying more — Railway's revenue rises in lockstep with the customer's own growth, without either party touching a contract or a plan page. That's a friendlier model for solo developers and small teams sizing up gradually, and it's also the model that lets a vendor grow its own revenue quietly as existing customers use more, rather than needing new logos or plan upgrades to move the topline.
Neither strategy is dishonest. But they produce very different signals to a customer trying to read vendor stability from the outside, which is exactly why the sticker price alone is the wrong thing to be reading.
The counter-evidence: Railway hasn't actually pulled the quiet-hike lever
It would be easy to stop the argument at "usage-metered pricing lets a vendor raise costs invisibly" and treat that as damning. The honest version of this piece has to report what actually happened, not just what the model makes possible — and what actually happened cuts the other way.
Railway's own 2023 migration announcement set network egress at $0.10/GB. Railway's current pricing page lists egress at $0.05/GB. The compute rates — $20/vCPU-month, $10/GB RAM-month — are identical to the 2023 numbers, cent for cent. Three years into a usage-metered model that structurally could absorb cost inflation without anyone noticing, the one rate that moved, moved down.
That doesn't prove Railway never will move a rate upward — the whole point of the mechanism in the previous section is that it wouldn't be visible in the same way if it did. But it does mean the specific fear (a usage-metered vendor using invisibility to raise revenue quietly) is a structural risk this business model enables, not something Railway has actually done. Judge the model on what it makes possible; judge the company on what it's actually billed.
What to actually track if you're watching either vendor
If you're deciding between Railway, Render, or anyone else pricing this way, the plan page is the wrong artifact to monitor for stability. Two things to check instead:
- The per-unit rate card, not the plan fee — for a usage-metered vendor, that's where a cost increase would actually surface. Bookmark it, and compare it against an old cached version or a past blog post's numbers once a year.
- What counts as "included" — Render's repricing didn't touch its compute rate at all; it moved by redefining how much bandwidth comes bundled before metering starts. A vendor can hold every rate flat and still raise your bill by shrinking what's free.
Either way, the underlying lesson is the same one that applies to every hosted PaaS: the price you're being billed always has someone else's cost structure and someone else's growth strategy embedded in it, whether or not that shows up as a changelog entry. The only way to remove both variables is to not have a vendor's rate card between you and the machine at all — which is a different trade entirely, not a cheaper version of the same one.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. There's no plan page to watch and no rate card to move, because there isn't a vendor sitting between you and the Hetzner box. Star the repo on GitHub or deploy your first app today.



