Upgrade Cerynix safely
The updater automates download, rebuild and validation. Production change control, backup verification and schema-aware recovery remain operator responsibilities.
Prepare
- Announce a maintenance window and stop user changes.
- Record the current version and confirm adequate disk space.
- Run
scripts/backup.sh, copy the encrypted result off-box and complete a restore drill with the off-box age identity. - Keep the installer-created application snapshot and database backup until acceptance is complete.
Run and validate
cd ~/cerynix-onprem
./install.sh --updateBefore it changes anything, the updater takes an encrypted, fail-closed pre-upgrade database backup (cerynix-db-backup-<ts>.sql.gz.age): it stops with nothing changed unless age is installed, BACKUP_AGE_RECIPIENT is a valid public age recipient and PostgreSQL is reachable. The dump is a single pg_dump | gzip | age stream, so no plaintext ever reaches disk. Require both Update complete and SELF-TEST: PASS. Then verify login, health, a read/write workflow, evidence access, reports and external integrations.
--allow-update-without-db-backup. That skips only the database backup — it never disables signature verification, the application snapshot or the self-test — and leaves no database recovery path, so use it only when an independently verified external backup already exists.If validation fails
If no migration ran, the application snapshot may be sufficient. If a migration ran—or you are unsure—do not assume old code is compatible with the new schema. Preserve logs and current data, keep the service in maintenance, and follow the disaster-recovery runbook using the pre-upgrade backup.
Close the change
Monitor logs and health, record the deployed version and evidence of validation, then retain recovery artifacts according to policy. Remove them only after the rollback window has closed.