1.0.0 deliberately publish no latest tag, so every deployment names an explicit version. That prevents an unattended docker pull from moving a running instance onto a schema it has not been tested against.
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.
Four 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.
The checked in
docker-compose.yml builds both images from source rather than pulling them. A supported pull based Compose file arrives with 1.0.0. Until then, use the docker run sequence above when you want pinned images without a clone.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.