> For the complete documentation index, see [llms.txt](https://docs.hivel.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.hivel.ai/self-managed-hivel-deployment/virtual-private-cloud/azure/hivel-on-premises-deployment-guide-azure/upgrade-and-rollback.md).

# 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.

<br>

{% columns %}
{% column %} <a href="/self-managed-hivel-deployment/virtual-private-cloud/azure/hivel-on-premises-deployment-guide-azure/backup-and-restore.md" class="button primary" data-icon="backward">Backup and Restore</a>
{% endcolumn %}

{% column %}

{% endcolumn %}

{% column %} <a href="/self-managed-hivel-deployment/virtual-private-cloud/azure/hivel-on-premises-deployment-guide-azure/uninstall-and-cleanup.md" class="button primary" data-icon="forward">Uninstall and Cleanup</a>
{% endcolumn %}
{% endcolumns %}