> ## Documentation Index
> Fetch the complete documentation index at: https://docs.sovseal.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Upgrade Your Self-Hosted sovseal Deployment

> Redeploy the edge function and apply new migrations. No Alembic, no container orchestration — it's two Supabase CLI commands.

<style>
  {`
      main, article, .prose {
        margin-left: 2.5cm !important;
        margin-right: 2.5cm !important;
      }
      `}
</style>

Because self-hosted sovseal is one Deno edge function plus a Postgres schema on your own Supabase project — not a multi-container stack — upgrading has no moving parts to coordinate. There is no Alembic, no `docker compose`, and no separate dashboard server to restart in sequence.

## Standard upgrade process

<Steps>
  <Step title="Back up first">
    Use Supabase's own backup tooling (point-in-time recovery, or a manual `pg_dump` against your project) before applying new migrations. See [Backups and Recovery](/self-hosted/backups-and-recovery) for the exact commands against a Supabase-hosted database.
  </Step>

  <Step title="Pull the latest source">
    ```bash theme={null}
    git pull origin main
    ```
  </Step>

  <Step title="Apply new migrations">
    Migrations are plain SQL files under `supabase/migrations/`, applied in order and safe to re-run:

    ```bash theme={null}
    supabase db push
    ```
  </Step>

  <Step title="Redeploy the function">
    ```bash theme={null}
    supabase functions deploy v2-agent-state --project-ref your-project-ref
    ```
  </Step>
</Steps>

That's the entire upgrade. Supabase handles the deploy atomically — there is no window where the old and new function versions serve requests simultaneously against an inconsistent schema, because the migration step runs first.

## Client SDK version compatibility

The edge function's request/response contract is additive — new optional fields, not breaking renames — so an older SDK continues to work against a freshly upgraded function. The reverse is not guaranteed: **upgrade the server before upgrading client SDKs.**

<Tip>
  If you're unsure which server version is live, the function's response headers or your own request logging is the source of truth — there is no `/version` endpoint today. Track your deployed migration timestamp (the filename prefix under `supabase/migrations/`) as your effective server version.
</Tip>

## Troubleshooting a failed migration

If `supabase db push` fails partway through:

```bash theme={null}
# See what actually applied
supabase migration list

# Repair the migration history if Supabase's tracking disagrees with reality
supabase migration repair --status applied <version>
```

<Warning>
  Do not hand-edit rows in `supabase_migrations.schema_migrations`. Use `supabase migration repair`, which is designed for exactly this recovery case, or restore from your pre-upgrade backup and re-apply migrations from a known-good state.
</Warning>

If the function itself fails to deploy, `supabase functions deploy` prints the Deno compile error directly — there is no separate log stream to correlate, since the deploy step and the runtime are the same artifact.