Files
ProgressionMods/deploy
HRiggs c79aad1cb9
Build and Publish Container / Publish Linux container (push) Successful in 4m11s
fix: disk image
2026-10-05 18:09:15 -04:00
..
2026-10-05 18:09:15 -04:00

Progression deployment

This deployment pulls the published container from the Gitea registry. No repository checkout or local image build is required on the server.

  1. Copy .env.example to .env and change PROGRESSION_ADMIN_TOKEN.
  2. Set PROGRESSION_EXTERNAL_PORT if port 8000 is already in use.
  3. Start the service:
docker compose pull
docker compose up -d

The SQLite database and Steam Workshop files are stored in named Docker volumes and survive image upgrades. To update later, run the same two commands again.

On a new deployment, the hourly refresh timer stays paused while the first full Workshop download runs. Its hard limit defaults to 12 hours and can be changed with INITIAL_DOWNLOAD_TIMEOUT_SECONDS. Follow the per-mod title, Workshop ID, result, and completion percentage in Dockhand or with docker compose logs -f. Failed batches also include SteamCMD's output tail so network, subscription, and filesystem errors are visible directly in the container log.

SteamCMD is forced to use /opt/steamcmd so Workshop content always lands in the mounted volume. On the first I/O Operation Failed result, transient .acf, download, and temp state is moved into .progression-recovery; completed mod directories are left untouched. Startup also checks that the volume has enough free space for the remaining Steam metadata estimate.

The image does not switch Unix users at startup because some rootless and capability-restricted container hosts block setuid. The process remains inside the container's user namespace and writes directly to its named volumes.