Deploy to Railway
Push to Git, get a URL. The least ceremony of anything here.
Getting something in front of people today. Postgres and Redis are one click and wire themselves into your service.
Cost-sensitive workloads that run hot — usage billing is generous until it is not, and there is no hard spend cap.
Setup
- 1
Create the service from your repo
Railway finds the Dockerfile and builds it. For a monorepo, set the service root to the API directory so it does not try to build the whole tree.
Root directory: apps/apiBuilder: Dockerfile - 2
Add Postgres and Redis
Add them from the same project canvas. Railway exposes them as variables you reference rather than copy — so a rotated password propagates instead of silently breaking the app.
DATABASE_URL=${{Postgres.DATABASE_URL}}REDIS_URL=${{Redis.REDIS_URL}} - 3
Bind to the port Railway gives you
Railway injects PORT. Grit reads APP_PORT, so map one to the other rather than hardcoding 8080 — the assigned port is not stable.
APP_PORT=${{PORT}} - 4
Run migrations
Grit does not auto-migrate on boot in production — a process that rewrites the schema every time it restarts is a bad idea when the platform can restart it for its own reasons. Run migrations as an explicit step. Railway’s one-off command runs in the same environment as the service, so it sees the same DATABASE_URL.
railway run /app/migrate
What catches people out
The generated Dockerfile builds only the API. A monorepo with a separate web app needs a second service, not a second process in the same one.
Sleeping is not available on all plans; an always-on service bills continuously even with no traffic.
Set a usage alert on day one. Railway bills by consumption and a runaway job queue is an expensive way to find that out.
Platform dashboards and CLI flags change faster than these docs. For anything that looks different from what is written here, Railway's own documentation is the authority: docs.railway.com/