Docker Secrets & Config Management
Out of .env files, encrypted at rest
The default state of Docker secrets on a fleet is quietly terrible: plaintext .env files copied to each host, drifting from each other, readable by anyone with SSH, and referenced by nothing that can tell you where a credential is actually used — which makes rotation a guessing game.
BridgePort replaces that with an encrypted, environment-scoped store wired directly into config management. Secrets are AES-256-GCM encrypted at rest with a master key you provide; config files are composed from reusable fragments and templated per server; and every secret knows exactly which files reference it.
How it works
Store secrets and variables per environment
Secrets are encrypted with AES-256-GCM before they touch the database; revealing a decrypted value is restricted to admins, and sensitive operations are audit-logged.
Compose config from fragments
Reusable, environment-scoped fragments share common blocks across config files. Files can iterate tagged servers with range templating — one source renders correctly for every host.
Reference secrets in config files
Usage is tracked in both directions: list which files use a secret before rotating it, and see what a file depends on before touching it.
Sync atomically
Config rollouts run as all-or-nothing sync batches with dry-run previews and rollback. Editing a shared fragment auto-resyncs every dependent file; file edits keep history for rollback.
What you get
AES-256-GCM at rest
Secrets are encrypted with a master key you control; the database never stores plaintext values.
Secrets & variables →Admin-only reveal
Viewer and operator roles can use secrets in deployments without ever being able to read the decrypted values.
Users & roles →Usage tracking
Join tables map secrets and variables to the config files that reference them — rotation stops being archaeology.
Secrets guide →Reusable fragments
Shared config blocks defined once and included everywhere, with automatic resync of dependents on change.
Config files →Atomic sync batches
Multi-file, multi-server config rollouts are transactional: preview with dry-run, apply all-or-nothing, roll back if needed.
Config sync →Encrypted SSH keys too
Per-environment SSH keys are stored encrypted with the same machinery that protects your secrets.
Security & hardening →Frequently asked questions
How are secrets encrypted?
With AES-256-GCM, using a master key you provide via environment variable when running BridgePort. Values are encrypted before storage and decrypted only when needed for a deployment or an admin-initiated reveal.
Can my whole team see secret values?
No. Revealing decrypted secret values is an admin-only operation. Other roles can reference secrets in services and config without read access to the values, and reveals are audit-logged.
What happens when I edit a fragment used by many config files?
Dependent files are automatically resynced so servers never run a stale mix. Sync batches make multi-file rollouts atomic, with dry-run previews and rollback.
How do I know where a secret is used before rotating it?
BridgePort tracks which config files reference each secret and variable, so the blast radius of a rotation is a list you can read, not something you discover in production.