Skip to main content

​
How versions work

Everything in the stack runs the same pinned CRCON release, so the seven services can never drift apart:
  • maintenance and webhooks run the upstream image, pinned by tag.
  • backend, supervisor, and frontend build from this repo, which pins the same tag inside its Dockerfiles.
The template deliberately does not track upstream’s latest tag. A new CRCON release lands here after it has been tested against the Railway setup.

​
Updating your deployment

1

Repo-built services notify you

The backend, supervisor, and frontend deploy from this GitHub repo. When the repo updates, Railway shows an update notification on those services; accepting it rebuilds them from the new commit.
2

Bump the image services to match

When an update changes the pinned CRCON version, also update the image tag on maintenance and webhooks (service Settings, Source) to the same version. The update notes will say when this is needed.
3

Redeploy order

Redeploy maintenance first (it runs the new migrations), then the rest. The backend blocks until the migrations are done, so getting the order wrong delays things rather than breaking them.
Database migrations run automatically on every maintenance deploy. There is never a manual migration step.

​
Version drift warning

If you manually change the image tag on one service, keep all of them in lockstep. Upstream does not support mixed-version stacks, and the database schema is tied to the release the maintenance service runs.

​
Backups

All persistent state lives in the Postgres service’s volume (plus the supervisor’s small scoreboard cache). Railway supports volume backups from the service’s settings; do that before major version jumps.