4.2 KiB
Deployment and release
Production deployment
DoGaMa V1 targets one Linux Docker host with the Compose plugin. Use the root compose.yaml, place the public HTTP service behind a trusted TLS reverse proxy, and never publish the agent port.
cp .env.example .env
mkdir -p data/servers data/backups
docker compose config --quiet
docker compose pull
docker compose up -d
The one-shot init service creates the agent token and master encryption key from the operating system cryptographic random source before either long-running service starts. It uses atomic create-without-replacement behavior and restrictive ownership/modes. Repeated starts validate and reuse the existing files; invalid existing files stop initialization instead of generating a replacement. Secret values never enter Compose environment values or logs.
The application data path contains SQLite, import staging and the application-only master key. The internal agent_state volume contains the agent token and authenticated container-binding registry. The registry is durable security state: losing it makes existing containers unknown rather than silently adopting them. The agent never receives the master key.
Only host-side storage locations, image version, web port and timezone are public Compose settings. Container paths and allowed agent roots are fixed internal contracts. Back up the application data, game servers, backups and agent_state volume together.
The application image uses numeric UID/GID 65532:65532. Grant that identity write access to the configured application, server and backup paths. The short-lived initializer runs as root only to establish file ownership and retains CAP_CHOWN, CAP_FOWNER and read/search access needed to validate an existing mode-0600 key; long-running services keep their existing restricted profiles.
Upgrade and rollback
No production deployment predates automatic secret initialization, so this change requires no legacy migration. For future updates, stop DoGaMa, take a filesystem-consistent backup of all four persistent stores, change only DOGAMA_VERSION, then run docker compose pull and docker compose up -d.
Startup applies append-only SQLite migrations before serving requests. Never remove or recreate agent_state, and never replace an existing master key: doing so would invalidate the agent registry or make encrypted notification data unreadable. On failure, restore all state from the same backup point and select the prior image version.
Release pipeline
Normal CI runs for pull requests and pushes to main; it does not publish images. .gitea/workflows/release.yml runs only for tags matching v*.*.*, validates the exact tag commit, then publishes the dogama and dogama-agent images for Linux amd64 and arm64.
The external tag keeps its v (v0.1.0), while container images use 0.1.0. Stable releases also update latest; prerelease tags containing a hyphen never do. Images are published to:
git.zaynet.fr/dogama/dogama:<version>
git.zaynet.fr/dogama/dogama-agent:<version>
The workflow uses the protected Gitea Actions secret REGISTRY_TOKEN for registry login and Gitea Release creation. After all validations and both image pushes succeed, it creates DoGaMa <tag> against the exact tagged commit with notes derived from actual commit subjects. Tokens are never stored in the repository or printed.
The repository owner should protect the Gitea tag pattern v* so only authorized accounts can trigger production publication. Do not create a release tag until the candidate commit has passed the full disposable-host verification below.
Release verification
Run the complete validation gate in AGENTS.md, then verify the release artifacts and both image targets:
make release VERSION=v0.1.0
(cd dist/dogama-v0.1.0 && sha256sum -c SHA256SUMS)
make images VERSION=v0.1.0
On an isolated Docker host, confirm automatic secret initialization and reuse, application bootstrap, Palworld draft/install, lifecycle operations, backup/restore, failed-update rollback, and denial against unrelated containers. Confirm that only the web port is published, the main application lacks the Docker socket, the agent cannot access the master key, and player/backup data survive container recreation and interruption.