Upgrading
Use this checklist for each release that includes schema, auth, or deployment changes.
Pre-Release
Section titled “Pre-Release”1. Confirm migration state
Section titled “1. Confirm migration state”cd crates/edgeplane-towersqlx migrate infoAll migrations should show as applied on your current version.
2. Validate migrations locally
Section titled “2. Validate migrations locally”sqlx migrate run# Start server and verifycurl http://localhost:8008/health3. Run tests
Section titled “3. Run tests”cargo test -p edgeplane-towercargo test -p edgeplane-tui4. Validate Docker profiles
Section titled “4. Validate Docker profiles”bash scripts/smoke.sh --profile quickstartbash scripts/smoke.sh --profile full5. Confirm auth config
Section titled “5. Confirm auth config”- OIDC settings are present and valid for the target environment
- Admin identities set (
EP_ADMIN_SUBJECTSand/orEP_ADMIN_EMAILS) - Service account tokens (
mcs_sa_*) created for any CI pipelines or MCP clients that need programmatic access
Release Execution
Section titled “Release Execution”- Take a DB snapshot in the target environment before proceeding
- Deploy the new image (or binary, depending on your deployment path)
- Run schema migrations:
edgeplane-towerruns migrations automatically on startup- To run manually:
cd crates/edgeplane-tower && sqlx migrate run
- Verify API health:
Terminal window curl https://<edgeplane-host>/healthcurl https://<edgeplane-host>/schema-pack
Post-Release Validation
Section titled “Post-Release Validation”Authorization checks
Section titled “Authorization checks”- Owner/contributor update paths work as expected
- Owner/admin delete paths work as expected
- Non-admin subjects cannot call admin-only endpoints
Data checks
Section titled “Data checks”# Verify post-upgrade connectivity and entity stateedgeplane status# create + update a test mission via edgeplane or MCP toolsPublish checks (if publication is enabled)
Section titled “Publish checks (if publication is enabled)”- Create a pending ledger event
- Approve it
- Verify Git commit is created and provenance written back to Postgres
Rollback
Section titled “Rollback”If the release must be rolled back:
- Roll back the application image (or binary)
- If the migration is not backward-safe: restore the DB snapshot taken in step 1 of Release Execution
- Document migration constraints in release notes before the next attempt
Migration safety assessment
Section titled “Migration safety assessment”A migration is backward-safe if:
- It only adds columns (with defaults or nullable)
- It adds tables
- It adds indexes
A migration is not backward-safe if:
- It drops or renames columns
- It changes column types
- It drops tables
- It changes constraint behavior
When in doubt, treat the migration as not backward-safe and keep the DB snapshot.
Schema Drift Detection
Section titled “Schema Drift Detection”After any schema change, run:
# From the edgeplane-tower cratecargo sqlx prepareIf this produces changes, commit them. Uncommitted schema drift causes CI failures on the SQLx offline check.
See Also
Section titled “See Also”- Deployment — server setup and systemd/Compose configuration
- OIDC Authentication — auth configuration