Deploying on Railway

Railway feels like Heroku grew up. You connect a repo, Railway builds it, gives you a URL, and you add a Postgres instance from a menu. No Kubernetes certificate to debug at 2 a.m.

The UI is a canvas — boxes for your web service, database, Redis, workers, connected by lines. It matches how you already draw architecture on a whiteboard.

Services and the canvas

Each service is one deployable unit. Usually one Git repo or one Docker image.

You might have:

• A web service running your Node or Python API
• A worker service running the same repo with a different start command
• A Postgres plugin
• A Redis plugin

Railway injects connection strings into your app’s environment. Your web service reads DATABASE_URL. No manual copy-paste after the first link.

The canvas is not just eye candy. It shows what talks to what. When StackPlan recommends Railway, it is often for teams who want multiple processes — API plus background worker — without managing two VPSes.

Usage-based pricing

Railway bills on actual resource use, not fixed instance sizes.

You pay for vCPU, memory, and network egress consumed by your services. Databases and Redis add their own line items. There is a free trial credit; after that you add a payment method and usage accrues monthly.

This model is great when:

• Traffic is spiky — you are not paying for a 4 GB RAM server sitting idle
• You run one small app that needs Postgres and does not fit serverless

Watch out when:

• Something leaks memory or loops — bills climb quietly
• You leave staging environments running 24/7
• You run many services with always-on minimums
• A noisy neighbor in your own code — one worker pegging CPU raises the whole project bill

My advice: set a spending limit in Railway’s settings and enable notifications. Usage-based is fair until it is not.

Postgres and Redis add-ons

Railway’s managed Postgres is the main reason people pick the platform. Click “New”, choose Postgres, connect your app. Backups and version upgrades are Railway’s job.

Redis is one click too. Sessions, rate limits, Sidekiq-style job queues — same pattern.

You are not locked to Railway’s Postgres forever. It is standard Postgres with a connection URL. Export and move when you outgrow it.

For indie SaaS with relational data, Railway plus Postgres is a sweet spot: real SQL, no server patching, deploy from Git in minutes.

Deploying from a repo or Dockerfile

From Git — Connect GitHub, pick a repo, Railway detects the language. Set the start command if needed (npm start, uvicorn main:app). Every push to main can auto-deploy.

From Dockerfile — Drop a Dockerfile in the repo. Railway builds the image and runs it. Use this when you need a custom OS package, a specific Python version, or a multi-stage build.

Environment variables live in the Railway dashboard or CLI. Secrets stay out of Git.

Custom domains and HTTPS are built in. Point a CNAME, Railway provisions a cert.

Logs and metrics live in the dashboard. You can stream them to external tools later if you outgrow the defaults.

When Railway fits

Railway works well when:

• You want managed Postgres without AWS complexity
• Your app is a traditional server process — Express, FastAPI, Rails, Django
• You need a worker alongside a web tier on the same project
• You value speed over squeezing the last dollar from a VPS

StackPlan recommends Railway for full-stack apps that outgrow serverless limits but do not need multi-region edge yet.

When to skip it

Look at Fly.io or a VPS when:

• You need specific regions close to users worldwide
• Scale-to-zero matters for rarely used services
• Usage-based pricing would exceed a €5 Hetzner box at steady load

Railway is the comfortable middle ground. You trade some cost optimization for a dashboard that respects your time.

If that trade sounds right, the remaining question is how your app’s CPU, memory, and database size translate into a monthly number — not a vague “usage-based” shrug.