Railway vs Render: where to run a backend that is not serverless

By Gerald · 22 August 2026

Shipping containers stacked at a port, representing the metered usage that both platforms bill by

Vercel and Netlify are great until your app needs a process that stays running: a websocket server, a queue worker, a cron job, or a database you actually manage yourself. That is the gap Railway and Render both fill.

Here is the short version. Render bills you for a fixed instance size, the same $7 or $25 a month whether your app is idle or busy. Railway bills by the second for what you actually use, which is cheaper for spiky or low-traffic apps and more expensive for one that runs hot all month. Pick Render for pricing you can predict on a spreadsheet. Pick Railway if your usage is genuinely low most of the time and you are comfortable watching a metered bill.

If you can't tell me in one sentence why your traffic is spiky rather than steady, you probably want Render's fixed pricing, not Railway's meter.

What both are replacing

Neither of these exists because Heroku is bad. They exist because Heroku's free tier disappeared in 2022 and its paid tiers stayed simple but expensive at scale. Render and Railway both picked up that same "git push, get a URL" workflow and modernized the pricing and the infrastructure underneath it.

Both connect to GitHub, both build from a Dockerfile or auto-detected buildpack, both give you a URL and a dashboard with logs. If you have used one, you can use the other inside twenty minutes. That part of the comparison is close to a tie, which is exactly why the pricing model and the platform's recent track record end up deciding it.

The pricing models, and how each one bites

Close-up of an amp and volt analog gauge panel, representing usage-based billing — Railway bills by the second on CPU, memory, and egress. Render bills by a fixed instance size. That difference matters more than any feature list.

Render's workspace plans were Hobby (free), Pro at $25 a month, and Scale at $499 a month, on top of per-service compute charges, as shown on the official pricing page in July 2026. Web service compute runs from Starter at $7 a month (512 MB RAM, 0.5 CPU) up through Standard at $25 a month and several Pro tiers beyond that. A Render Postgres instance starts near $7 a month for the smallest size. You pick a size, you pay that size, and the bill does not move unless you resize.

Railway works differently. The Hobby plan is $5 a month and that $5 becomes a usage credit, not a flat fee. Beyond it you pay per second: roughly $0.0000039 per GB of memory per second, $0.0000077 per vCPU-second, and $0.05 per GB of egress, according to Railway's own pricing page in July 2026. Pro is $20 per seat per month with higher limits and longer log retention.

The practical effect: a small backend that sleeps most of the night and gets light daytime traffic can cost less on Railway than the flat $7 Render Starter instance. A backend that runs constant background jobs at moderate load will often cost more on Railway than a fixed Render instance, because you are paying for every second regardless of how you got there. Metered billing rewards idle time and punishes sustained load. Fixed billing does the opposite.

Sleeping services and cold starts

Render's free web services spin down after 15 minutes without inbound traffic and take about a minute to wake up on the next request, confirmed on Render's own documentation in July 2026. That minute is a real UX cost if a real user hits a cold instance. Paid Render instances do not sleep.

Railway does not put services to sleep the same way. You are billed for compute the whole time a service is running, which is really a restatement of the pricing tradeoff above: Render's free tier sleeps to keep the free tier free, Railway's meter just charges you less when a service is idle instead of shutting it down.

If your app can tolerate a one-minute wake-up for the first visitor after a quiet stretch, Render's free tier is genuinely free. If it cannot, you are paying for a paid tier on either platform, and the pricing model above becomes the whole decision.

Managed databases on each

Both offer managed Postgres. Render Postgres starts at roughly $7 a month for the smallest size and scales up from there, with storage billed separately per GB. Railway runs Postgres, MySQL, Redis, and MongoDB as regular services on the same usage-based meter as everything else, so a small database with light traffic can be cheap, and a database under sustained load bills like any other Railway service.

Neither one is Neon. If you specifically want branchable Postgres with true scale-to-zero and a generous free tier, that is a different product entirely. I wrote about that tradeoff in the Neon review, and it is worth reading before you assume you need Railway or Render's database offering just because it is one click away.

One more thing worth knowing before you commit: Railway removed its CDN in May 2026 with no announced return date, and it came back with new CLI cache controls by mid-July 2026, based on Railway's own changelog and status history. That is a fast recovery as these things go, but it happened, and Railway also logged a cluster of incidents through spring and summer 2026, including an eight-hour platform-wide outage in May caused by a cloud provider account suspension. Render has had a quieter run over the same period. Neither history should be the only factor, but if uptime volatility worries you more than a few dollars a month, weight it.

Deploying, logs, and rollbacks

Both platforms deploy on every push to a connected branch, both show build logs live, and both let you roll back to a previous deploy with one click. Render's dashboard leans slightly more polished for someone who wants to glance at a service and understand its state immediately. Railway's project view, where multiple services and databases sit visually connected on a canvas, is genuinely useful once you have more than two or three services talking to each other.

Neither one requires you to learn a new deployment language. If you already deploy static frontends on Vercel or Netlify, adding either Railway or Render for the backend piece is an afternoon of work, not a week.

Who should pick which

Teams that want a monthly bill they can predict without checking a usage dashboard
Apps with fairly steady, moderate traffic where a fixed instance is the cheaper math
Anyone who wants the safer recent uptime record

Render fits that list.

Solo builders whose app gets light or spiky traffic and would otherwise pay for idle time
People comfortable watching a metered bill and setting spend alerts
Projects where the visual multi-service canvas actually helps you reason about the system

Railway fits that list, with the caveat that you should read its recent incident history before betting a production app on it.

Frequently asked questions

Does Render still put free services to sleep? Yes. Render's free web services spin down after 15 minutes without inbound traffic and take about a minute to restart on the next request, per Render's documentation as of July 2026. Paid instances do not sleep.

Is Railway cheaper than Render for a small app? Often, if the app is genuinely low-traffic, because Railway's usage-based billing charges close to nothing for an idle service. If the app runs sustained background work, a fixed Render instance can end up cheaper because Railway is billing every second regardless.

Can I run a Postgres database on either? Yes. Render Postgres starts around $7 a month for the smallest instance. Railway runs Postgres as a regular metered service alongside your app, so the cost depends on usage rather than a fixed instance size.

Which is easier to migrate off? Both deploy from standard Dockerfiles or common buildpacks, so neither locks your application code in. The real migration cost is re-pointing DNS, re-creating environment variables, and, if you used a managed database, exporting and re-importing your data.

Do I need either of these if I use Vercel? Only if your app needs a long-running process, a persistent websocket connection, or a background worker. Vercel's functions are built for request-response and scheduled jobs, not for a service that needs to stay resident. Read the Vercel and Netlify comparison if you are not sure your app needs this category at all.

My verdict

If you cannot describe your traffic pattern as spiky, assume it is steady and take Render's fixed pricing. It is one less thing to monitor, and its recent uptime record has been calmer than Railway's. Railway is the better deal specifically when your app sits idle most of the time, and you are willing to watch the meter to make sure it stays that way.