TL;DR: Push to GitHub, connect the repo to Railway at railway.app, and Railway auto-detects your stack and builds. For LingCode-side deploys, paste a Railway token into Magic Deploy β Railway and click Ship. No Dockerfile needed for most stacks.
Railway is what happens when you take Heroku's simplicity, add real-time logs, give it 2020s pricing transparency, and don't make the user fight a Dockerfile. Point at a GitHub repo; thirty seconds later, your app is on the internet at a real URL.
The thing that made early Heroku magical was that you didn't have to think. git push heroku main. The dyno started. The URL worked. You'd get to the actual problem you were trying to solve in minutes instead of hours. Then Heroku got expensive, lost its free tier, and stagnated for years. The market noticed and a small wave of replacements arrived. Of those, Railway has done the cleanest job of recreating "the magic" while solving the problems Heroku didn't.
Railway's pitch is: connect a GitHub repo, they detect what kind of project it is (Node, Python, Go, Ruby, Rust, anything), they figure out the build, they deploy, you get a URL. The whole flow is fifteen seconds of UI clicks plus the build time. If your app needs a database, add a Postgres or Redis from a side menu; the connection string is automatically injected as an env var. If your app needs a worker, add another service. The mental model is "a project is a collection of services that share env vars and a private network." It maps to what real apps look like without making you build a yaml file.
The trade-off is opinionatedness. Railway picks the build path; you can override but doing so feels like fighting the platform. Pricing is usage-based (you pay for compute-time and RAM-time, not a flat monthly plan), which is great when usage is low and surprising when it's high. For most indie projects and side businesses, Railway is the cheapest path to "real production-shaped infrastructure." For specifically-shaped enterprise workloads, the opinionatedness becomes a problem.
Sign up at railway.com with your GitHub account. Railway requests permissions to read your repos β you can scope this to specific repos rather than "all" if you prefer. The free trial gives you $5 of usage credit; from there you pick a plan.
Railway's pricing changed in 2023 β there's no longer a free tier in the old sense, but the $5/month Hobby plan is real and the $5 credit is enough to test for hours.
Click New Project β Deploy from GitHub repo. Pick the repo. Pick the branch (defaults to main). Railway scans the repo, detects the stack (e.g., "this is a Next.js app"), and starts building.
Within 30β90 seconds the first deploy is live. Railway generates a public URL like my-app-production.up.railway.app that's HTTPS-by-default. Click it; your app should load.
railway.toml at the project root or set explicit start commands in the service settings. The detection is usually right for the common stacks; expect to override for monorepos or unusual setups.
In the Railway project view, click the empty space and pick Add Service β Database. Pick Postgres, MySQL, MongoDB, or Redis.
Railway provisions the database in seconds and exposes a connection string as an env var inside the project's network β your app service automatically gets DATABASE_URL in its environment without you setting it manually. The database is private to the project; nothing on the public internet can reach it.
In the service's Variables tab, set any env vars your app needs (SECRET_KEY, third-party API keys, etc.). Two patterns worth knowing:
${{ Postgres.DATABASE_URL }} imports the database's connection string into your app's env without copying the value.Variables are encrypted at rest; the dashboard shows them masked by default.
Click your service, go to Settings β Networking, click Custom Domain. Enter your domain. Railway shows a CNAME target (something like your-app.up.railway.app) to point your DNS at.
At your DNS provider, add a CNAME for the subdomain pointing at that target. For apex domains, Railway supports ALIAS / flattened-CNAME at hosts that allow it (Cloudflare, Route 53, etc.). Within a few minutes Railway issues TLS automatically.
Real projects want a staging environment to test before main goes live. In Railway, click Environments β New Environment and duplicate from production. Railway sets up an independent copy with its own URLs and (cloned) database. You push to the staging environment's branch; promote to production when ready.
This is the gap Railway closes that Heroku never quite did β a real two-environment workflow without learning yet another tool.
Railway charges for CPU-time, RAM-time, network egress, and database storage. Pricing is per-service. A small idle app on the Hobby plan ($5/month) is usually fine; an app that spikes (long-running cron jobs, large container builds, lots of bandwidth) can climb.
Set a usage limit in your account settings β Railway will shut services down when you hit the cap rather than letting the bill grow indefinitely. This is the single most important configuration; do it on day one.