Upgrading

QAID upgrades are handled through standard Docker Compose commands. Database migrations run automatically on startup. The whole process typically takes 2–3 minutes of downtime.

Before you upgrade

1. Read the release notes for the version you're upgrading to — breaking changes (if any) are called out at the top.
2. Back up your database (and screenshots if you care about historical visual baselines).
3. Pick a low-traffic window — there's a brief downtime while containers restart.

Backup

cd ~/qaid  # or wherever you installed QAID

# Database dump
docker compose exec postgres pg_dump -U qaid qaid > backup-$(date +%F).sql

# Runtime data (screenshots, snapshots)
tar czf data-backup-$(date +%F).tar.gz data/

Move both files off the QAID host (S3, object storage, separate disk) before proceeding.

Upgrade

cd ~/qaid

# Pull the new container images
docker compose pull

# Recreate the containers (database migrations run automatically on backend startup)
docker compose up -d

Container recreation is sequential — Postgres comes up first, then the backend (which runs any pending migrations), then the frontend, then Caddy.

Verify

# All services should report (healthy)
docker compose ps

# Backend should log a successful startup with no migration errors
docker compose logs --tail=50 qaid-server

Then open the web interface and sanity-check:

• Login works
• Projects list loads
• Existing test runs still display correctly

Rollback

If something goes wrong, the rollback is straightforward — but you'll restore the database to its pre-upgrade state, losing any data created during the upgraded session.

# Stop the containers
docker compose down

# Restore the database
docker compose up -d postgres
docker compose exec -T postgres psql -U qaid qaid < backup-YYYY-MM-DD.sql

# Pin to the previous version in docker-compose.yml
# (edit the `image:` tag to your previous version)

# Bring everything back up at the old version
docker compose up -d

Migrations are forward-only — there's no automatic schema downgrade. If a migration ran during the failed upgrade, the restored database from your backup is the source of truth.

AWS deployments

On AWS Terraform deployments, the upgrade flow is identical from the EC2 instance:

aws ssm start-session --target <instance-id>
cd /opt/qaid
docker compose pull && docker compose up -d

Infrastructure changes (EC2 instance type, RDS class, etc.) go through terraform apply instead.

Patch vs. major upgrades

Automatic updates

QAID doesn't ship an auto-updater. Updates are explicit — pull when you're ready. This is intentional: you control when downtime happens, and you've always read the release notes.

If you want scheduled updates, wire your own cron + script + monitoring around the standard docker compose pull && docker compose up -d flow.