Binions keeps every credential in a locked-down, per-daemon vault on your own host. Each background service — we call them daemons — has its own private secrets/ directory that only that daemon and root can read. Some secrets are generated for you when you install a package; others, such as a mailbox login or an AI provider key, you place there yourself.
Nothing leaves your host. Secrets live on the machine where Binions runs. They are never sent to a vendor cloud, and the platform reads them locally over
localhost.
Every daemon stores its secrets in its own directory under /opt/binions/:
/opt/binions/<service>/secrets/For example, the mailbox daemon uses /opt/binions/mailbox-service/secrets/ and the AI daemon uses /opt/binions/aiinjector-service/secrets/. The directory holds two kinds of files:
*.password files — passwords and other secret strings, one secret per file.*.key files — private keys and API keys.The package sets tight permissions automatically. The directory is mode 0700 and is owned by that daemon's own system user (the user is named after the service, for example mailboxsvc or aiinjectorsvc).
| Location | /opt/binions/<service>/secrets/ |
| Directory mode | 0700 — owner access only |
| Owner | The daemon's service user (e.g. mailboxsvc) |
| Contents | *.password and *.key files |
Strictly isolated. Only the daemon's own user and
rootcan read these files. One daemon cannot read another daemon's secrets, so a problem in one service does not expose the credentials of the rest.
Where Binions can create a strong secret itself, it does. The clearest example is the per-daemon Redis password. When you install a daemon, the package writes a fresh 40-character random password into the daemon's secrets/ directory and into the matching Redis configuration, so the two always agree:
# Run for you at install time — you do not type this:
openssl rand -base64 30 # 40-character random Redis passwordYou do not create, copy, or manage this password by hand. It is written once, kept in the daemon's vault, and used internally so the daemon can talk to its private Redis instance.
Some daemons need to reach services that live outside Binions — a mailbox, an AI provider, a database. Those credentials are yours, so you supply them. Place each one in the relevant daemon's secrets/ directory and point the daemon's configuration at it (see Per-daemon configuration).
| Daemon | What you provide |
|---|---|
Mailbox (binions-mailbox) | IMAP and SMTP credentials for the mailbox it should read and send from. |
AI (binions-aiinjector) | An API key for your AI provider. |
Database (binions-database) | Connection credentials for your chosen backend (PostgreSQL, MySQL, MongoDB, or MSSQL); SQLite needs none. |
The pattern is always the same: write the secret to a file in the daemon's secrets/ directory, then make sure it is owned by that daemon's user and readable only by the owner. The example below writes an AI provider key for the AI daemon.
# Illustrative — adjust the service name, file name, and value to your daemon.
sudo install -d -m 0700 -o aiinjectorsvc -g aiinjectorsvc \
/opt/binions/aiinjector-service/secrets
printf '%s' 'YOUR-API-KEY-HERE' | \
sudo tee /opt/binions/aiinjector-service/secrets/provider.key > /dev/null
sudo chown aiinjectorsvc:aiinjectorsvc \
/opt/binions/aiinjector-service/secrets/provider.key
sudo chmod 0600 /opt/binions/aiinjector-service/secrets/provider.keyThe command above is illustrative. The exact file name a daemon expects, and whether it reads the secret directly or via its configuration, depend on the daemon. Check that daemon's page under Daemons and its configuration for the precise file name and key.
Two kinds of secret live outside the per-daemon secrets/ directories and are handled in their own way.
/etc/binions/<daemon>.license. These are written and renewed by the activation process — you do not edit them by hand. See Activating a licence./opt/binions/traefik/secrets/server.key, with mode 0600. See TLS & the Traefik edge.The defaults are safe out of the box. These habits keep them that way:
*.password or *.key file, or anything containing one, to git.application.toml, prefer the file reference.0600), inside a 0700 directory. Do not loosen these.A leaked secret is a real risk. Anything you paste into a playbook, a config file you commit, or a shared note can end up where it should not. Keep credentials in the daemon's
secrets/directory, refer to resources by name, and rotate any secret you suspect has been exposed.