Binions keeps its secrets as plain files on disk, protected by Unix permissions — never inline in configuration. Every credential a daemon needs — a database password, an API key, a TLS private key — lives in a file that only that daemon’s service user can read. There is no external secret manager to run; the security comes from file ownership and mode bits on the host you already control.
Files, not config. Configuration files reference secrets by path; they never contain the secret value itself. That keeps credentials out of your version control, out of logs, and out of any config you might share when asking for support.
Binions splits secret material across two locations, each owned by the right account:
0600 (read/write for the owner only) and owned by the daemon’s dedicated service user, so no other daemon and no ordinary login can read it.| Location | What it holds | Owner / mode |
|---|---|---|
/opt/binions/<service>/secrets/*.password | That daemon’s credentials (DB passwords, API keys) | <service>svc, mode 0600 |
/etc/binions/master.toml | Master configuration shared across daemons | root-managed |
/etc/binions/*.license | Per-binion licence files | root-managed |
/etc/binions/secrets/ | TLS certificates and private keys for the edge | Traefik service user |
Because every daemon runs as its own isolated user, this layout enforces least privilege automatically: a daemon can only ever read the secrets that belong to it.
Rotation is deliberately simple. There is no API to call and no vault to unseal — you replace the file on disk and restart the daemon so it re-reads the new value on startup. Keep the same ownership and mode when you write the replacement:
# Replace the secret file for one daemon, then restart it.
# <name> is the daemon's short name; <service> is its service-user prefix.
sudo install -o <service>svc -g <service>svc -m 0600 \
new-secret.password /opt/binions/<service>/secrets/db.password
sudo systemctl restart binions-<name>
# Confirm the daemon came back up and its dependencies are reachable.
sudo systemctl status binions-<name>
binions-cliconsole statusNo external secret-manager integration. Binions does not currently integrate with HashiCorp Vault, cloud KMS, or any external secret store. Secrets are local files guarded by Unix permissions. If you need centralised secret management, manage the files with your own configuration-management tooling.
The daily backup deliberately captures your configuration and secrets together — the master config, licence files, and credential files — as a single archive, so a restore brings a host back exactly as it was. That convenience comes with a responsibility:
Protect your backup storage. A backup archive contains live secrets in clear form. Treat the bucket or directory that holds your backups with the same care as the host itself — restrict access, and encrypt the storage at rest where you can.
For how the backup is taken and restored, see Backup & restore. For how configuration files point at these secret files without embedding the values, see Configuration → Secrets.