Railway Hosting vs Render vs Fly.io: Billing Compared

The verdict. For a solo, always-on micro-SaaS, start with Railway when you want the bill to follow what the process actually consumes and you will set limits and watch metrics. Start with Fly.io when one small, explicitly sized Machine is enough and you accept more infrastructure decisions in return for the lowest predictable tiny-VM floor. Pick Render when the extra fixed floor is worth a more opinionated managed-service path and deployment guardrails. Do not choose from “from $0” badges: Railway bills utilization, Fly bills a provisioned Machine while it is started, and Render bills a selected service size. Those are different meters.

What stays billable when nobody is visiting, and what breaks when you use the cost-saving setting?

Proof status. Vendor prices and limits below were fetched from the vendors’ official pages on 21 August 2026 and each vendor figure is inline-linked. The worked example is a model, not production telemetry. Prices for databases, managed add-ons, different Fly regions, taxes, payment processing, and custom contracts are outside the model unless stated; treat them as unverified for your deployment and re-check the linked pages before committing.

1. The operator

Meet Nora, a solo developer with a small B2B SaaS: one public API and web app, a managed database elsewhere, no user uploads, and a background job that is not yet a separate worker. Her real leak is not “I need global scale.” It is that her app is quiet for most of the day, needs to be online when a paying customer clicks, and has no time to turn hosting into a second product.

Nora needs a budgetable idle baseline and a credible recovery path. The number is a consequence of the billing unit, not of the container runtime.

2. The meter: consumption, provision, or service size

Host	What the invoice principally meters	What that means at idle
Railway	CPU, RAM, volume storage, and egress actually consumed, offset by a plan credit	A process holding RAM still costs money; a high limit alone does not.
Fly.io	A named CPU/RAM Machine for every second it is started, plus storage and egress where applicable	A tiny Machine has a clear floor; stopping it changes compute cost but does not erase every storage cost.
Render	The selected service instance type, prorated by the second, plus workspace plan and metered items	You buy a 512 MB/0.5 CPU Starter or a larger fixed service size, whether it is quiet or busy.

As of 21 Aug 2026, Railway Hobby is $5/month including $5 of usage, with RAM at $10/GB-month, CPU at $20/vCPU-month, volume storage at $0.15/GB-month, and egress at $0.05/GB. Its bill is consumption-led, but it is not request-led: Railway says an idle running service still consumes billed CPU and RAM.

Fly bills started Machines per second. In the published Amsterdam pricing matrix, a shared-cpu-1x Machine with 512 MB is $3.32/month; the same page prices North America/Europe public egress at $0.02/GB. This is provision-led: the selected 512 MB Machine is the unit, not Nora’s average 5% CPU reading.

Render Hobby is $0/month plus compute; a paid Starter web service is $7/month for 512 MB and 0.5 CPU, prorated by the second. Hobby includes 5 GB of bandwidth, then $0.15/GB. Render therefore gives a clean selected-size invoice, but its tiny paid floor is visibly higher than the other two in this narrow scenario.

3. The priced worked example: a small API, not a fantasy free tier

Model assumptions. Not vendor measurements. Nora runs one always-on service for 30 days. Observed-like inputs for the fixture are 0.35 GB average RAM, 0.05 vCPU average CPU, and 10 GB public egress. There is no disk, database, custom domain charge, build overage, preview environment, second replica, worker, tax, or managed add-on. Fly is deliberately pinned to Amsterdam because its Machine price is region-specific; its egress assumption uses the vendor’s North America/Europe rate. This is not a performance-equivalence claim: Railway uses average consumption, while Fly and Render require a safe provisioned size.

Host	Calculation	Modelled monthly bill
Railway Hobby	0.35 GB × $10 + 0.05 vCPU × $20 + 10 GB × $0.05 = $5.00 (rates) — Hobby’s $5 credit absorbs it	$5.00
Fly.io	Amsterdam shared-cpu-1x 512 MB: $3.32 + 10 GB × $0.02 (pricing)	$3.52
Render Hobby + Starter	$7 + (10 − 5 GB incl.) × $0.15 (pricing)	$7.75

The arithmetic is simple; the crossover is not. In this fixture, Fly is $1.48/month below Railway and Railway is $2.75/month below Render, derived from the cited inputs, as of 21 Aug 2026. That does not make Fly universally cheapest. It means a single 512 MB Machine is the cheapest fit if it remains a safe fit.

Railway’s important crossover is the $5 Hobby floor. Its modelled resource use reaches that floor exactly: below it, Nora still pays $5; above it, her bill follows average CPU, RAM, and egress. The moment an app truly holds 1 GB of RAM continuously, Railway’s RAM alone is about $10/month, before CPU and egress. That is the point to compare real 30-day metrics with a Fly Machine or Render instance that can safely hold the workload, not an invitation to substitute a smaller VM and call it a savings.

Render’s crossover is operational rather than algebraic. Its Standard service is $25/month for 2 GB and 1 CPU. If Nora needs that fixed capacity, compare it with Railway’s observed consumption and Fly’s chosen Machine in the same region. If the need is only a short daily spike, provisioned-instance math can overstate it; if the app needs the capacity continuously, pretending average utilization is sufficient can understate it. The correct output is a range, not one winner.

4. Where each choice fails

• Railway: the quiet process that never becomes cheap. Railway charges allocated resources rather than traffic; an idle service still bills. Its own billing guide calls out memory leaks, public database connections that create egress, and PR environments that duplicate running services. Set a soft alert and a deliberate hard usage limit, but know the trade: Railway takes workloads offline when a hard limit is hit. A cap is a cost-control tool, not availability engineering.

• Fly.io: “stopped” is not “gone.” A stopped Machine still has root filesystem charges; volumes bill while attached or unattached, including when a Machine is stopped. Fly also warns that metrics-based autoscaling can create Machines if configured to do so, and its cost guide says it does not yet support billing alerts. Build an inventory check for Machines, volumes, snapshots, managed services, and IPs before you call auto-stop a saving.

• Render: the convenient free environment becomes a customer outage. Render explicitly says not to use Free instances in production. A free web service spins down after 15 idle minutes and takes about one minute to spin up; its local filesystem is ephemeral. Pay for the service before an interactive customer workflow depends on it.

• Render with a disk: the deployment trade hides in storage. A persistent disk preserves local state but disables zero-downtime deploys and prevents scaling to multiple instances. Do not use a local SQLite file as an accidental production database and then discover the deployment constraint during an incident.

• All three: “monthly price” hides a second resource. Storage, egress, previews, replicas, databases, and workers are separate objects. A background worker is not free merely because it is internal; Fly says so directly, and Render bills every scaled instance. Price the whole topology.

5. When not to use any of them

Do not migrate just because the current invoice looks wrong. First fix these conditions:

• You have no 30-day RAM, CPU, egress, and uptime evidence. A pricing calculator cannot repair missing measurements.
• The app has a memory leak, polling loop, or oversized response. Moving it moves the waste.
• You need local durable data but have not chosen backups, restore testing, and a managed database or disk strategy.
• The only reason to choose Fly is a headline number but you cannot operate a VM, volumes, regions, and a rollback under pressure.

6. The 30-day host test

Run the same production-shaped staging workload for 30 days, or move one non-critical service first, and record five receipts:

1. Cost: daily spend and the final bill, split into compute, RAM/CPU, egress, storage, previews, and add-ons. Set an alert at 80% of the test budget; where a platform has no alert, calendar a dashboard check twice weekly.
2. Capacity: p50/p95 RAM, CPU, request latency, and error rate. Keep the smallest configuration only if it has headroom at your recorded peak.
3. Wake and recovery: deliberately deploy a bad health check, roll back, and time customer-visible recovery. Render’s health checks hold a new deploy out of traffic until it passes; a failed new deploy continues serving the prior version.
4. State: prove that an upload, migration, or queued job survives the failure mode you expect. Do not count a successful deploy as a backup test.
5. Operator minutes: log every minute spent on deploys, config changes, billing investigation, and incident response. Add that time to the cheap host’s invoice.

Keep the platform only if the measured bill is within budget, the smallest safe capacity has headroom, and recovery is boring. If the cheapest option consumes an evening of operator time or produces one customer-visible wake-up failure, it failed the actual test.

Bottom line

Railway vs Fly.io vs Render is not a container-host beauty contest. Railway sells observed resource consumption with a $5 Hobby floor; Fly sells the time of a Machine you provision; Render sells a chosen managed service size. For Nora’s narrow, 512 MB-class always-on fixture, that yields $5.00, $3.52, and $7.75 respectively from the cited 21 Aug 2026 prices. The durable decision is not the order of those three numbers. It is whether your app is utilization-shaped, capacity-shaped, or operationally constrained, and whether you have 30 days of receipts to prove it.

---

More on this decision, three ways to look at it: