v2.1.0 — credential sources (env var / Docker secret)

Highlights

🔐 Declare where a credential lives — env var or Docker secret

A client container can now source a credential indirectly instead of inlining it:

gobackup.databases.main.password_env:  "DB_PASSWORD"          # from the client container's env
gobackup.databases.main.password_file: "/run/secrets/db_pw"   # from a Docker secret file

Applies to the secret keys password, token, secret, access_key, secret_key under databases/storages/notifiers. The rendered gobackup.yml only ever contains a ${GB_…} placeholder — plaintext is never written to the config.

• _env → the value is read from the client's env and set in the engine's env.
• _file → the secret's host file is re-mounted into the engine and read via a command wrapper at start. The secret value never appears in gobackup.yml or docker inspect, and the supervisor never reads it.

Notes & limits

• _file supports Compose file: secrets. Swarm docker secret / Compose environment: secrets have no re-mountable host source and are skipped with a log (use _env).
• The _file value lives in the daemon's process env — trigger those backups via the schedule or POST /api/perform, not docker exec … perform.
• credentials_file (gobackup's GCS keyfile key) is deliberately not treated as a credential ref.
• Conflicting inline+_env/_file, or an unresolved value, skips the model (fail-closed).

Verified end-to-end (spike/e2e-creds/): postgres authenticates using a file secret and 0 occurrences of the value appear in docker inspect. Multi-arch image ghcr.io/ekho/gobackup-docker tags 2.1.0, 2.1, 2, latest.