- How a plan minimum differs from a plan price, and why the distinction matters
- Which four resources Railway meters, and which one usually dominates
- Why per-second billing rewards idle services and punishes steady ones
- The crossover point where flat pricing becomes cheaper
- How to estimate a Railway bill before you deploy anything
Railway's pricing page is short and honest, which is exactly why it confuses people. It shows a small number, and small numbers read like prices.
They are not. On Railway, the plan price is a floor. What you pay is the floor or your metered usage, whichever is larger.
Plans are minimums with credit attached
Railway sells access, not capacity. Hobby costs $5 per month and includes $5 of usage. Pro costs $20 per seat per month and includes $20 of usage. New accounts get a short trial with a small credit that expires rather than renewing.
So on Hobby, if your project consumes $3 of metered resources, you pay $5. If it consumes $19, you pay $19. Nothing about the plan caps consumption; the plan simply prepays some of it.
This is a genuinely fair structure, and it is the opposite of how most developers read a pricing page. We are trained to see a monthly figure and assume it bounds the bill.
The four meters
Railway measures your service by the second, across four dimensions:
vCPU - processor time consumed while the service runs.
Memory - the RAM your container occupies, billed per GB per unit of time.
Volumes - persistent disk attached to a service, billed per GB per month.
Egress - bytes leaving Railway's network.
For most web services, memory dominates. A typical Node or Python API is memory-hungry and CPU-idle: it holds a couple of gigabytes and spends most of every second waiting on I/O. You are billed for the memory you reserved regardless, because the container is holding it whether or not it is doing work.
Current per-unit rates live on Railway's own pricing page and move from time to time, so we are not going to reprint numbers here that may be stale by the time you read this. The structure is the durable part. Check the rates, then use the structure below to reason about them.
Per-second billing rewards idleness
This is the core insight, and it cuts both ways. Per-second metering means a service that scales to zero, or that only runs during a nightly job, costs almost nothing. Ten experimental side projects that receive four requests a week are close to free.
The same mechanism means a service that runs at steady utilisation twenty-four hours a day is billed for 2.6 million seconds a month at full rate. There is no volume discount for being boring.
Every metered platform has a crossover point: the utilisation level above which a flat plan of equivalent capacity is cheaper. Below it, metering saves you money. Above it, you are paying a premium for the ability to have saved money.
A worked comparison
Take two teams with identical infrastructure - one API container at 2 GB, one Postgres database, one small volume, and 40 GB of monthly egress - but different traffic shapes.
Team A: a side project. The API sleeps most of the day.
effective runtime ~120 hours / month
metered usage ~$6
Hobby plan minimum $5
billed $6 <- metering wins
Team B: a production SaaS. The API never sleeps.
effective runtime ~730 hours / month
metered usage ~$48
Pro plan minimum ($20 incl. credit)
billed $48 <- flat plan would win
Same architecture. Same platform. 8x the bill,
entirely because of utilisation shape.
Team A should be delighted with Railway. Team B is paying for elasticity it never uses. Neither team is doing anything wrong; they simply have different shapes, and only one of them matches the model.
Databases meter differently, and worse
One asymmetry deserves its own section. A stateless API can be scaled down, slept, or restarted freely, so per-second billing works in your favour whenever traffic dips.
A database cannot. It holds memory to keep its working set warm, it holds a volume that bills per GB-month regardless of activity, and it must be reachable at 4am on a Sunday whether or not anyone is awake to query it. The one component you can never scale to zero is billed on a model whose entire benefit is scaling to zero.
This is why attached databases on metered platforms tend to be the line item people are most surprised by, and why so many teams end up running their application on one platform and their database on another. The application benefits from elasticity. The database only pays for it.
Metered billing is a discount on idleness. A production database is never idle, so there is no discount to collect.
Where Railway is worth paying for
We have no interest in pretending Railway is bad. It is not, and its dashboard is the best in the category. Choose it when:
You run many small or experimental services, most of which are idle most of the time.
Your traffic is genuinely spiky and you would otherwise over-provision for the peak.
Deployment ergonomics matter more to you than a predictable invoice, which for a small team iterating quickly is a perfectly rational preference.
We compared it head to head with the obvious alternative in Railway vs Render, including the places each one clearly beats the other.
Where flat pricing wins
The inverse case is a service with steady load, a database that must always be reachable, and a finance function that would like the same number every month.
That is what Swyftstack sells. The Launch plan is $19 per month for three projects, three databases, 10 GB of database storage, 200 GB of object storage, and 500 GB of egress. Growth is $99 for 15 projects, 50 GB of database storage, and a terabyte of object storage. There is no per-second meter, so a busy month and a quiet month cost the same.
The trade is real and worth stating plainly: if your services idle, you are overpaying us relative to a metered platform. Flat pricing is not a universally superior model. It is a better fit for steady workloads and a worse one for bursty ones. If you are already on Railway and your bill has stopped surprising you in a good way, migrating away is straightforward, and our Railway alternative page lays out what changes.
Estimating your bill before you deploy
Work out effective runtime, not wall-clock time. How many hours a month is the service actually holding memory? For an always-on API that is roughly 730.
Multiply memory reservation by that runtime. For most web services this is the dominant term, not vCPU.
Add volumes and egress. Volumes bill per GB-month regardless of runtime. Egress scales with users.
Compare the total to your plan's included credit. If usage lands under the credit, the plan price is your bill. If it lands over, the plan price is irrelevant.
Then ask the shape question. If your answer to step one was 730 hours, price a flat plan of equivalent capacity before you commit.
Prices quoted here were checked in July 2026. Vendors change them; treat the structure as the durable part and re-check the current numbers before you budget.
Frequently asked questions
Does Railway have a free tier?
Not an ongoing one. New accounts get a trial with a small credit that expires, after which the Hobby plan at $5 per month is the entry point. That plan includes an equivalent amount of usage credit, so a genuinely tiny project can sit close to the minimum.
Why is my Railway bill higher than my plan price?
Because the plan price is a minimum that includes a matching usage credit, not a cap. Once your metered vCPU, memory, volume, and egress consumption exceeds that credit, the excess bills on top. A service that runs continuously will exceed it.
What does Railway actually meter?
Four things: vCPU time, memory, persistent volume storage, and network egress. All are measured by the second while your service is running. Memory is frequently the meter that dominates, because most web services reserve far more memory than CPU.
Is Railway cheaper than a VPS?
For intermittent workloads, often yes, because a VPS bills whether or not you use it. For a service that runs 24 hours a day at steady load, a VPS or a flat plan is usually cheaper, because you are paying a convenience premium on every metered second.
How do I estimate a Railway bill before deploying?
Multiply your service's memory reservation and vCPU allocation by the number of seconds it will actually run each month, add volume storage and expected egress, then compare that total to your plan's included credit. If the result is comfortably under the credit, the plan price is your bill.