Skip to main content
DBDock’s security model rests on one habit: secrets live in the environment, not in files. This page covers where to keep them and how to handle them in production and CI.

​
The config / secret split

dbdock.config.json holds non-sensitive settings and is safe to commit. Secrets go in environment variables. See the full table in the Security overview.

​
Strict mode

Have DBDock refuse to run if any secret appears in the config file:
Use it in CI and production as a safety net against accidental secret leaks in dbdock.config.json.

​
Where secrets should live

Local development

A gitignored .env file, or your OS keychain. Never commit .env.

Production

A secret manager or cloud KMS — AWS Secrets Manager, Vault, GCP Secret Manager, etc.

CI/CD

Your CI provider’s encrypted secret store (GitHub Actions secrets, GitLab CI variables). Inject at runtime.

Cloud sign-in

For the CLI in CI, use DBDOCK_TOKEN from a secret store. See Authentication.

​
Least-privilege storage credentials

Give DBDock only the permissions it needs. For AWS S3 or R2, a scoped policy is enough to put, get, list, and delete backups:
On the bucket, also enable server-side encryption, block public access, and turn on versioning for ransomware protection.

​
The encryption secret

Your backup encryption secret deserves special care — it’s the one value that, if lost, makes encrypted backups unrecoverable.
Store the encryption secret separately from the backups themselves, and keep a redundant copy in a vault or password manager. See Encryption.

​
Rotating keys

Rotate on a schedule and after any suspected exposure. The Key rotation guide walks through rotating your encryption secret without losing access to old backups.

Encryption

The crypto behind backups.

Data handling

What sync uploads.