Railway

Overview

Railway is a usage-based application platform (PaaS) for shipping apps, databases, volumes, functions, and background jobs without managing Kubernetes yourself. The company ships under railway.com (legacy railway.app still redirects). You connect GitHub, push a Dockerfile or let Nixpacks/Railpack detect your stack, and Railway builds, runs, networks, and observes the service on its own infrastructure (“Railway Metal”).

Primary job: give solo builders and small product teams a Heroku-class deploy path with modern DX—project canvas of services, private IPv6 networking between them, managed Postgres/MySQL/Redis/MongoDB/ClickHouse templates, automatic TLS domains, CLI + MCP for agents, and per-second CPU/RAM billing instead of pre-sized dynos.

As of mid-2026 the product surface is broader than “git push web app”: Railway Agent (dashboard + Slack/Discord), agent skills / local and remote MCP, CLI agents setup (curl -fsSL agents.railway.com | sh), feature flags, sandboxes, object storage/buckets, Functions (Bun TypeScript), mobile iOS app, and committed-spend / Enterprise compliance paths (SOC 2 Type II, SOC 3, HIPAA BAA add-on, DPA).

Key features

• GitHub autodeploys + CLI deploys — Branch-linked deploys on push; railway up from local directories; Docker image deploys; monorepo root-directory support per service.
• Nixpacks / Railpack / Dockerfile — Default language detection and builds; override with a root Dockerfile or config-as-code (railway.toml / railway.json).
• Project canvas — Visual graph of services, databases, volumes, and variable references (${{ServiceName.VAR}}) so multi-service apps stay one project.
• Managed databases — One-click Postgres, MySQL, Redis, MongoDB, ClickHouse (and related templates). Database view, backups, PgBouncer options, private DNS like *.railway.internal.
• Private networking — Services in a project talk over private IPv6; public HTTP/TCP/WebSocket/gRPC via domains with automatic certificates.
• Volumes & buckets — Persistent disks for stateful workloads; object storage patterns via templates or external S3-compatible providers.
• Horizontal & vertical scale — Replicas with load balancing; CPU/RAM limits per service; region pinning where plan allows.
• Serverless (app sleep) — Optional idle scale-down after ~10 minutes without outbound activity to cut usage cost; cold starts and possible first-request 502s are documented trade-offs.
• Environments & PR previews — Isolated production/staging (and PR) environments with separate variables and data unless you wire them deliberately.
• Observability — Build/deploy/runtime logs, CPU/memory/network metrics, deploy history, one-click rollback within image-retention windows, healthchecks for zero-downtime cutover.
• Railway Agent + MCP + CLI — Natural-language ops in the dashboard; local MCP via CLI and remote MCP at mcp.railway.com; Slack/Discord agent integrations; Claude Code plugin and agent skills.
• Feature flags — Built-in progressive rollout flags (2026) controllable from CLI/SDK/MCP without a third-party flag service.
• Templates marketplace — One-click stacks (Metabase, Strapi, WordPress, MinIO, Umami, etc.) for common apps.
• Enterprise controls — SAML SSO, audit logs, environment RBAC, org guardrails (networking/deploy source policies), Trust Center reports.

Pricing

Railway bills a plan subscription plus resource usage (CPU, memory, volume storage, egress). Subscription dollars apply toward usage: if usage stays under the included credit, you pay only the plan fee; overage is charged as the delta. Rates and plan tables below are from official docs (pricing/plans) and railway.com/pricing as of mid-2026—always recheck the live page before budgeting.

Plan	Subscription	Included usage	Typical maxes (per service)	Best for
Trial	$0 + one-time $5 credit	Trial grant	~2 vCPU / 1 GB RAM; limited volume	First deploy, no card required for trial path
Free	$0	~$1/mo resource credit	1 replica; 1 vCPU / 0.5 GB RAM; small volume/image caps	Tiny experiments after trial
Hobby	$5/mo	$5 usage included	Up to 6 replicas; 48 vCPU / 48 GB RAM; ~5 GB volume; 100 GB image	Side projects, solo builders
Pro	$20/mo (per seat / workspace tier as listed)	$20 usage included	Up to 42 replicas; 1,000 vCPU / 1 TB RAM; volumes up to 1 TB self-serve; unlimited image size	Production apps, teams, collab
Enterprise	Custom	Contract / committed spend	Higher ceilings (e.g. multi-TB RAM/CPU class); SSO, SLA, procurement	Regulated / large orgs

Resource rates (docs): RAM ≈ $10/GB/month ($0.000231 per GB-minute); CPU ≈ $20/vCPU/month ($0.000463 per vCPU-minute); network egress ≈ $0.05/GB; volume storage ≈ $0.15/GB/month. You are charged for what the workload actually consumes, not for idle “reserved instance” markup—but a process that never sleeps still accrues full-time CPU/RAM.

Bill shape examples (from docs logic): Hobby with $3 usage → pay $5 total. Hobby with $7 usage → pay $7 ($5 sub + $2 overage). Same pattern on Pro with $20 included. Credits and included usage do not roll over. Post-paid card is required (prepaid credit-only flow was removed historically; docs note post-paid card requirement).

Rough always-on math: ~1 vCPU 24/7 ≈ $20/mo CPU; ~1 GB RAM 24/7 ≈ $10/mo memory before egress/volumes. A small 0.5 GB / fractional-CPU web service can fit near Hobby’s $5 envelope if it stays light or uses serverless sleep; a 2 GB / 2 vCPU always-on box is commonly tens of dollars/month and is why Reddit threads ask “is Railway expensive?”—the answer is “cheap for tiny/idle-friendly apps, not a bargain for large always-on VMs versus a raw VPS.”

Other commercial notes: Agent (LLM) usage is tracked separately from compute with default hard caps (docs: ~$5 Hobby / ~$20 Pro agent limits, adjustable but not fully removable). Business Class support is a Pro add-on; included on Enterprise. Annual committed spend discounts exist for Pro/Enterprise. Image retention for rollback: Free/Trial 24h, Hobby 72h, Pro 120h, Enterprise 360h. Data retention after cancel: Free/Trial ~30 days, Hobby ~60, Pro ~90 after warnings.

Limits & gotchas

• Usage surprises — Always-on multi-GB services, high egress, large volumes, and multiple replicas stack quickly past the $5/$20 included credits. Community threads regularly compare a $5–20 “feel” with actual $50–100+ months for multi-service stacks.
• Plan ceilings — Free is for toys; Hobby volume cap (~5 GB) bites databases/media; Pro unlocks serious RAM/CPU/volume and collaboration.
• Serverless cold starts — First request after sleep can be slow or return 502; not ideal for latency-sensitive APIs or anything that must answer in <100ms always.
• Not multi-cloud DIY — You run on Railway’s regions/Metal, not arbitrary AWS account topology. Multi-region and advanced networking need plan support and design work; this is not full AWS/GCP freedom.
• Reliability incidents (real 2026) — Public postmortems include a Feb 11, 2026 abuse-enforcement false positive that SIGTERM’d a subset of workloads (~<3% fleet, including some DBs) and a July 2, 2026 US East AZ major outage. Railway publishes status + blog incident reports—plan for multi-region or external DB if you need higher independence.
• Account verification / fraud controls — New GitHub accounts and abuse systems have blocked deploys historically; expect ID/GitHub age checks and partial mid-cycle charges for fraud risk.
• Collaboration gated — Serious multi-seat workspaces and permissions are Pro/Enterprise territory.
• Compliance is shared-responsibility — SOC 2/3 via Trust Center; HIPAA BAA is a paid spend-threshold add-on, not free on Hobby; GDPR DPA is available. Encrypt and design PHI carefully.
• Ecosystem lock-in is moderate — Standard containers + Postgres reduce lock-in, but private DNS, Railway variables, and canvas wiring are platform-specific; budget migration effort like any PaaS.
• Build/runtime edge cases — Procfile multi-process Heroku myths, monorepo root mistakes, missing start commands, and Node SIGTERM handling show up in docs troubleshooting and forums—read healthcheck + start-command guides for zero-downtime deploys.

Community sentiment

Across r/railwayapp, r/webdev, r/SaaS, Hacker News, and Railway Station, Railway is repeatedly framed as the default modern Heroku alternative for people who want canvas-level multi-service apps without Kubernetes.

Praise: fastest path from repo to URL; excellent support stories (HN users often call support “stellar”); private networking + DB templates beat stitching three free tiers; usage pricing feels fair when services sleep or stay small; agent/CLI/MCP story is ahead of many PaaS peers in 2026; good for Next.js/Node/Rails/Django side projects and early startups.

Criticism: bills climb once you run “real” always-on memory; Free tier too small for serious demos; occasional platform outages and dashboard flakiness reported on HN; some users prefer Fly.io for global edge/machines control or a $5–12 VPS for predictable static cost; Rails multi-process and complex worker layouts need more manual service splitting than Heroku Procfile nostalgia.

Pricing threads (e.g. r/webdev “Is Railway expensive?”) usually resolve to: measure your constant RAM×CPU; enable sleep where possible; set hard limits; compare to Render fixed instances and Hetzner/DigitalOcean VPS TCO rather than comparing only the $5 headline.

Who should use it

• Indie hackers and solo founders shipping full-stack apps with a DB and a worker who want one bill and a canvas, not three vendors.
• Startups on Pro that value deploy speed, PR previews, team seats, and SOC 2 paperwork via Trust Center over deep AWS specialization.
• Teams using AI coding agents that should deploy/fix infra via CLI, MCP, or Railway Agent without a human YAML ritual every time.
• Heroku migrants who want usage-based cost and modern private networking—with eyes open that multi-process apps become multiple Railway services.
• Less ideal: ultra-predictable $X VPS budgets with no tolerance for usage variance; workloads needing specialized GPU training clusters; orgs that must own every AZ and IAM policy in their own cloud; ultra-latency edge static sites better on pure CDN/frontend hosts (Vercel/Netlify/Cloudflare) unless you need the long-running API/DB side too.

Alternatives

• Render — Similar PaaS; often compared on free tier shape, fixed instance pricing vs Railway usage meters, and dashboard style.
• Fly.io — Machines closer to the metal, strong multi-region story; steeper ops curve, mixed reliability reputation depending on era.
• Heroku — Classic DX and add-ons; typically pricier dyno model; Railway/Render are common exit ramps.
• Vercel — Best for frontend/serverless Next.js; pair with Railway/Neon/etc. for long-running backends and classic DBs.
• DigitalOcean App Platform / Droplets — More traditional cloud pricing; App Platform competes on PaaS, Droplets on VPS control.
• AWS (ECS/Fargate/App Runner/RDS) — Maximum control and enterprise gravity; far more assembly required.
• Coolify / CapRover / Dokku — Self-hosted PaaS on your VPS when you want Railway-like DX with fixed server cost.
• Supabase / Neon — Database-first backends; often combined with Railway for the app tier rather than pure substitutes.

Verdict

Railway in 2026 is a strong default for shipping multi-service apps quickly on usage-based infrastructure: Hobby at $5 and Pro at $20 with included usage credits, real per-second CPU/RAM meters (~$20/vCPU-mo, ~$10/GB-mo), managed data stores, private networking, and an unusually agent-friendly CLI/MCP surface. Choose it when developer time and cohesive project networking beat raw $/vCPU against a VPS. Set spend limits, design for sleep or right-size always-on memory, and treat public incident reports as a reminder to keep backups and an exit plan—same as any managed PaaS. For edge-only frontends or iron-clad multi-cloud control, look elsewhere; for “repo + DB + worker in one canvas,” Railway remains one of the clearest paid options.