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 and on the GitHub releases page.

Before you upgrade

1. Read the changelog

   Check the Changelog or the GitHub releases page for the target version. Look for migration notes, new required environment variables, or breaking changes.

2. 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:

   docker compose exec postgres pg_dump -U infraudit infraudit > backup-$(date +%Y%m%d).sql
   
3. Note your current version

   docker compose exec api ./infraudit-api --version
   # InfraAudit v1.2.3
   

Docker Compose upgrade

Pull the latest images and restart the stack:

# 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:

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 with the error message if you need help.

Kubernetes upgrade

Update the image tag in your API deployment manifest:

# 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:

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.

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.

Pinning to a specific version

For production deployments, always specify an exact version tag:

Docker Compose

Edit your docker-compose.yml to specify the image version:

services:
  api:
    image: ghcr.io/pratik-mahalle/infraudit-go:v1.3.0

Kubernetes

Set the image tag in your deployment manifest:

spec:
  containers:
    - name: api
      image: ghcr.io/pratik-mahalle/infraudit-go:v1.3.0

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:

docker compose exec api go run ./cmd/migrate down 1

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

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.