Ansvisor Docs

Standard upgrade

cd ansvisor
git pull
docker compose up -d --build

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:

cd ansvisor
git pull
cd supabase
supabase db push       # apply new migrations
cd ..
docker compose up -d --build

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:

cd ansvisor
git checkout v0.1.0    # previous tag
docker compose up -d --build

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.

Self-host

Upgrading

Standard upgrade

When migrations are involved

Major version upgrades

Rollback

Watching the changelog

​Standard upgrade

​When migrations are involved

​Major version upgrades

​Rollback

​Watching the changelog

Standard upgrade

When migrations are involved

Major version upgrades

Rollback

Watching the changelog