Every few months a wave of "we left Railway" posts shows up, and every one of them is really about the same moment: the app outgrew the hobby tier and the bill stopped looking cute. So instead of another migration story, here is the thing I actually wanted when I was making this call: an honest look at what Railway, Render, Fly.io, and plain AWS cost once you are past the free tier and running something real.
I am a cloud associate, so my bias is toward understanding the bill rather than avoiding it. Here is how these actually compare.
The tradeoff in one sentence
PaaS (Railway, Render, Fly.io) sells you time: you pay a premium per unit of compute in exchange for not running infrastructure. Raw cloud (AWS) sells you leverage: it is cheaper per unit and infinitely more flexible, in exchange for you doing the ops. The entire decision is where your app sits on the "is my time worth more than the markup" curve, and that point moves as you grow.
Where each one fits
Railway. Fantastic developer experience, deploy-from-git simplicity, great for a small team shipping fast. The catch is the one everyone writes about: usage-based pricing that is gentle at hobby scale and climbs quickly as your always-on services and databases grow. You are paying for the smooth experience, and at low scale that is a great trade.
Render. Similar PaaS comfort with more predictable service-based pricing. Managed databases, background workers, cron, all first-class. Tends to stay reasonable a bit further up the curve than pure usage-based billing, but you are still paying a managed premium and you hit ceilings on control.
Fly.io. The most infrastructure-flavored of the three. Runs your containers close to users, gives you more knobs, and is often cheaper for compute-heavy or globally distributed apps. In exchange you are closer to the metal and doing more yourself, which is either a feature or a cost depending on your team.
Plain AWS. The cheapest per unit and the most flexible, full stop. It is also the most work: you own networking, security, scaling, and the bill's complexity. The per-unit savings are real and large at scale, but they are not free, you pay in engineering time and the risk of misconfiguration.
The honest cost crossover
Here is the pattern I have seen, stated plainly rather than as a fake pricing table (your real numbers depend entirely on your workload):
- Hobby / early stage: PaaS wins easily. Your time is the scarce resource, the bills are small, and running your own infra to save a few dollars is a bad trade. Use Railway or Render and move on.
- Growing / steady traffic: the crossover zone. This is where the "we left Railway" posts come from. Always-on services and databases on usage-based PaaS pricing start to cost multiples of the equivalent raw compute. If your infrastructure is stable and predictable, the PaaS premium is now buying you less.
- Scale / cost-sensitive: AWS (or another raw cloud) usually wins on cost, if and only if you have someone to run it. At this size the per-unit savings dwarf a fractional engineer's time, and you need the flexibility anyway.
The mistake is treating this as a permanent religious choice. It is a stage-dependent decision. The right answer genuinely changes as you grow, and switching when the crossover arrives is not a failure, it is just noticing the trade flipped.
Before you migrate to "save money," read this
Most teams jumping from PaaS to AWS for cost reasons underestimate two things:
- The managed services you were getting for free. Railway/Render gave you a database, TLS, deploys, logs, and networking as part of the price. On AWS every one of those is a service you now provision, secure, and pay for separately. The raw compute is cheaper; the fully-loaded stack is closer than the sticker suggests.
- The ops time is a real cost. "We save $400/month on AWS" is not a win if it costs you a week of engineering a month to run it. Put a dollar figure on the time before you call it savings.
And if you do move to AWS, the cost only stays lower if you actually do the FinOps: rightsize, schedule non-prod, watch data transfer, and clean up idle resources. AWS being cheaper per unit does not make it cheaper by default, it makes it cheaper if you manage it. A neglected AWS account can easily cost more than the Railway bill you fled.
My take
If you are small, use a PaaS and stop thinking about it. When your bill crosses into "a chunk of an engineer's salary" territory and your infra is stable, price out the AWS version honestly, including the managed services and the ops time, not just the compute. Migrate when the math flips, not because a blog post told you PaaS is a trap. It is not a trap, it is a stage.
Where did the crossover land for you, and did the AWS bill actually come in lower after you added back all the managed pieces? That last part is where a lot of migrations quietly disappoint.
Top comments (0)