Render vs Railway: Pricing, Free Tiers, and the Question Neither Answers

Two tabs are open. One quotes a price per second, the other a price per month, and the arithmetic refuses to resolve because it depends on traffic you don't have yet. In a third tab is a comparison article that picks a winner, and it says roughly what the four other comparison articles said.

This is not a fifth ranking. The billing difference between the two is real and the next section states it plainly, because there is no skipping it. What follows after that is the part the comparison genre leaves out, which is also the part that gets expensive later rather than at signup.

One clarification on scope first. If the question underneath your search is whether the platform layer should run on a server you administer, that is a different trade with a different ledger, and it is worked through in self-hosted PaaS versus managed. If you have already decided to leave Railway and want to know what a project costs to unpick before it can move anywhere, that is what leaving Railway actually detaches. Everything below assumes somebody else operates the platform and you are choosing which somebody.

The comparison everyone writes, and why it's half a decision

Search this and you get one axis, repeated. Railway meters actual consumption: as of writing their pricing page describes charging per second for the CPU, memory and disk your services use, with each plan bundling a credit allowance and metering anything beyond it. Render sells instances at a fixed monthly rate per service. That is an accurate summary and it is where nearly every page on the subject stops.

The axes that separate one deploy platform from another were worked through in how git push to deploy actually works: reproducible builds, an addressable artifact, health-gated releases, where config and secrets attach, preview environments, observability, and region and residency. That post notes that applying those axes to named platforms is a separate exercise. This is that exercise. Running it turns up something a price table structurally cannot show, which is that on the last axis these two platforms give the same answer, and it is the answer most people check last.

Two billing models are two shapes of uncertainty

Which one is cheaper has no answer that survives contact with a real workload, because the two models are not pricing the same thing. Usage billing makes the invoice a function of what your application consumed, so it tracks reality closely and moves when reality moves. Fixed instance pricing makes the invoice a function of a decision you made in advance, so it stays still while reality moves underneath it. The question with an actual answer is which of those two uncertainties you would rather carry.

When usage billing surprises you

The failure mode worth knowing about is that a bug acquires a price. A retry loop with no backoff, a worker draining a queue that keeps refilling, a background job that was supposed to run nightly and is running continuously, an endpoint that got posted somewhere. On a fixed instance all of those present as a slow application, which is a symptom every developer is trained to notice within the hour. Under usage billing they present as an application working correctly, and you find out at the end of the billing period. Egress is metered on its own line in most usage models, which means a hot asset served from the wrong place is a second version of the same surprise.

When a fixed instance wastes money

The opposite failure is quieter and more common. You are paying for the ceiling rather than the floor, so an application serving forty requests a day costs what it would cost serving forty thousand, and you had to guess the size before you had a single day of production data to guess from. Guess high and you fund headroom you never touch. Guess low and you discover it during the traffic event you sized for. Resizing is available on both, but it is a step between named tiers rather than a slope, so the correction happens after the incident rather than during it.

# One application, one month, two invoices.
#
# Metered on consumption
#   idle overnight ................ close to zero
#   normal daytime traffic ........ tracks it honestly
#   the retry loop on the 14th .... billed, silently, as legitimate work
#   the launch-day spike .......... billed, correctly, as a great day
#   -> the bill is a report on the month you actually had
#
# Fixed instance
#   idle overnight ................ full price
#   normal daytime traffic ........ full price
#   the retry loop on the 14th .... free, and visible as latency
#   the launch-day spike .......... free until it hits the ceiling, then 503
#   -> the bill is a report on a decision you made in week one

Neither model is a trick played on the customer. Preferring the first because you are small and spiky is sound, and preferring the second because a finance team needs a number in advance is equally sound. What is not sound is treating the choice as an arithmetic problem with one right answer, since the inputs are your own traffic pattern and your own tolerance for a surprise.

Free tiers: what happens when nobody is using the app

The useful question about a free tier is not whether it exists but what it does to an idle application. As of writing, Render's documentation states that it spins down a free web service after 15 minutes without inbound traffic, that bringing it back takes about a minute, and that a visitor arriving in the meantime is shown a loading page; free instance hours are also capped monthly, after which the service is suspended until the next month. Railway, as of writing, lists a standing free plan built on a small monthly credit allowance rather than on always-on hours, alongside a separate 30-day trial credit, so the binding constraint there is the allowance rather than an idle timer.

That last detail is worth dwelling on for a second, because a good deal of writing on this comparison describes Railway as trial-only. Their own pricing page as of writing lists a permanent free plan next to the trial. The summaries were out of date and the source was not, which is the general lesson: on pricing, the vendor's own page is the only citation worth having, and everything in this section should be re-read there before you rely on it.

What a spin-down costs is not measured in money. The mechanics of why an idle container takes time to answer are covered in what cold starts are and why free-tier apps fall asleep; the relevant point here is who waits. Not you, since you are hitting the app constantly while you build. The person who waits is whoever arrives first after a quiet period, which on a demo link in a job application or a webhook that fires twice a week is precisely the visit you cared about. A minute is a long time to hold a browser tab that has given you no reason to stay.

An EU region is not a European provider

Both platforms will run your application inside the EU. As of writing Render's region list is Oregon, Ohio, Virginia, Frankfurt and Singapore, so Frankfurt is a supported choice, and Railway offers European capacity as well. Neither fact makes either company a European provider, because a region determines where bytes are written and says nothing about which government can compel the company operating the service. The three separate things that "European" can mean, and why only one of them survives a procurement questionnaire, are set out in choosing a European Heroku alternative, so they are not re-derived here.

Applied to these two, the test is short. Look at which legal entity appears in the terms you are agreeing to and where that entity is registered, then look at the published subprocessor list and where those sit. Both are US companies as of writing, and a US entity operating a Frankfurt region stays subject to US law regardless of where the container runs. Why that remains true when the servers are in Germany is the substance of Schrems II and what it did to data transfers. Run that check against their current terms rather than against this paragraph, since corporate structure is exactly the kind of fact that changes without a changelog entry.

There is a second layer here that does not come up when the platform is one you run yourself, and it catches people out. The region selector applies to the service you are creating. Your build artifacts, your deploy and application logs, your metrics history and your managed database backups are separate systems, and whether they live in the same jurisdiction as the container is a question you have to ask specifically. All of them hold personal data as readily as the database does, which is the argument made at length in EU hosting for developers. None of this implies either platform mishandles data. It means the dropdown answers a narrower question than the one an auditor is going to ask.

The three things you only see in month three

Feature matrices go stale within a quarter, so rather than a table of what each platform ships today, here are the questions worth putting to both pricing pages before you commit. They share a property: none of them hurts in week one, and all of them are awkward to reverse.

• A region is chosen once. As of writing, Render's region documentation says the region is picked during the creation flow and that changing the region of an existing service or database is not supported, so moving means recreating the service and migrating the data underneath it. Multi-region on that model means one service per region rather than one service spread across several. Whatever the current answer is on either platform, this is the least reversible decision on the signup page, and it is usually made in the first ninety seconds.
• The database beside the application is often the larger line. Comparisons price the web service and stop. In practice the managed Postgres or Redis sitting next to it costs as much or more, and free database tiers tend to carry expiry dates that the free application tier does not. Price the pair, and check what happens on the day the free database's clock runs out.
• Egress is metered separately and nobody models it. Outbound traffic is its own line on most usage-based bills, and it is the line that scales with success rather than with your architecture. Why it lands so much harder than people expect, and what it does to the arithmetic of serving files, is worked through in why downloading your own data costs so much.

What each of them is genuinely good at

Railway's interface is the reason people stay. The service canvas makes an architecture visible as a graph rather than as a list of unrelated dashboard entries, environment variables can reference each other across services, and the distance between a repository and a running application is about as short as anyone has managed. Combined with consumption billing, a low-traffic or bursty workload can run there for very little. That is just what metering by the second does when the meter is honest.

Render's case is maturity. Background workers and cron jobs are service types in their own right as of writing rather than a container you configured into that shape, the platform has been doing the same thing long enough that the edges are worn smooth, and a fixed monthly figure is a thing you can put in a budget and forget. For a team whose main requirement is that nothing surprises anybody, that combination is worth real money. If either description fits your situation, nothing in this article is trying to move you.

• Choose Railway if your traffic is bursty or the application is idle most of the day, if you want the architecture visible as a graph rather than as a list of dashboard entries, and if you would rather pay for what ran than for what you provisioned. The trade you are accepting is that a runaway job is billed as legitimate work and you learn about it at the end of the month.
• Choose Render if the load is steady enough to size, if somebody needs the number in advance, or if you want background workers and cron as first-class service types rather than containers bent into that shape. The trade is that a quiet month costs what a busy one costs, and you picked the instance size before you had a day of production data.
• Choose neither if the question underneath the search is whose law governs your customers' data. Both are US companies as of writing, so the choice settles your billing model and leaves that question exactly where it was, in whichever region you deploy.

Which question you're actually answering

The choice looks like a pricing comparison and behaves like two independent decisions that happen to be made on the same afternoon. One is about how you want to be billed. The other is about whose law your infrastructure sits under, and it does not appear on either pricing page.

The fourth row is where most of the wasted effort lives. A team decides, usually after a customer asks or a contract lands, that its stack should be under European law, and then migrates from one US platform to another because the second one has a Frankfurt region. The application moves, the data moves, the work is real, and the answer to the question that prompted it is unchanged. What does change when the operator changes, separated from what changes when only the region does, is worked through in EU vs US hosting.

How Runsite handles it

For the European side of that trade, concretely, and starting with the part that sits awkwardly. Runsite prices fixed monthly plans rather than metering consumption, which puts it in the right-hand column of the table above with all of that column's drawbacks: a quiet month costs the same as a busy one, and you size the service before you know the load. Web services on EU infrastructure run from €5/mo up to 8 vCPU and 16 GB as of writing, with a free tier covering one service at 0.1 vCPU and 256 MB. If your workload is bursty and mostly idle, consumption billing will be cheaper, and no amount of positioning changes that.

The second limitation is regions. There is one, Frankfurt, Germany. Against a platform offering five regions across three continents that is a shorter list, and if you need to serve Singapore from Singapore it is the wrong answer. What that single region buys is the sentence from the callout above: your containers, environment variables, build artifacts and logs stay inside the EU, there is no replication to non-EU regions, and a signed GDPR data processing agreement comes with every plan including the free one. The processor named in it is a European company, so the answer you give a customer's security review is the same answer whether they ask about the runtime, the build cache or the log store.

The rest is the shape you would expect. Connect a repository on GitHub, GitLab or Bitbucket and a webhook builds on every push to your branch; the framework is detected for Next.js, Django, Rails, FastAPI and others, and your own Dockerfile is used when you supply one. Releases are rolling behind a configurable health check, a failed check returns to the previous healthy version, and every pull request gets an environment on its own URL. A deploy takes around 30 seconds as of writing. Rollbacks and deploy history are on the Pro plan (€25/mo). On the free tier specifically, active applications don't cold-start, so the loading-page problem from earlier doesn't apply; a service sleeps only after 14 days idle. Alongside it sit managed PostgreSQL hosted in the EU and managed Redis for caches and job queues from €5/mo, and object storage with no egress charges, which removes the third item from the month-three list entirely. Setup details are in the Runsite docs.

The short version

Railway meters what you consume and Render sells you an instance, and picking between those two is picking which uncertainty you carry: a bill that can be surprised by your own bug, or a bill that keeps charging while the application sits idle and that you had to size before you had any data to size it with. On free tiers, ask what happens to an idle application and who waits when it wakes, and read the vendor's own page rather than a comparison, because several of the widely repeated claims about both are out of date.

Then there is the question neither pricing page raises. Both are US companies as of writing, so choosing between them settles your billing model and leaves your jurisdiction exactly where it was, whichever region you select. If that matters to your customers, it is a decision about which company you contract with rather than which dropdown you pick, and it is far cheaper to make now than after the migration. Deploying one service on a European platform that builds and releases on every push is a short way to find out whether the answer you would give a customer changes.