VPS deployment, upgrades and rollback

Use the existing VPS and preserve its applications, Caddy routing, private Alloy configuration and credentials. Recheck CPU/RAM, free disk and loopback ports 3001/8429. Use a dedicated Compose project under /srv/raspberry-telemetry.

deploy/prepare-storage.sh creates a fully allocated 8 GiB ext4 loop image, an fstab entry and mount. This is the public database’s hard size boundary. Confirm findmnt /srv/raspberry-telemetry/data before every start. Never start with an ordinary unmounted directory masquerading as bounded storage.

Copy explicit releases under the releases directory, retaining the predecessor. Provide a protected environment file with release, source commit and dedicated ingestion token. Validate without printing secrets:

docker compose --env-file /etc/raspberry-telemetry/vps.env -f deploy/compose.yaml config --quiet
docker compose --env-file /etc/raspberry-telemetry/vps.env -f deploy/compose.yaml build
docker compose --env-file /etc/raspberry-telemetry/vps.env -f deploy/compose.yaml up -d --wait

Compose pins images, health checks, restart behavior, memory/CPU limits and bounded logs. The database has no host port. The gateway and portal have distinct loopback ports. Check health, unauthorized ingestion rejection and safe real series before adding the public hostname.

For an upgrade, run CI and validate the new image before changing the release environment. On failure, restore the previous release environment and Compose checkout, then run up -d --wait. Retain the database. Stop/start only this project, not the shared Docker service. Record existing application health before and after deployment.

See the portal repository’s deploy/OPERATIONS.md for backup and storage details, and DNS and HTTPS for publication.