April 18, 2024 • 14 min read
I avoided Railway for ages because I assumed it'd be another toy PaaS. It isn't. I'd been writing Dockerfiles and fighting AWS for side projects that didn't need either, and the friction was enough that I stopped shipping them. Railway reads your repo, guesses the framework, and builds it. Usually it guesses right. I've put 20-odd projects through it now, and the workflow below is the one I keep coming back to.
railway add postgresqlFor a side project this is the difference between shipping it on a Sunday and not shipping it at all. For real production I'd still reach for more control, but most things aren't real production.
Railway reads your repo and figures out the framework on its own, so most of this is just glue. Here's the sequence I run for a new project:
# 1. Initialize Railway project
npm install -g @railway/cli
railway login
railway init
# 2. Link GitHub repository
railway connect
# 3. Add PostgreSQL database (one command!)
railway add postgresql
# 4. Configure environment variables
railway variables set NODE_ENV=production
railway variables set DATABASE_URL=${{PGHOST}}:${{PGPORT}}/${{PGDATABASE}}
railway variables set SECRET_KEY=your-secret-key
# 5. Deploy with git push
git add .
git commit -m "Initial deployment"
git push origin main
# Railway automatically:
# - Detects your framework (React, Django, Express, etc.)
# - Builds your application
# - Sets up SSL certificate
# - Deploys to global CDN
# - Provides custom domainIt's not magic and it's not for everything. The build minutes add up if you leave a service running idle, and the logging is fine until you actually need to debug something, at which point you'll wish for more. But for getting a thing from my laptop onto a URL someone else can open, nothing else I've used gets out of the way this fast. That's the whole pitch.