Secrets and keys

Four keys matter. Only one of them is unforgiving.

Key	Protects	If lost
`SECRETS_MASTER_KEY`	Connector credentials and backups	Unrecoverable. Reconfigure every connector
`JWT_SECRET`	Session and refresh tokens	Everybody is logged out. Generate a new one
`LICENSE_PUBLIC_KEY`	Verifying licences	Get it again from the vendor. It is public
The licence signing private key	Issuing licences	Vendor side only. See the control plane

`SECRETS_MASTER_KEY`

The one to be careful about.

Connector credentials are protected with envelope encryption using this key. They are encrypted before they reach the database and decrypted in memory only for the duration of a call. Backups are encrypted with it too.

What losing it looks like

You restore a backup. Everything is there. You sign in. Every connector reports a decryption error and nothing authenticates.

The data is intact and the vault cannot be opened. Every integration has to be reconfigured from scratch, assuming you still have the original credentials somewhere. Some of them, like a token shown once by a vendor, are simply gone.

That is the difference between a recoverable outage and permanent data loss, and it is the one thing only you can do something about.

Where the copy goes

A password manager. Not a file next to the backup. Not the same cloud account as the server. Not a note in the same wiki as the server documentation.

The test: if the server and everything it can reach disappeared tonight, would you still have the key? If the answer is no, the copy is in the wrong place.

Generating one

openssl rand -base64 32

Generate a fresh one per deployment. Never copy one from another install, from documentation, or from a demo.

Rotating it

Not a routine operation, because it means re-encrypting everything the vault holds. If you need to, treat it as a planned change with a backup taken first and verified afterwards by confirming a connector still tests successfully.

`JWT_SECRET`

Signs session and refresh tokens.

Rotating it logs everybody out, which is exactly what you want after a suspected compromise and exactly what you do not want at 8:40 on a Monday.

openssl rand -base64 48

Licence keys

Instances verify licence keys with the vendor’s public key. The private half never leaves the vendor control plane.

That means:

There is no call home at sign-in, and no network dependency for entitlement.
A network outage cannot disable your service desk.
The vendor cannot silently change what you are entitled to.

LICENSE_PUBLIC_KEY is the same value for every customer and is not a secret.

Key rotation is supported through a keyed map, and specific licences can be refused locally:

LICENSE_PUBLIC_KEYS='{"k_ab12cd34":"LS0tLS1CRUdJTiBQVUJM..."}'
LICENSE_REVOKED_JTIS="..."

Connector credentials

Stored encrypted, never displayed again after saving, and never written to the audit log. Configuring a connector is logged; the token you pasted is not.

Leaving a secret field blank when re-saving keeps the existing value, so you can change a base URL without re-entering a token you no longer have a copy of.

Connector agent tokens

A connector agent enrolment token is a credential into your network. It is shown once, only its hash is stored, and revoking it takes effect on the next poll.

API keys

API keys are shown once and stored as hashes. A lost key is reissued rather than recovered.

The environment file

.env holds all of the above on a self-hosted install. Treat the file accordingly:

chmod 600 .env

On the portable bundle, .env lives inside the install directory, which is why copying that folder is both a complete backup and a complete compromise.

What we hold on managed hosting

Per-deployment secrets, escrowed. That is what lets us restore your deployment and is why a key handover is part of moving to self-hosting.

Not your connector credentials in the clear. Those are encrypted with your deployment’s key, the same as anywhere else.

Backups and restore, where this matters most.
The security model.
Compliance answers.