Updates & recovery

Signed updates

Back up state and the existing encryption key before updating. The CLI verifies Ed25519 manifest signatures and SHA-256, then runs the installer while retaining the selected Portal Node major. Project auto-deploy does not update Portal itself.

sudo dashboard-portal update --check
sudo dashboard-portal update
sudo dashboard-portal update --check

sudo systemctl is-active dashboard-portal hostmgr-deploy-helper nginx
sudo nginx -t
curl -fsS http://127.0.0.1:3100/api/health
curl -fsS https://portal.example.com/api/health
curl -fsSI https://portal.example.com/

Moving from 0.6.x

Existing owners migrate to Master accounts and organization names become stable IDs. Membership changes invalidate sessions. Back up before this access-model migration. Downgrading to a version before multi-account support is not an access-control rollback. The Node 20 adapter does not require a database conversion.

If verification fails

Stop on a signature/checksum error and verify release provenance and installed public key. Some pre-0.7.0 hosts use an older key; follow the verified fingerprint procedure in the upstream production guide rather than disabling verification. Installer snapshots cover managed files and small state, not full project data, volumes or external databases.

Upgrading to 1.0.0

Use the dedicated upgrade checklist for a 0.8.x installation. Keep the original encryption key with a consistent state backup, wait for existing host jobs to finish, and use the signed updater. In v1.0.0, participating installer, CLI, helper and host operations use maintenance leases; a busy update is refused before services stop. This does not automatically drain work started by older installed versions.

Open the 1.0.0 upgrade checklist