Genace
Sign inGet started

generation API key rotation: migrate consumers without test renders

Key rotation is an operational rollout across every process using a credential. Replacing one environment setting does not update already-running workers, scheduled jobs, or local MCP servers automatically. Inventory consumers first, verify the replacement through read-only requests, then retire the previous key according to the supported account management flow.

List consumers and their restart behavior

Include web servers, dispatchers, observers, CI workflows, containers, developer tools, and emergency scripts. For each consumer, record the secret location, deployment owner, reload mechanism, and a safe configuration version label. Store the label in telemetry, not the secret itself.

Separate routine rotation from a suspected exposure. If the old key may be compromised, prompt revocation can take priority over an overlap period. Do not preserve a known exposed credential merely to avoid restarting a worker. Use your incident policy and account’s supported key controls.

consumer: media-observer
secret_reference: production/generation-key
configuration_version: rotation-2026-10-24-b
reload_action: restart worker deployment
verification: authenticated models GET, then known-job GET

This is an example inventory entry in your operations system. It is not a Genace configuration resource or an API for issuing keys. Avoid storing raw values in this checklist, tickets, or screenshots.

Validate the replacement without creating work

Genace’s models route requires authentication and lists registered model metadata. A successful GET can verify that the new key reaches the gateway and is accepted. It does not prove upstream rendering availability, available credits, or the success of a future generation.

Then inspect a known job owned by the intended account. The job route checks the account identity associated with the key. A replacement from a different account may authenticate while failing ownership access. Do not create a new paid job merely to test whether the credential was loaded.

Roll out and verify each runtime

Update the secret source, restart or redeploy consumers that read environment values at startup, and verify their safe configuration version. Watch authentication failures and observation recovery. Existing accepted jobs should remain mapped by ID in your application database; rotation should not erase their operation records or cause dispatchers to submit replacements.

If a consumer still uses the old value, fix that process specifically. Do not print the full environment to identify it. A presence flag and configuration version are enough to begin diagnosis without placing credentials in logs.

Retire and reconcile

After the reviewed rollout, revoke the previous key through the supported management interface and verify no necessary consumer still depends on it. Remove obsolete secret references and update the inventory. Keep an audit record of the rotation event without retaining the retired secret value unnecessarily.

Test rollback as a configuration action, not a generation action. If the new credential fails, preserve known job IDs and temporarily pause dispatch rather than repeating uncertain POST requests. Refund and creation semantics are independent of key rotation.

Acceptance checks

Confirm all inventoried consumers report the intended configuration version, read-only authentication succeeds, known-job ownership is correct, and the retired key no longer authorizes requests. Verify no test render was created during the rollout and no secret entered logs or artifacts.

See environment variables, secret scanning, and non-generating health checks.

Continue with security

Where these facts come from