Skip to main content
Three secrets are worth rotating, and each one behaves differently. Take a backup first in every case.

​
Rotate AUTH_SECRET

AUTH_SECRET signs session cookies. Rotating it invalidates every signature, so every browser session is signed out at once.
1

Generate a new value

2

Replace it in the root .env

Or in apps/api/.env for a local development instance.
3

Recreate the API

4

Sign in again

Every user has to. There is no way to rotate the signing secret without that.
Personal API tokens are unaffected. They are stored as SHA-256 hashes rather than signed with AUTH_SECRET, so scripts and the MCP server keep working across a rotation. Revoke an individual token instead when that token is what leaked. See Personal API tokens.

​
Rotate the database password

The role password and the root .env must change together, so generate the value once and apply it to both before recreating the services.
Two details make this work. Recreating the PostgreSQL container does not change an existing role password, which is why the alter role statement is required. The new value reaches the database over standard input rather than as a command line argument, so it stays out of the process list.
Writing .env with > replaces the file. If your .env carries more than POSTGRES_PASSWORD, including AUTH_SECRET, edit it in place or rewrite every line you need. Losing AUTH_SECRET here signs everyone out.
If the API fails to start afterwards, the role and .env disagree. Re run the block.

​
Rotate an OpenAI key

The simplest of the three. Replace OPENAI_API_KEY in apps/api/.env, recreate the API, then revoke the old key at OpenAI.
Nothing is stored that depends on the old key. Cached AI audit results stay valid because they are stored output rather than credentials. See Enable the optional AI features.

Back up PostgreSQL

Take one before every rotation.

Hosting behind TLS and a reverse proxy

The rest of the pre exposure checklist.
Last modified on July 31, 2026