When deploying applications with Docker Swarm, youβll often run into a common problem: how do you securely handle secrets like API keys, database passwords, and tokens? Storing them in .env
files or hardcoding them into your docker-compose.yml
is dangerous β especially in production.
In this post, letβs break down why Swarm secrets are important, how to use them, and a real-world example to make your apps more secure and production-ready. π
π€ Why Not Just Use .env
Files?
Environment variables in .env
files are fine for local development, but:
- They can accidentally get committed to Git.
- Anyone with access to the container can read them via
docker inspect
orps
. - They are not encrypted and not safe for production.
If your production secrets are stored in plaintext, it's like locking your house but leaving the key under the doormat.
π§ͺ Enter: Docker Swarm Secrets
Docker Swarm provides a built-in way to securely store and manage secrets, such as passwords, TLS certificates, or SSH keys. These secrets are:
- Stored encrypted at rest.
- Exposed only to services that need them.
- Mounted as read-only files inside containers.
- Never exposed in
docker inspect
, logs, orps
.
βοΈ How to Create and Use Secrets in Swarm
Letβs go step-by-step with a practical example:
1. π§ͺ Create a Secret
echo "my-super-secret-password" | docker secret create db_password -
This creates a secret named
db_password
.
2. π Use the Secret in a Service
Letβs say you have a MySQL container that needs the password:
# docker-compose.yml (Swarm version)
version: '3.9'
services:
mysql:
image: mysql:8
environment:
- MYSQL_ROOT_PASSWORD_FILE=/run/secrets/db_password
secrets:
- db_password
deploy:
replicas: 1
secrets:
db_password:
external: true
Notice how we use
_FILE
to read the secret from a mounted file. Docker injects it to/run/secrets/db_password
.
3. π Deploy with Swarm
docker stack deploy -c docker-compose.yml my_stack
Thatβs it! π Your container now securely uses the secret without exposing it as an environment variable.
π§Ό Best Practices for Using Docker Secrets
β
Use _FILE
suffix whenever possible β this tells your app to read from the file, not an env var.
β
Avoid docker secrets create
in CI β instead, automate it via scripts or CI/CD tools.
β
Rotate secrets regularly. You can update them by removing and recreating them with the same name.
β
Use access control β only services that need the secret should have access.
π‘οΈ Real-World Analogy
Think of Docker secrets like bank safety deposit boxes:
- You (Swarm manager) create the box (secret).
- Only specific people (containers/services) can view inside.
- No one else in the building (host or other containers) can peek in.
Much safer than hiding cash under your pillow (.env
).
π§ Final Thoughts
If youβre building secure, production-ready applications with Docker Swarm, you should never store secrets as environment variables.
Instead, leverage Docker Secrets to protect your sensitive data with minimal effort and maximum security. π
π Bonus: Tools That Work Well with Docker Secrets
- π HashiCorp Vault
- π οΈ Docker configs β for non-sensitive config files
- π sops + GitOps for encrypted secrets in Git
Need help setting this up for your own app? Drop a comment or reach out β happy to help!
Top comments (0)