Skip to main content

​
Back up

Back up before every gateway or schema upgrade:
  • Postgres database using your standard physical or logical backup process;
  • gateway YAML configuration;
  • secret-manager references and recovery procedure, not plaintext secrets in the backup bundle;
  • deployed image digest and Alembic revision;
  • TLS/tunnel and monitoring configuration.
Redis stores transient rate windows, cooldowns, and router cache data. It is not the source of truth for keys, usage, or budgets.

​
Test restore

Restore Postgres into an isolated environment, start the same gateway image/config, verify /ready, list keys/budgets, and run a disposable application-key request. A backup is not accepted until restore is demonstrated.

​
Upgrade

  1. Read release notes and configuration/schema changes.
  2. Back up Postgres and record the current image/config/revision.
  3. Test the candidate image against a restored database.
  4. Run alembic upgrade head with the candidate image.
  5. Start the gateway and require private /ready success.
  6. Run discovery, non-streaming, streaming, usage, budget, revocation, and provider capability checks.
  7. Observe before removing the previous image and application rollback credentials.

​
Rollback

Restore the previous image and configuration when the current database schema is backward compatible. Do not automatically run alembic downgrade after new writes; database downgrade must be separately reviewed and tested. Downgrading to a release without OIDC support removes OIDC-only administrator records and their sessions because the older schema requires a password credential. Password-backed administrators are retained. Verify a password break-glass administrator and preserve the OIDC identity mapping before crossing that boundary. For application-only rollback, restore the previous provider base URL, key, and model configuration without changing the gateway database.