latest tag that follows the newest version, so a deployment that names no tag tracks the current release.
Pin an explicit version when you want an upgrade to be a decision rather than a restart. A release can carry a schema migration, and latest moving underneath an unattended docker pull applies that migration on the next restart.
Which images are published?
Each GitHub release builds both applications forlinux/amd64 and linux/arm64, signs a build provenance attestation and pushes them to GitHub Container Registry.
Five tag shapes are published for every release. Pick the narrowest one your upgrade policy allows.
Run the stack
The sequence below creates the networks and volumes, starts PostgreSQL and Redis on an internal network, attaches the API to both networks and publishes only the web app.--env flag on the API container.
Why two networks?
Separating them is what keeps the datastores unreachable.asobeast-backend is created with --internal, so containers on it have no route off the host.
The web container therefore reaches the API and nothing else, while PostgreSQL and Redis are reachable only from the API. This mirrors what
docker-compose.yml does with its frontend and backend networks.
Run the same images from Compose
docker-compose.pull.yml is the supported Compose path for published images. It declares the identical stack as docker-compose.yml, with the same project name, volumes, memory limits, log limits and health checks, and differs only in running the published images instead of building them. An installation can move between the two without touching its data.
main gets the current file, and that file defaults to the release it was published with, so the copy on your disk is pinned even though the download URL is not. Release Please bumps that default on every release and continuous integration fails when it drifts, so the file you fetch today runs today’s release and keeps running it until you say otherwise.
Two variables in the root .env change what it pulls. ASOBEAST_IMAGE_TAG selects a different release, which is how you pin an older one or roll back. ASOBEAST_IMAGE_OWNER selects the registry namespace and exists for forks. Both are read only by this file.
The file declares no pull policy, so Compose fetches an image it does not already have and otherwise starts what is on disk. Changing the tag is therefore enough to upgrade, and a restart with the tag unchanged never needs the registry, which matters on a machine that reboots without network. Only a moving tag such as latest needs an explicit fetch:
The checked in
docker-compose.yml builds both images from source and declares no image, so docker compose pull cannot move it onto a published tag. Use docker-compose.pull.yml for pinned images, or the docker run sequence above when you want no Compose file at all.Next steps
Self host with Docker Compose
The build from source path, with health checks and volumes handled for you.
Upgrade and roll back
Moving a pinned tag forward, and what to do when it goes wrong.