Encryption and secrets
What is encrypted, and the one key you must not lose.
Connector credentials
Every credential a connector uses — tokens, passwords, service account keys —
is encrypted before it is stored, using AES-256-GCM with your
ENCRYPTION_KEY.
The interface only ever shows them masked. There is no view that reveals a stored credential in full, including for administrators.
ENCRYPTION_KEY
Exactly 32 bytes, base64:
openssl rand -base64 32The API refuses to start if it is missing or malformed. That is intentional: the earlier behaviour was to continue and store credentials in plain text, which fails silently and is worse than not starting.
Back it up separately, and never change it.
Lose it and every stored credential becomes unreadable — a restored backup will need every connector re-authenticated by hand. Change it and the same thing happens.
Passwords
Hashed with bcrypt. Never stored recoverably, and never logged.
Sessions and keys
Browser sessions use signed tokens in HTTP-only cookies. Set
COOKIE_SECURE=true in any deployment served over HTTPS.
API keys are stored hashed. The full value exists only at the moment of creation, which is why it is shown once.
In transit
LensHub does not terminate TLS itself. Put it behind a reverse proxy that does — agents send API keys on every request, and those must not cross a network unencrypted. See Putting it on a network.
At rest, beyond credentials
Content itself is stored unencrypted in PostgreSQL, so that it can be searched. Use encrypted volumes or an encrypted managed database if your requirements call for it — that is the standard answer, and it composes cleanly.