Railway pricing in 2026: the real 30-day bill

Railway's plan price is not your bill. It is a floor. In 2026 the $5 Hobby plan and the $20 Pro plan are usage minimums, and everything above that minimum is metered by the second on four separate resource meters. The teardowns online quote the plan number and stop. This one models the actual 30-day invoice at three real app sizes, so you can budget the number you will actually pay.

Quick Answer (July 2026)

Railway bills you a plan minimum plus metered resource usage. The plan is $5/month (Hobby) or $20/month (Pro), and that fee covers your first $5 or $20 of usage. On top of the minimum you pay $20 per vCPU-month, $10 per GB of RAM-month, $0.05 per GB of network egress, and $0.15 per GB-month of volume storage. A one-service side project sits near the $5 floor. A three-service SaaS with a Postgres database runs about $79/month. A scaled, multi-replica product runs about $278/month. The meter that moves your bill is provisioned RAM and CPU, not the plan you clicked.

The four rates that actually bill you

Railway publishes one honest rate card, and it is the same set of numbers your invoice uses. Here is the July 2026 sheet (Railway pricing reference):

Two things follow from that card. First, RAM at $10 per GB-month is cheap per unit but it is the meter people over-provision, so it quietly becomes the biggest line on a real bill. Second, because billing is per-second, a service that sits idle costs a fraction of a service pinned at full load. The rate card is a ceiling, not a promise.

The plan fee is a floor, not the bill

The single most common Railway budgeting mistake is reading "$5" or "$20" as the monthly cost. It is not. Railway's own billing docs are explicit: your subscription fee is a minimum usage commitment that covers your first $5 (Hobby) or $20 (Pro) of resource usage each month. Stay under the minimum and you pay the minimum. Go over, and you pay actual usage instead (Railway billing docs).

So the plan is not an added cost on most real apps. It is the first slice of your usage. For anything past a hobby project, the plan number is a rounding error and the resource meters are the bill. Let's model three.

Cohort A: the indie side project (Hobby, $5/mo)

One always-on web service, 0.5 vCPU and 0.5 GB RAM, a 1 GB volume, light traffic.

• CPU: 0.5 vCPU x $20 = $10.00
• RAM: 0.5 GB x $10 = $5.00
• Volume: 1 GB x $0.15 = $0.15
• Egress: ~3 GB x $0.05 = $0.15
• Usage ceiling: $15.30/month

That $15.30 is the fully-pinned ceiling. Real side projects idle most of the day, and because Railway bills per second, actual usage on a bursty low-traffic app often lands between $4 and $8, which the $5 Hobby minimum largely absorbs. Budget $15 for a service you keep truly always-on and busy; expect closer to the $5 floor if it mostly waits for visitors.

Cohort B: the growing SaaS (Pro, $20/mo)

A real product: a web service (1 vCPU / 1 GB), a background worker (0.5 vCPU / 0.5 GB), and a managed Postgres (1 vCPU / 1 GB, 10 GB volume), all always-on. Moderate traffic.

The $20 Pro fee is the first $20 of that $79, not an addition. So the invoice is about $79/month at full utilization. The plan you picked is 25% of the bill; the other 75% is CPU and RAM months you provisioned. Notice the worker: a small 0.5/0.5 helper still costs $15/month if it never sleeps.

Cohort C: the scaling product (Pro, $20/mo)

Two web replicas (2 vCPU / 2 GB each), a worker (1 vCPU / 2 GB), a busy Postgres (2 vCPU / 4 GB, 50 GB volume), and a Redis cache (0.5 vCPU / 0.5 GB). Always-on, real traffic.

Here is the part the plan-price teardowns miss. Add the meters up by type: CPU across every service is 7.5 vCPU, so $150. RAM is 10.5 GB, so $105. That is $255 of compute out of a $277.50 bill. The $20 plan fee is 7% of the invoice and fully absorbed. The bill is your provisioned RAM and CPU, full stop.

RAM is the quiet meter

On r/webdev, a developer sizing a "2 GB RAM / 2 core machine" estimated roughly $80/month and asked why Railway felt expensive. Run the real numbers: 2 vCPU x $20 plus 2 GB x $10 is $40 + $20, so about $60/month at full utilization, and less if the box is not pinned. Their instinct was right that memory drives the bill, but the ceiling for that spec is nearer $60 than $80, and per-second billing pulls it lower on an idle service.

The lesson holds across all three cohorts: over-provisioned memory is where Railway invoices balloon. A service that asks for 4 GB "to be safe" and uses 800 MB is paying $40/month for $8 of RAM. On Railway you size to what you use, because you are billed for what you provision times how long it runs.

Same app, three billing philosophies

The growing-SaaS stack from Cohort B costs differently on each major platform, because each meters a different thing. Numbers below are 2026 published rates.

Render prices always-on services as flat instances: Starter is $7/month (0.5 vCPU / 512 MB) and Standard is $25/month (1 vCPU / 2 GB), with 100 GB of bandwidth included on the base workspace. A flat instance is easier to predict but you pay the same whether it is pinned or idle, which is the opposite of Railway's per-second model.

Vercel charges $20 per seat plus usage (active CPU billed by the hour, fast data transfer at $0.15/GB), and it is built for serverless functions rather than always-on workers and databases, so the Cohort B stack does not map cleanly onto it. For a persistent worker plus Postgres, a per-second resource platform is the more honest comparison. We broke Vercel's own bill down in the Vercel pricing teardown, and the Postgres side in the Supabase pricing teardown.

The seat detail that matters for teams

One line on the Pro plan is easy to miss and worth real money. Railway's own Vercel comparison states that Pro is a $20/month usage minimum with workspace seats included, not a per-user fee (Railway vs Vercel). A five-person team on Railway Pro starts at $20/month flat before usage. The same team on Vercel Pro starts at $100/month (five seats at $20) before a byte of usage. If your headcount is growing faster than your traffic, that difference compounds.

How to actually keep the bill down

Four moves, in order of impact:

1. Right-size RAM first. It is the meter you most often over-provision. Watch real memory use for a week and set the service to match. Dropping a service from 4 GB to 1 GB saves $30/month per service.
2. Sleep what can sleep. Railway can idle inactive services. A dev or staging service that sleeps outside business hours costs a fraction of one pinned 24/7.
3. Watch egress on media-heavy apps. At $0.05/GB it is cheap until you are serving large files; move heavy assets to object storage or a CDN and keep egress off the app service.
4. Consolidate tiny services. Three 0.5-vCPU helpers each costing $10 to $15/month may be cheaper as one right-sized service if they are not independently scaled.

Railway's model rewards discipline: because you pay for provisioned resources times run-time, the budget is entirely in your hands. That is the opposite of a flat-instance platform, where the only lever is which tier you buy.