Run it

Updating and backups

Keep the board current and its database safe.

Updating the board

Put the new version from the image's Tags page in .env and start it:

cd pidash
sed -i 's/^PIDASH_VERSION=.*/PIDASH_VERSION=1.3.0/' .env
docker compose up -d

Compose pulls the new image and restarts the board; the database and your files stay. When an update changes the config format, the board says so at start-up (below).

Now and then a release changes the Compose project too. Compare yours with the current one, and take over what changed (keep your own user: lines):

curl -fsS https://pidash.io/install/compose.yaml | diff compose.yaml -
curl -fsS https://pidash.io/install/db-backup | diff db-backup.sh -

To go back, put the previous version in .env and run docker compose up -d again.

Converting an older config.yaml

A config.yaml from before connections (with environments:, prometheus_url:, awx:, push: and the like) is refused at start-up. Convert it with the new image:

cp config.yaml ~/config.yaml.v1          # keep the old one, outside the project folder
docker compose run --rm --no-deps -T alertboard migrate-config /config.yaml > config.yaml.v2
# read the "dropped:" lines it printed, check config.yaml.v2, then:
mv config.yaml.v2 config.yaml && chmod 600 config.yaml
docker compose up -d

migrate-config never lets more people act than before: where the old file named different groups for approvals, runbooks and Kubernetes actions, it stops and names them, as the new format has one operators group for all three. Make them the same in the old file and run it again.

A newer file that still has a calendar:, metrics:, ssh: or networks: block starts, with a warning per block. Run migrate-config on it the same way, or delete the blocks: the calendar now reads the connections, the metrics tiles are built in, and the terminal's hosts and networks come from Proxmox.

To go back to an earlier version after converting, restore the old config.yaml from your copy, put the old version in .env and start it.

Backups

The db-backup service writes data/backup/alertboard-YYYY-MM-DD.sql.gz every night at 03:30 and keeps 14. Old ones are pruned only after a successful dump. A failed dump is retried once; if that fails too, docker compose ps shows db-backup unhealthy until a dump succeeds.

Restore

docker compose stop alertboard
gunzip -c data/backup/alertboard-2026-10-14.sql.gz | \
  docker compose exec -T mariadb sh -c 'MYSQL_PWD="$(cat /run/secrets/db_password)" mariadb -u alertboard alertboard'
docker compose start alertboard