Standard upgrade
That’s it for most releases. Behind the scenes:
- Docker rebuilds the changed image(s)
restart: unless-stopped ensures containers come back up automatically- Migrations under
supabase/migrations/ are forward-only — re-running supabase db push is idempotent
When migrations are involved
If the release introduces new SQL migrations:
Always run migrations before restarting containers — new code may expect new tables/columns.
Major version upgrades
When jumping a major version (e.g. v1 → v2), check the release notes on GitHub Releases for breaking changes. Common scenarios:
- Renamed env variables — update
web/.env and server/.env
- Migration that requires manual data backfill — release notes will spell it out
- Removed deprecated endpoints — your custom integrations might need updates
Rollback
If an upgrade breaks something:
Database migrations are not automatically reversed. If a new migration introduced a breaking schema change, you may need to manually restore from a Supabase backup taken before the upgrade.
Always take a Supabase backup before upgrading in production. From the Supabase dashboard: Database → Backups → New backup. Free tier includes daily backups; Pro tier offers point-in-time recovery.
Watching the changelog
Subscribe to release notifications on the GitHub repo: ansvisor/ansvisor → Watch → Releases only. You’ll get an email for each new release with the full changelog.
