Secret values are never written into config.yaml.
The configuration file carries only environment variable names or file paths:
| Key | Purpose |
|---|---|
database.password_env | The name of the variable with the PostgreSQL password |
auth.bootstrap_admin.password_env | The name of the variable with the first administrator’s password |
server.proxy_auth.secret_env | The name of the variable with the reverse proxy secret |
security.secret_key_file | The path to the encryption key file |
If a *_env key is set but the variable itself is empty or missing,
the server does not start — the error message names the variable.
The encryption key file
security.secret_key_file is a mandatory parameter:
without the key file the server does not start.
The key encrypts the secrets stored in the database:
the external registry credentials of proxy repositories
and the service key that signs container image uploads.
User passwords and tokens are stored as hashes and are not encrypted with this key.
The file format:
active: 1
keys:
- id: 1
key: "<base64 value of 32 bytes>"The value is generated with openssl rand -base64 32.
The server does not check the file permissions —
restrict them with the means of your deployment system.
The key file is part of the instance data. If it is lost, the server will not start, and the stored external registry credentials are lost irrecoverably. Do not regenerate the file during deployment: if the deployment tool re-creates the secret on every update, all servers stop starting. Back the file up together with the database (see Backup).
Key rotation
Rotation is performed in three phases, restarting the servers after the first two:
- Add. Add the new key to
keyswith the nextid, leavingactiveunchanged. Roll the file out to all servers and restart them. - Promote. Switch
activeto theidof the new key, roll out, and restart. New records are encrypted with the new key; the image upload service key is re-encrypted automatically at startup. - Re-encrypt the credentials. Open “Edit” for every proxy repository with stored external registry credentials and enter the password or token again — that is the only way they are re-saved under the new key. This does not happen automatically.
While some records are still not re-encrypted, the server writes the
secrets: upstream credentials still sealed under a non-primary key warning
at startup, with the number of such records in the stragglers field.
Remove the old key from the file only after the warning is gone.
If the old key is removed without completing the third phase, repositories with stored credentials stop working: every request to them fails, and the secrets can only be restored by entering them anew.
All servers of an instance must use the same key file.