Migration Guide
Database Migrations
Alga manages its schema with hand-written goose SQL migrations in apps/backend/db/migrations/, paired with the Bun models in apps/backend/db/models/. Migrations are embedded into the binary at build time.
Auto-Migration
Enable auto-migration on startup:
POSTGRES_AUTO_MIGRATE=trueThis is enabled by default in Docker Compose via POSTGRES_AUTO_MIGRATE=true in the environment block. The config default is false. Schema changes are applied on every startup when enabled.
Manual Migration
# From apps/backend
go run . db migrate
# Or using the built binary
./alga db migrateMigration Process
Migrations are versioned SQL files applied by goose:
- goose tracks applied versions in its
goose_db_versiontable - On
up, pending migrations run in version order, each within a transaction - Only the
-- +goose Upblocks run on startup; the paired-- +goose Downblocks exist for manual rollback - Schema changes are explicit — there is no auto-diffing; author a new migration file and the matching Bun model change together
For destructive changes, author them explicitly in a migration.
Version Upgrades
Upgrade Checklist
Review release notes for breaking changes
Backup the database before upgrading
Pull the latest code:
shgit pullInstall dependencies:
shpnpm install --no-frozen-lockfile cd apps/backend && go mod tidyReview configuration changes — new env vars may be required
Pull new images and restart:
shdocker compose pull docker compose up -dVerify:
shcurl http://localhost:8080/health curl http://localhost:8080/api/v1/readiness
Zero-Downtime Deployments
For zero-downtime upgrades with multiple replicas:
Deploy new version to one replica
Wait for health check to pass
Drain and update remaining replicas one at a time
Use rolling updates in Kubernetes:
yamlstrategy: type: RollingUpdate rollingUpdate: maxUnavailable: 1 maxSurge: 1
Rollback
If issues occur after upgrade:
Database rollback — restore from pre-upgrade backup:
shcat backup_pre_upgrade.sql | docker compose exec -T postgres psql -U alga algaCode rollback:
sh# Pin ALGA_VERSION=v1.2.3 in .env, then: docker compose pull docker compose up -dConfiguration rollback — restore previous
.envvalues
Breaking Changes
When Breaking Changes Occur
Alga follows semantic versioning:
- Patch (1.2.x): Bug fixes, no breaking changes
- Minor (1.x.0): New features, backward-compatible
- Major (x.0.0): Breaking changes, migration required
Handling Breaking Changes
- Release notes document all breaking changes
- Migration scripts are provided for data changes
- Deprecated features are warned for at least one minor version before removal
- Configuration changes are documented with before/after examples
Configuration Migration
Environment Variable Changes
When env variables change:
- New variables are added with sensible defaults
- Deprecated variables are logged with migration instructions
- Use the System Configuration API for runtime changes where possible
Encryption Key Rotation
To rotate encryption keys:
Generate a new key:
shNEW_KEY=$(openssl rand -base64 32)Add to
ENCRYPTION_KEYSwith a higherkid:shENCRYPTION_KEYS="1:old_key_base64,2:$NEW_KEY"The highest
kidbecomes the active encryption key. Older keys decrypt existing ciphertexts.After all secrets are re-encrypted (on next save), remove the old key:
shENCRYPTION_KEYS="2:$NEW_KEY"
From Other Platforms
From OpsGenie
- Export users, teams, and escalation policies via OpsGenie API
- Import users:
POST /api/v1/usersfor each user - Create teams:
POST /api/v1/teams - Recreate escalation policies:
POST /api/v1/escalation-policies - Update monitoring tools to send webhooks to Alga
- Disable OpsGenie integrations
From PagerDuty
- Export services and schedules via PagerDuty API
- Create services in Alga service catalog
- Import on-call schedules
- Recreate escalation policies
- Update alert routing to point to Alga webhooks
- Gradually migrate services one at a time
See Also
- Deployment — deployment options
- Backup & Restore — backup procedures
- Architecture — system design