---
title: "Upgrading"
description: "How to safely upgrade your self-hosted Ansvisor instance."
---

## Standard upgrade

```bash
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:

```bash
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](https://github.com/aeohub/ansvisor/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:

```bash
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.

<Tip>
**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.
</Tip>

## Watching the changelog

Subscribe to release notifications on the GitHub repo: [aeohub/ansvisor → Watch → Releases only](https://github.com/aeohub/ansvisor). You'll get an email for each new release with the full changelog.
