Secret rotation in Docker Swarm is a solved problem in theory. Docker has supported pluggable secret drivers since 2017 a plugin interface that can fetch a secret's value at runtime instead of storing a static blob.
In practice, almost nobody uses this, and most Swarm deployments still update secrets manually by hand: create a new secret, edit every compose file that references it, redeploy, and hope you remember to delete the old one. Cumbersome right?
Kubernetes solved this same problem with External Secrets Operator (ESO) open source controller which helps manage secrets in Kubernetes applications that watches an external provider like HashiCorp Vault or AWS Secrets Manager and keeps a Kubernetes Secret in sync automatically. Docker Swarm has no equivalent ecosystem, even though it has had the right extension point for longer than Kubernetes has.
In this session, I will demonstrate swarm-external-secrets (SES), an open-source Docker Swarm secrets plugin that closes this gap. SES integrates HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, and OpenBao behind a single driver interface, and runs a background rotation loop that detects when a secret changes upstream, creates a new Docker secret version, force-updates every service using it, and removes the old version without human running any command.
This will explain about how secrets and never known by docker until runtime need them, docker never cares about who it is getting secret from not it store secret it just store metadata of secret (where secret can be available). There is one cool concept of how docker mounts secret at runtime using docker.sock ( Inter-Process Communication ).
I will walk through why this was harder to build than it sounds: Docker secrets are immutable once created, so "rotation" is not a retrieval problem, it is a distributed replace-and-redeploy problem across every node running the service.
How secret is co-ordinated and shared across manager and other node in swarm architecture and also how RAFT logs use them and what are some of best practices of handling Docker Swarm deployments with external secret providers.
The following make this project worth watching even if you've never touched Docker Swarm:
A working secret-rotation reconciliation loop built without a Kubernetes-style controller runtime underneath it
Multi-provider support (Vault, AWS Secrets Manager, Azure Key Vault, OpenBao) behind one driver contract, with per-secret label-based configuration
A built-in monitoring dashboard exposing rotation success/failure rates, provider health, and Prometheus-format metrics
A live demo: rotating a database password in Vault on stage and watching it propagate to a running service with zero manual steps
An honest threat-model discussion of what it costs to give any plugin docker.sock access including for SES itself
Honestly this is project i am working on since past 6 months and surprisingly this is the project i got selected for to work as Google Summer of Code Mentee 2026 at OpenScienceLabs.
