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

# Upgrading Your Self-Hosted InfraAudit Installation

> How to update InfraAudit to a new release: pull images, run migrations, verify the rollout, and pin versions for controlled production upgrades.

InfraAudit uses semantic versioning. Minor and patch releases are backward compatible. Major releases may include breaking changes — these are documented in the [Changelog](/resources/changelog) and on the [GitHub releases page](https://github.com/pratik-mahalle/infraudit-go/releases).

## Before you upgrade

<Steps>
  <Step title="Read the changelog">
    Check the [Changelog](/resources/changelog) or the [GitHub releases page](https://github.com/pratik-mahalle/infraudit-go/releases) for the target version. Look for migration notes, new required environment variables, or breaking changes.
  </Step>

  <Step title="Back up your database">
    Take a database backup before upgrading. If a migration fails and you need to roll back, you'll need a clean restore point.

    For Docker Compose:

    ```bash theme={null}
    docker compose exec postgres pg_dump -U infraudit infraudit > backup-$(date +%Y%m%d).sql
    ```
  </Step>

  <Step title="Note your current version">
    ```bash theme={null}
    docker compose exec api ./infraudit-api --version
    # InfraAudit v1.2.3
    ```
  </Step>
</Steps>

## Docker Compose upgrade

Pull the latest images and restart the stack:

```bash theme={null}
# Pull the latest images
docker compose pull

# Restart containers
docker compose up -d
```

The API runs any pending database migrations automatically on startup. Watch the logs to confirm:

```bash theme={null}
docker compose logs -f api
```

You should see output like:

```
api_1  | Running database migrations...
api_1  | Migration 0012_add_anomaly_table.up.sql applied
api_1  | All migrations applied successfully
api_1  | InfraAudit API starting on :8080
```

If migrations fail, the API exits with a non-zero code. Check the container logs for the SQL error and open a [GitHub issue](https://github.com/pratik-mahalle/infraudit-go/issues) with the error message if you need help.

## Kubernetes upgrade

Update the image tag in your API deployment manifest:

```yaml theme={null}
# api-deployment.yaml
spec:
  containers:
    - name: api
      image: ghcr.io/pratik-mahalle/infraudit-go:v1.3.0  # update to the new version
```

Apply the updated manifest and wait for the rollout:

```bash theme={null}
kubectl apply -f deployments/kubernetes/api-deployment.yaml
kubectl rollout status deployment/infraudit-api -n infraudit
```

Kubernetes performs a rolling update by default — old pods continue serving traffic until the new pods pass their readiness checks. If a migration fails, the new pod will fail its readiness check and Kubernetes will not route traffic to it. Your existing pods remain available.

<Tip>
  Pin to specific image tags (e.g. `v1.3.0`) rather than using `latest`. This gives you explicit control over when upgrades happen and prevents unexpected changes from automatic pulls.
</Tip>

## Pinning to a specific version

For production deployments, always specify an exact version tag:

<Tabs>
  <Tab title="Docker Compose">
    Edit your `docker-compose.yml` to specify the image version:

    ```yaml theme={null}
    services:
      api:
        image: ghcr.io/pratik-mahalle/infraudit-go:v1.3.0
    ```
  </Tab>

  <Tab title="Kubernetes">
    Set the image tag in your deployment manifest:

    ```yaml theme={null}
    spec:
      containers:
        - name: api
          image: ghcr.io/pratik-mahalle/infraudit-go:v1.3.0
    ```
  </Tab>
</Tabs>

## Downgrading

Downgrading is only supported within the same minor version — for example, `v1.3.2` to `v1.3.0`. Downgrading across minor versions requires running `down` migrations, which may be destructive.

To downgrade within the same minor version:

1. Roll back the image to the previous version tag.
2. Run down migrations for any files applied during the upgrade, one at a time:

```bash theme={null}
docker compose exec api go run ./cmd/migrate down 1
```

<Warning>
  Always restore from a database backup when downgrading across minor versions. Running `down` migrations in production carries risk of data loss.
</Warning>

## Upgrade schedule

There is no forced upgrade schedule. InfraAudit does not phone home or require license renewals. Upgrade at your own pace, but staying within one major version of the latest release is recommended to ensure you have current security patches.