Files
HRiggs 516f1cfde2
Build and Publish Container / Publish Linux container (push) Successful in 4m3s
fix: steamcmd install dir
2026-10-05 18:25:51 -04:00

37 lines
1.7 KiB
Markdown

# 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:
```sh
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 installed in `/opt/steamcmd`, while its forced library root is the
separate `/srv/steam-library` path. The existing `progression-workshop` volume
is mounted below that library root, so upgrades keep all completed downloads.
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.