Updating a Deployment

Updating a deployment

How to pull in new changes for an instance you already have running, using one of the deploy guides' docker-compose.yml — where app.image points at ghcr.io/scotcw/vgde:latest, a prebuilt image published by GitHub Actions on every push to master, rather than building from source on your own host.

The short version

docker compose pull app
docker compose up -d

That's it for most updates. Migrations and the question-bank seed run automatically on container startup — nothing to run by hand.

How the image gets built

A GitHub Actions workflow builds the image once, in CI, and pushes it to GHCR — not on your server. Every push to master updates the latest tag (plus a tag matching the commit SHA, always, for traceability), and pushing a v* git tag additionally publishes that exact version number as its own tag. docker compose pull just fetches whatever latest currently points at; there's no build step, no compiler, no npm install running on the machine hosting your game — which also means no risk of a build filling up disk on a small VPS mid-update, unlike building from source locally.

Migrations run themselves

The container's entrypoint runs prisma migrate deploy against whatever schema changes shipped since your last update, then the idempotent question-bank seed, before the app starts serving traffic. This is a real migration history (committed migration files, not prisma db push), so it only ever applies forward — there's no automatic rollback if a migration turns out to be wrong for your data.

Before updating, especially across a schema change

• Back up the Postgres volume. A quick pg_dump is enough for most setups:

  docker compose exec db pg_dump -U voting_game voting_game > backup-$(date +%F).sql

  Restoring it (docker compose exec -T db psql -U voting_game voting_game < backup-2026-01-01.sql) is your rollback path if a migration does something you don't want — there's no "undo migration" command, only restore-from-backup plus rolling the image tag back to the previous version.
• Check what actually changed. There's no CHANGELOG file — look at recent commits or releases on GitHub. If you're mid-game when you update, finish or abandon it first — the app isn't designed to handle a schema change landing under an in-progress session.

Pinning to a specific version instead of always tracking latest

By default image: ghcr.io/scotcw/vgde:latest always resolves to whatever's newest on master. If you'd rather update on your own schedule instead of picking up every push, point it at an immutable tag instead:

image: ghcr.io/scotcw/vgde:v1.2.0

(a released version tag) or ghcr.io/scotcw/vgde:sha-<short-sha> to pin an exact commit that never had its own version tag. Every image published carries a SHA tag regardless — see the package's tagged versions for what's available. "Updating" then becomes deliberately bumping that tag and running docker compose pull app && docker compose up -d, rather than always tracking latest.

Expected downtime

docker compose up -d only recreates app (its image changed); db is untouched and stays up unless its own service definition changed. The brief gap while app restarts and runs migrations is normal — nothing else to do.