Railway, Render, and Fly.io are the three names that come up every time someone asks what to use now that Heroku is no longer the default. They look similar from a distance: connect a repo or a container, get a running app, skip the server babysitting. Up close they make different bets, and one of them changed its free offering enough that older advice about it is now wrong.
What Railway actually does
Railway is the closest thing to Heroku's original developer experience. Connect a GitHub repo, Railway detects the runtime (Node, Python, Go, Rails and others), and you have a deployed app with a domain in a couple of minutes. Persistent volumes, private networking between services, cron jobs, and one-click Postgres and Redis provisioning are all first-class features.
The pricing is usage-based with a small base fee. The Trial plan gives a one-time $5 credit with limited resources, and it does not renew, so it is not a free-forever tier. Hobby costs $5/month with $5 of included usage and up to 8GB of RAM per service. Pro costs $20/month with $20 of included usage, team features, 32GB of RAM per service, and priority support. A small managed Postgres instance lands around $5/month in usage.
The honest limits: Railway is younger and smaller than Heroku was, SOC 2 certification only arrived in 2024, multi-region deployment is less straightforward than on Fly.io, and a database plus a backend running around the clock can burn through the included credit faster than hobbyists expect. On r/webdev it is the most consistent recommendation for a Heroku replacement.
What Render actually does
Render is the Docker-friendly, static-site-friendly option. Connect a repo, push, and it deploys. Preview environments, where a branch gets its own live URL for PR review, are a genuinely useful feature, and Docker is supported natively, which matters if your team already owns container definitions. Free static site hosting with a CDN is competitive with Netlify and Vercel for non-Next.js projects.
The pricing structure has two layers, which trips people up. Instance pricing: web services can run on a free instance that spins down after 15 minutes of inactivity, or on a paid Starter instance at $7/month for 512MB of always-on RAM, with larger sizes above that. Managed Postgres starts at $7/month. On top of that sits the workspace plan, and per Render's live pricing page the tiers are Hobby at $0/month plus compute and Pro at $25/month plus compute, with unlimited seats and full-stack previews on Pro.
The recurring complaints are the free-tier spin-down (a cold URL is a bad first impression), single-region services with no built-in multi-region routing, and slow support response on production incidents. Reliability has been solid in recent years.
What Fly.io actually does
Fly.io is the most technically interesting of the three. It runs your containers on its own hardware across 30-plus regions and places them near your users, with Anycast routing. If latency in Tokyo, Frankfurt, and Chicago at once is a real product concern, nothing else here makes that as easy. The fly deploy workflow is excellent, though it is CLI-first and assumes more infrastructure comfort than Railway or Render.
Pricing is pure pay-as-you-go. Per Fly's own pricing page, a shared-cpu-1x machine with 256MB runs about $1.94/month, shared-cpu-2x with 512MB about $3.89/month, and volumes cost $0.15/GB per month. Here is the change worth knowing: older guides describe a free tier of three small VMs. That is now a discontinued legacy plan. New accounts get a short free trial (2 VM hours or 7 days), and every organization needs a credit card on file. Fly is no longer a free-forever host for hobby projects.
The other big caveat is Postgres. Fly Postgres is self-managed, meaning you own backups, failover, and upgrades, which is cheaper than managed offerings but a real operational responsibility. Support is largely community-based unless you pay for a higher plan.
Where the three genuinely diverge
Railway optimizes for speed to deploy and a clean developer experience, with managed databases attached to the app. Render optimizes for a broad, familiar PaaS feature set, particularly static sites, Docker workflows, and preview environments. Fly.io optimizes for geography: containers close to users, multi-region failover, and low-level control.
The database story separates them cleanly. Railway and Render both offer managed Postgres. Fly does not, in the sense most people mean. If you do not want to operate a database, that alone rules Fly out or makes you pair it with an external managed provider.
Real cost for different teams
A side project or prototype that needs to be deployed today: Railway's Hobby at $5/month with included usage is the smoothest path, and the one-time Trial credit lets you try it first.
A static site or small service where a cold start is acceptable: Render's free static hosting and free web instance cover this, and the $7/month Starter instance removes the spin-down when it starts to matter.
A startup with a Docker-based stack and PR review workflows: Render's preview environments and native Docker support fit, at $7/month per small instance plus the workspace plan once a team is involved.
A globally distributed API where user latency by region matters: Fly.io, at roughly $2 to $4 per month per small machine per region, is the only one here built for that, provided your team is comfortable with containers and self-managed Postgres.
A team that wants to stop thinking about infrastructure entirely: Railway, or Render with managed Postgres. Fly asks more of you.
What actually breaks in practice
Railway's failure mode is credit burn and scale. Always-on services plus a database eat the included usage, and enterprise or multi-region needs push you elsewhere.
Render's failure mode is the free-tier cold start and slow support. A free web service that sleeps is fine for background jobs and painful for anything user-facing.
Fly.io's failure mode is operational surface area. Self-managed Postgres, a CLI-heavy workflow, and less predictable usage-based bills mean it can cost more of your time than the machine price suggests.
Data handling and where your apps live
Railway runs on US infrastructure (GCP), does not sell data or use it for AI training, supports export and deletion, and is SOC 2 certified.
Render hosts in the US and EU on its own infrastructure, with an EU region available, no AI training on customer data, exportable databases, and SOC 2 Type 2 certification.
Fly.io runs your workloads on its own hardware across a global edge network, states no data selling or AI training, and supports export and deletion. Your data lives wherever you deploy your machines, which is a feature for latency and something to plan around for data residency.
Switching between them
Moving from Heroku to Railway or Render is mostly a matter of pointing at your repo and re-creating environment variables and add-ons. Moving between Railway and Render is similar, with Render's Docker-native approach helping if you already have container definitions. Moving to Fly.io means containerizing if you have not already, and deciding how to handle Postgres, since there is no managed equivalent to migrate into.
Onboarding and day-to-day usability
Railway's signup takes GitHub or email, and a repo deploys in under three minutes with zero config for most frameworks. Database provisioning is one click.
Render accepts GitHub, GitLab, or email with no credit card for the free tier. A web service deploys from a repo in under five minutes, managed Postgres and Redis spin up in seconds, and deploy logs are detailed.
Fly.io needs an email and a credit card, and the flyctl CLI is the primary interface. Deploying a Dockerfile takes a few minutes once flyctl is installed, but there is no GUI-first path.
Which one to actually pick
Pick Railway if you want the smoothest Heroku-style experience with managed databases and you are happy with usage-based billing.
Pick Render if you want static sites, Docker-native deploys, and preview environments, and can live with a single region per service.
Pick Fly.io if geography is a product requirement and your team is comfortable running containers and its own Postgres.
For a simple web app with no special needs, start with Railway or Render. Reach for Fly when latency by region is the problem you are actually trying to solve.