Railway

What Railway actually is

Railway is a deployment platform for application developers: push code (from GitHub or a Dockerfile), get a running service with logs, metrics, private networking, volumes, databases and object storage, without writing infrastructure config. It was launched in 2020 by Jake Cooper (better known as @jakerunzer) and is run as a remote team. The pitch on the pricing page is blunt — "pay only for what your app uses, by the second" — and the whole product is built around that claim: no instance sizes to pick, no preprovisioning, just resource metering.

We'd place Railway in the modern PaaS tier alongside Render and Fly.io, but with a billing model closer to raw cloud. It is not a VPS substitute — you do not get root on a machine, and you cannot run arbitrary kernel-level workloads. What you get instead is a very short path from repository to production service, plus first-class database provisioning (PostgreSQL, MySQL, Redis and Mongo templates all deploy in a click) and a config-as-code file for when the UI stops being enough. Our category for it is /category/managed-cloud.

Pricing: what you really pay

The plans are published and the arithmetic is documented, which we appreciate. Free is listed at $0 per month: start with a 30-day free trial carrying $5 of credits, then $1 per month, capped at 1 vCPU / 0.5 GB RAM per service with 0.5 GB of volume storage and community support. Hobby is $5 minimum usage — a $5 monthly subscription that includes $5 of resource usage. Pro is $20 minimum usage with $20 of included usage per seat, unlimited workspace seats, 30-day log history and a 99.99% availability target. Enterprise is custom; third-party pricing trackers report a $2,000/month minimum commitment, which we have not confirmed with the vendor.

The metered rates behind those credits are the part that decides your bill: $20 per vCPU per month, $10 per GB of RAM per month, $0.15 per GB-month of volume storage, and $0.05 per GB of network egress, with compute billed per second while a service actually runs. The docs work the example honestly: on Hobby, $3 of usage still bills $5 (the subscription), while $7 of usage bills $7 ($5 subscription plus $2 over the credit). The subscription is a floor, not a separate fee.

What does that mean in practice? A small API averaging 0.25 vCPU and 0.5 GB RAM runs roughly $10 of usage a month by our reading of the published rates, and an app plus Postgres with 2 GB RAM, a 5 GB volume and 50 GB egress lands near $38. Compare that with fixed-tier platforms: one reviewer's published comparison puts Render's smallest always-on instance at $7/month and Fly.io's at $2.19/month — cheaper floors, but less elastic. Railway's own page carries customer quotes claiming bills of "like $300 per month" after moving $4.5k of AWS and $1k of Heroku spend, and a second claiming a drop from a $1,600 Heroku bill to $300. Those are marketing quotes, not our tests, but the mechanism behind them is real: second-level metering charges idle services almost nothing.

Two pricing details people get burned by. First, egress at $0.05 per GB adds up for media-heavy or API-heavy workloads with no included allowance on the metered resources. Second, the per-GB RAM and per-vCPU rates are expensive compared with a dedicated VPS — running a database at 2 vCPU / 4 GB continuously is roughly $80/month of usage before storage, where a $8/month VPS would do it. Railway sells convenience and elasticity, not raw compute per dollar. Object storage (Railway Buckets) is a bright spot at $0.015 per GB-month with free egress and free API operations.

Performance & infrastructure

Railway runs its own hardware across four deploy regions: US West (California), US East (Virginia), EU West (Amsterdam) and Southeast Asia (Singapore). All regions offer the same experience; a service can change regions without touching domains or private networking, though a volume attached to it has to migrate and that move causes downtime. Volume storage is documented at 3,000 read and 3,000 write IOPS across all plans — modest but predictable block storage.

Storage options cover most application shapes: volumes (persistent block storage mounted at runtime), managed database templates, and Railway Buckets — private, S3-compatible object storage that works with standard S3 client libraries (virtual-hosted-style URLs, presigned URLs, multipart uploads and tagging supported; server-side encryption, versioning and lifecycle rules are not yet supported). Each environment gets its own bucket credentials, which is a nice isolation property for preview environments.

Availability commitments are targets rather than contractual SLAs outside Enterprise: 99.9% on Hobby and 99.99% on Pro, per the pricing page. We treat those as engineering goals, not guarantees — the fine print lives in the Enterprise agreement. On reliability in general, Railway is a young platform and has had well-publicized incidents; the transparency of its incident communication is good, but we would not run hard compliance workloads here without an Enterprise agreement.

The developer experience is where the platform earns its reputation. Deploy from GitHub with no config file, attach a Postgres database in the click of a button, watch builds and runtime logs in one UI, add a volume or a bucket when needed, then graduate to config-as-code (multi-region configuration included) and the CLI. Templates cover one-click deploys of popular open-source stacks — MinIO, SeaweedFS and hundreds of others — which doubles as an escape hatch: if the platform's native offerings fall short, you can host the equivalent yourself on a volume.

Where it falls short

The headline weakness is cost at scale. Railway is priced for elasticity, so a workload that runs hot continuously pays multiples of what fixed infrastructure costs. Teams that leave a chatty service on a 2 vCPU / 4 GB allocation can watch the meter climb past $80/month for a single service, and egress-heavy products (video, downloads, public APIs) can see bandwidth dominate the bill. The pricing page's savings stories are all about leaving overprovisioned cloud or expensive PaaS tiers — not about beating a cheap VPS.

Second, the usage model genuinely surprises people. The floor ($5 or $20) is easy; the metered tail is not. If you cannot estimate your average vCPU/RAM draw, you cannot forecast your bill, and the fix — setting limits and alerts — is on you. Our cons in the database say "pricing can surprise at higher usage levels" and that is fair.

Third, platform boundaries. There is no root access, no arbitrary kernel modules, no GPU compute, and no published DDoS mitigation product — you are trusting Railway's edge and networking posture without a documented guarantee. IPv6 support and built-in volume backups are not documented either (we leave both unverified rather than guess). For compliance-sensitive workloads, note that region choice is broad but the contractual paperwork only exists at Enterprise tier.

Fourth, the free tier is thin in absolute terms — 1 vCPU / 0.5 GB RAM per service and 0.5 GB of volume storage — and the post-trial $1/month step is easy to miss. This is not a criticism so much as calibration: the free tier is for evaluation and tiny side projects, not for hosting anything with users.

Who should pick this

We'd pick Railway when time-to-production is the binding constraint and the workload is variable: side projects, internal tools, MVPs, staging environments, event-driven workers, AI agent backends, and small teams who want Postgres plus an app plus object storage without operating any of it. It is also a strong fit for teams migrating off Heroku-class pricing who still want the developer experience, and for anyone whose spend already sits at the low hundreds per month on a hyperscaler and who values a simpler bill over the last dollar of efficiency.

We'd look elsewhere when: the workload runs hot and steady (a VPS in /category/vps-providers will beat it on price by an order of magnitude), you need root or custom kernels, you need contractual SLAs and compliance documentation, or you are egress-heavy. A common and sensible split we see: keep the app on Railway for velocity, keep large media in cheap object storage, and move steady database workloads to a VPS or managed database service once the usage pattern is stable. For platform comparisons in this space, our /benchmarks pages track the compute side.

Key takeaways

• Usage-based pricing with per-second compute billing: $20/vCPU-month, $10/GB-month RAM, $0.15/GB-month volumes, $0.05/GB egress; subscriptions ($5 Hobby, $20 Pro) act as usage credits, not extra fees.
• A real free tier exists ($0/month with $1 of monthly credit after a 30-day, $5-credit trial) — thin limits, but no credit card required.
• Four regions (California, Virginia, Amsterdam, Singapore) with same-experience deploys and per-environment isolation.
• Railway Buckets are fully S3-compatible object storage at $0.015 per GB-month with free egress — unusually cheap for a PaaS add-on.
• The developer experience (GitHub deploys, one-click databases, config-as-code) is the reason to pay the usage premium.
• The trade-offs are cost at steady high utilization, metered-bill surprise, and thin guarantees outside Enterprise; our overall view lands at 3.9/5.

Sources

• https://railway.com/pricing
• https://docs.railway.com/reference/pricing/plans
• https://docs.railway.com/deployments/regions
• https://docs.railway.com/storage-buckets
• https://docs.railway.com/guides/object-storage-for-ai-agents
• https://railway.com/about
• https://startupspotlight.co/q/who-founded-railway
• https://costbench.com/software/developer-tools/railway
• https://techverdict.io/articles/railway-vs-render-2026
• https://appstackinsider.com/insights/railway-pricing-explained