Fixed vs. Metered: What a 4-Service Stack Really Costs on Sevalla vs Railway

Two platforms will both take your git repo and give you back a running HTTPS service. One of them will charge you $69 next month. The other will also charge you $69 next month. The punchline of this post is that those two identical numbers arrive by completely opposite routes — and that the month after, they can diverge by 20–30% depending on nothing but how spiky your workloads are.

The two platforms are Sevalla and Railway, the two names that keep showing up next to Render on every "Heroku alternatives" ranking in 2026, including Back4App's ranked list. They share the Heroku-shaped developer experience — push code, get a URL — and they share one more thing most comparisons skip: neither charges per seat. But their billing models are mirror images. Sevalla, a Kinsta product, sells fixed-size pods at fixed monthly prices: pick a size, pay the number on the page. Railway charges no per-service price at all and instead meters what your containers actually consume, by the minute, at $20 per vCPU and $10 per GB of RAM per month.

Which one is cheaper? The honest answer is a table, not a slogan. So here is the table — the same four-service stack, priced three ways: a steady month, a bursty month, and a bad month.

The stack we'll price​

To keep both sides honest, everything below prices one concrete, typical small-team stack, always on:

• Web app — 0.5 vCPU / 1 GB RAM
• Background worker — 0.5 vCPU / 1 GB RAM
• Postgres — 0.5 vCPU / 1 GB RAM + 10 GB disk
• Cache (Redis-style) — 0.25 vCPU / 0.25 GB RAM

No GPUs, no multi-region sprawl, no freak requirements — the modal early-stage backend. Egress is broken out separately at the end, because the two vendors treat it differently enough to deserve its own paragraph.

Scenario 1: the steady month​

Assume every service runs 24/7 at roughly its full footprint. Here is Sevalla, mapped to the smallest pod that fits each service (application pricing, database pricing):

Two judgment calls, shown so you can audit them: Postgres needs 10 GB of disk, and the $5 database tier ships only 1 GB while the next tier up carries 5 GB — so the right-sized answer is that $34 tier plus the $10 disk add-on rather than jumping to the $65 tier. The cache takes the $5 hobby pod, whose one limitation (no custom domain) is irrelevant for an internal service. Builds add roughly $1–2 at $0.02 per build-minute for a normal deploy cadence.

Now Railway, at its published metered rates — $10/GB RAM, $20/vCPU, $0.15/GB-month for volumes — on the Hobby plan ($5/month, which comes back as a $5 usage credit):

Same stack, same footprint, same total: $69 on both. That tie is the single most useful fact in this comparison, because it reframes the question. At full steady-state utilization, Sevalla's fixed tiers are priced almost exactly at Railway's metered unit rates — a 1-CPU/2-GB standard pod costs $40, which is precisely $20 + $20 at Railway rates. The fixed-vs-metered debate is not about the unit price. It is about what happens when your actual consumption stops matching the footprint you reserved.

Scenario 2: the bursty month​

Real workloads breathe. The worker sits near-idle between queue drains; the web app's CPU halves overnight; the database hums along unchanged. Say the web app averages 50% of its CPU and the worker averages 10%, with RAM footprints unchanged (idle processes still hold memory — metering doesn't make RSS disappear).

Railway bills what the service actually consumes, so the bill moves:

That is a 20% drop for doing nothing — no resizing, no schedule, no intervention. Preview environments you spin up and tear down behave the same way: metered for the hours they exist, free afterwards. This is the entire case for usage-based billing in one number.

Sevalla's answer to the same month is $69, unchanged — fixed tiers don't breathe. The platform's lever here is hibernation: you can pause pods you don't need and stop paying for them. That works well for staging and preview pods on a schedule, but it is a manual action per pod, not an automatic property of the billing model. Production services that idle overnight still cost their full tier price.

So the bursty-month scoreboard reads: metered wins by roughly $14 on this stack, and the gap widens with every service whose average CPU sits far below its provisioned size. Note the asymmetry that matters: RAM-heavy-but-CPU-idle services (caches, sidecars, small JVMs) save little under metering, because their footprint is their consumption. The workloads that win big are CPU-spiky ones — workers, cron jobs, build-adjacent services.

Scenario 3: the bad month​

Now run it the other way. A launch-week traffic spike triples web and worker CPU for a quarter of the month, and pushes an extra 200 GB of egress. On Railway:

• Extra compute: ~1 extra vCPU × ¼ month × $20, on two services ≈ +$10
• Extra egress at $0.05/GB × 200 GB ≈ +$10
• New total: roughly $89, up 29% — and nothing about the bill warned you in advance beyond the usage graph climbing.

A subtler version of the same story is the slow memory leak, which Railway's own pricing FAQ names as a top cause of surprise bills: a worker whose RAM doubles over two weeks bills double for those two weeks. Metering is symmetric. It discounts your idle hours and it invoices your incidents.

Sevalla's bad month costs $69 — the same as every other month. The tier price is a ceiling: a spike can saturate your pod (and then you resize up, deliberately, knowing the new number), but it cannot silently multiply your invoice. That ceiling is what "predictable billing" actually means in practice. It is not that fixed pricing is cheaper on average — Scenario 1 showed it ties — it is that the worst case is printed on the pricing page instead of discovered on the invoice.

Railway does offer mitigations: configurable usage limits that can take workloads offline at a cap, plus alerts. Use them — "metered with a cap" recovers most of the predictability story. But a cap that pages you at 2am by stopping production is a different product than a tier that absorbs the spike and stays up. Know which failure mode you prefer before the bad month picks it for you.

The egress footnote both bills share​

Compute is where the philosophies differ; bandwidth is where both vendors quietly agree that traffic isn't free. Railway meters egress from the first byte at $0.05/GB with nothing included. Sevalla includes an allowance and charges $0.10/GB beyond it. At modest traffic (tens of GB) this is a few dollars either way; at media-serving scale (terabytes) it can exceed the compute line on both platforms — a 2 TB month costs roughly $100 on Railway's rate card. If your app serves images, video, or large downloads, price the egress row before you price anything else, and serve bytes from object storage or a CDN rather than your app pods.

The tax both charge: per-service multiplication​

Step back from the $69-vs-$55 debate and notice the shape both bills share: every service you add multiplies the total. A fifth service (search? queue dashboard? second database?) adds another $10–20 whether the unit is a tier or a meter. Eight always-on services land near $140/month on either platform, and nothing about fixed-vs-metered changes that slope. The per-service multiplication tax is the PaaS business model, not a pricing detail.

The number that collapses it is a flat-rate box. The entire four-service stack above — 1.75 vCPUs, about 3.25 GB of RAM, 10 GB of disk — fits comfortably on a single Hetzner Cloud box in the ~€4–9/month range (the entry 2-vCPU/4-GB tier starts around €4, with 20 TB of included traffic that makes the egress paragraph above evaporate). Even the eight-service version fits on one modestly larger box. Raw infrastructure for this stack costs roughly a tenth of either PaaS bill.

That 10× gap is real, and it is also the least surprising number in this post, because the $60 delta was never buying raw compute. It buys managed Postgres with daily backups, private networking between services at no extra charge, TLS and custom domains without certbot archaeology, autoscaling and 25 regions on Sevalla's side, minute-level metering and instant preview environments on Railway's — and, above all, the absence of 3am pages about a database disk filling up. Self-hosting on a flat-rate box under Cluster API or a lightweight PaaS layer keeps the flat number while automating most of that away, but "most" is doing honest work in that sentence: you still own backups, upgrades, and the on-call rotation. Price your own ops time at anything above zero before declaring the 10× gap pure savings.

The decision rule​

Three lines, in order:

1. Steady and predictable → fixed tiers. If your services run near their footprint all month and you value a worst case printed on the pricing page, Sevalla's model wins on peace of mind at no cost premium.
2. Bursty or idle-heavy → metered. If your average CPU sits well below provisioned, or you spin preview environments up and down weekly, Railway's metering discounts every idle hour automatically — expect 15–25% under the fixed equivalent on a typical mix.
3. Many always-on services → count services, not CPUs. Past a handful of services, both models converge on "roughly $15–20 per service per month," and the only lever left is leaving per-service billing entirely for a flat-rate box you operate.

The fixed-vs-metered debate was never about which vendor is generous. It is about which variable your workloads actually vary on — and now you have the table to check.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with flat-rate economics instead of per-service metering. Star the repo on GitHub or deploy your first app today.