Secret Rotation

It is better to plan secret rotation as a normal operational procedure, not as something you do “on the fly.” In SPG99, it is important to separate two classes of secrets.

1. API key

The API key is used for Console, CLI, and the Control Plane API.

A typical safe scenario looks like this:

1. issue a new key;
2. update CI/CD, automation, and local environments;
3. verify access with the new key;
4. revoke the old one.

In the normal managed scenario, this can be done on schedule without affecting application PostgreSQL connections.

2. Tenant credentials (pg_user / pg_password)

These credentials are used for PostgreSQL connections through Gateway. Because they affect all applications using the tenant, their rotation requires more careful planning:

• define the maintenance window in advance;
• update all DSNs and secret stores;
• restart or recreate connection pools;
• verify that old connections are no longer in use.

What is especially important

• do not mix API key rotation and PostgreSQL credential rotation into one opaque step;
• after an incident, issue a new API key first if there is any risk that the token leaked;
• rotate tenant credentials only through an agreed procedure, clearly understanding the impact on applications.

Practical conclusion

An API key is rotated as a secret for platform management access. Tenant credentials are rotated as production connection secrets and require more attention to the cutover window and to updating all applications.