Deploying on Railway

Deploy a Flask app

1. Create a project and choose Deploy from GitHub repo.
2. Railway detects Python and builds with its builder, or uses your Dockerfile if present.
3. Set the start command if it is not detected, for example gunicorn wsgi:app -c gunicorn.conf.py.
4. Generate a public domain in the service's networking settings to get a *.up.railway.app URL.

Add a database

Add PostgreSQL to the project. Its connection variables can be referenced from your web service, so you never copy credentials by hand:

DATABASE_URL=${{Postgres.DATABASE_URL}}

Variable references keep services linked: rotating the database password updates the app's variable automatically. Use the private networking URL so traffic stays inside the project.

Variables and environments

• Add secrets in the service's Variables tab; the raw editor accepts .env-style text for bulk entry.
• Shared variables apply across services in an environment.
• Environments (production, staging) duplicate the project with separate variables and databases; pull-request environments give previews.

Migrations

Run migrations as part of the deploy with a pre-deploy command (for example flask --app wsgi db upgrade) in the service settings, or chain them in the start command for small apps. Keep them backward compatible.

The CLI

npm i -g @railway/cli
railway login
railway link              # connect the folder to a project
railway run flask --app wsgi db upgrade     # run locally with the service's variables
railway logs

railway run is handy for one-off tasks against the real configuration; be careful when it points at production.

Exercise

Deploy a Flask app with PostgreSQL on Railway using variable references, add a pre-deploy migration step, and create a staging environment with its own database.

Check yourself

• Why reference database variables instead of copying them?
• What do Railway environments give you?
• What does railway run do?