Upgrade and Rollback
Checking for a New Version
Hivel does not currently publish a public changelog or a self-serve registry you can browse for new image tags. Check with your Hivel contact, or email support@hivel.ai, to learn when a new image tag is available for your deployment and what it contains.
Pre-Upgrade Checks
Goal: make sure you can get back to a known-good state before you touch a running deployment.
1. Take a backup point you can restore to if the upgrade goes wrong - see Backup and Restore above. On Azure Database for PostgreSQL, confirm a PITR-covered restore point exists that predates the upgrade (Azure's continuous automated backups normally make this a formality, not an extra step you have to trigger).
2. Confirm with Hivel whether the release you're upgrading to ships a new Flyway migration - this determines whether you'll need to re-run Run Flyway Migration as part of the upgrade.
Upgrade Steps
1. Stop services: ./deploy.sh --stop (on VM).
2. Pull the new image tags per Hivel's instructions: ./deploy.sh --update.
3. If Hivel confirmed the release includes a new database migration:
a. Switch config/.env back to the Phase 1 (admin) credentials - see Environment Configuration. Migration needs elevated privileges and will fail against the application-user credentials left in .env from your last install or upgrade (see Migration Failed in Troubleshooting).
b. Re-run the migration - see Run Flyway Migration: ./deploy.sh --service flyway-migration.
c. Once the migration completes successfully, switch config/.env back to application-user (Phase 2) credentials before continuing.
Skip this entire step if there's no new migration.
4. Redeploy service: VM (./deploy.sh --vm).
5. Re-run the Validation Checklist in Verification and Access end to end to confirm the upgraded deployment is healthy.
./deploy.sh --update(see Available deploy.sh Commands) covers pulling new images, but a specific release may require additional steps beyond that. Confirm with Hivel support at the time of the upgrade whether anything else applies to your release.
Rollback Procedure
If the upgrade fails validation:
1. Revert to the previous image tag and redeploy using the same ./deploy.sh steps above.
2. If the release included a database migration, reverting the image alone is not enough - Flyway migrations aren't easily reversible. You will likely need to restore the pre-upgrade database state via Backup and Restore using the backup point you took before starting the upgrade.
3. Contact Hivel support before attempting to roll back a release that included a migration - they can confirm whether a clean rollback is possible or whether a database restore is required.
Next step: Uninstall and Cleanup.
Last updated