Deployment#

Prepare release artifacts before the maintenance window. Stop both the API and worker and verify a recoverable database backup before applying migrations. Migration 0033 (Silicon Accounts) re-keys every row to accounts; older backends cannot write the migrated schema, so after it begins keep old processes stopped until the database is restored or the upgraded backend is running.

Run commit-migrate once with COMMIT_MIGRATOR_DATABASE_URL and COMMIT_SCHEMA_OWNER set to the schema owner. Run the API and worker with separate runtime roles. Grant them the application privileges after every schema migration:

psql "$ADMIN_DATABASE_URL" -v ON_ERROR_STOP=1 \
  -v database_name=silicon_commit -v schema_owner=commit_migrator \
  -v api_role=commit_api -v worker_role=commit_worker \
  -f deploy/postgres_runtime_grants.sql

Use the reviewed role template; do not grant blanket table deletion or routine execution. tests/postgres_runtime_grants.sql checks the result.

The API needs COMMIT_APP_SECRET, COMMIT_ACCOUNTS_WEBHOOK_SECRET and, for apps that act for accounts, COMMIT_PROOF_ISSUERS (Silicon Accounts integration). Health and readiness endpoints are /healthz and /readyz; the product API is mounted at /api/v1/, and Silicon Accounts events arrive at /webhook/.

The first deployment of the Silicon Accounts build follows the cutover runbook: after the migration, link the existing data with commit-migrate link-identities.

The current standalone AWS deployment and release procedure are documented in deploy/aws/README.md.