Backups and upgrades

Backups

The panel downloads and restores backups in System. Through the API:

• The whole runner: GET /api/system/backup, a .tar.gz of every service's data, the database, the code and master.key. A restore (POST /api/system/restore) replaces all data and restarts the runner in place.
• A service's data: GET /api/services/<name>/export and POST /api/services/<name>/import.
• A version: GET /api/services/<name>/deployments/<id>/bundle, the body that deploys it again, here or on another runner.

On a schedule

Call the API with the root token, from cron for example, on the machine that runs the compose:

docker compose exec -T panel wget -qO- \
  --header "Authorization: Bearer $ZEROKO_TOKEN" \
  http://runner:8081/api/system/backup > runner-$(date +%F).tar.gz

Databases are copied with VACUUM INTO, so a backup is consistent while services run. A restore cut short goes on where it stopped on the next start.

Upgrades

Pull the new images and recreate the containers:

docker compose pull
docker compose up -d

With the all-in-one image, the same with its file (docker compose -f docker-compose-aio.yml): its newer tag brings both a newer panel and a newer runner.

The runner migrates its database on start and refuses a database from a newer version. Services run with a fixed workerd compatibility date, so a newer workerd does not change their behavior.