Project summary
Secure secret management and automated rotation for Docker and Docker Compose.
Project description
DSO helps teams get secrets into containers securely when they aren't using Kubernetes. Most standalone Docker setups still rely on insecure .env files or fragile manual scripts to pull secrets from vaults. DSO replaces this with a simple Go-based agent that syncs secrets directly from HashiCorp Vault, AWS, Azure, and others into your containers. It uses in-memory streaming so secrets never touch the host's disk, and it can automatically reload or restart containers when a secret is rotated. It's built to give the millions of Docker Compose users the same level of security and automation that Kubernetes users already enjoy.
Org repo URL (provide if all repos under the org are in scope of the application)
https://github.com/docker-secret-operator
Project repo URL in scope of application
https://github.com/docker-secret-operator/dso
Additional repos in scope of the application
No response
Website URL
https://dso.skycloudops.in/
Roadmap
https://github.com/docker-secret-operator/dso#roadmap
Roadmap context
DSO aims to bring enterprise-grade secret management to the vast landscape of non-Kubernetes Docker workloads. We are currently finalizing the v3 production-ready core, which includes a pluggable provider model and event-driven triggers.
Contributing guide
https://github.com/docker-secret-operator/dso/blob/main/CONTRIBUTING.md
Code of Conduct (CoC)
https://github.com/docker-secret-operator/dso/blob/main/CODE_OF_CONDUCT.md
Adopters
https://github.com/docker-secret-operator/dso/blob/main/ADOPTERS.md
Maintainers file
https://github.com/docker-secret-operator/dso/blob/main/MAINTAINERS.md
Security policy file
https://github.com/docker-secret-operator/dso/blob/main/SECURITY.md
Standard or specification?
N/A
Business product or service to project separation
DSO is an independent, community-driven project with no corporate product ties. It was created to solve a fundamental security gap in the Docker ecosystem and is not part of any commercial offering.
Why CNCF?
We want to give DSO a long-term, neutral home where it can grow. While there is a lot of great innovation in the Kubernetes space, the millions of containers running on standalone Docker engines are often left behind with outdated or unsafe security practices. We believe DSO can become the go-to standard for secret injection in these environments, and joining the CNCF is the best way to build community trust and a sustainable path forward.
Benefit to the landscape
DSO fills a gap by extending cloud-native security patterns to non-Kubernetes environments. It ensures that projects like HashiCorp Vault (a graduated CNCF project) can be easily and securely consumed by standard Docker workloads. By making cloud-native secret management accessible to edge computing, IoT, and standard server environments, we’re helping a massive group of developers improve their security posture without forcing them to move to Kubernetes.
Cloud native 'fit'
DSO is built around "reconciliation"—the core idea that makes Kubernetes work. Instead of just pushing a secret once, DSO continuously watches the provider and ensures the container’s state matches what's declared in the config. It handles the difficult parts of container lifecycles, health checks, and rollbacks automatically, bringing a truly declarative and resilient approach to standard Docker workloads.
Cloud native 'integration'
Directly integrates with HashiCorp Vault (Graduated) and major cloud providers.
Cloud native overlap
Shares conceptual goals with the External Secrets Operator but focuses exclusively on non-Kubernetes runtimes, filling a unique gap in the CNCF Runtime and Provisioning layers.
Similar projects
The closest CNCF project is the External Secrets Operator (ESO). While ESO is fantastic, it is built exclusively for Kubernetes. DSO brings that same "reconciliation" pattern to the millions of containers still running on standalone Docker and Docker Compose. Other similar tools include HashiCorp Vault Agent, though DSO is designed to be provider-agnostic (supporting AWS, Azure, etc. in a single setup).
Landscape
N/A
Insights
N/A
Trademark and accounts
IP policy
Will the project require a license exception?
N/A (Project is licensed under Apache-2.0)
Project "Domain Technical Review"
N/A (We look forward to engaging with TAG Security for a formal review after entering the Sandbox).
Application contact email(s)
umairmd385@gmail.com
Contributing or sponsoring entity signatory information
| Name | Country | Email address |
| Md Umair | India | umairmd385@gmail.com |
CNCF contacts
N/A
Additional information
DSO was created to solve a "last-mile" security problem that has existed for a decade in the Docker ecosystem. While Kubernetes has excellent secret management, standalone Docker users are often forced to choose between "easy" (insecure .env files) and "secure" (complex custom scripts). Proper, automated secret rotation should be accessible regardless of the orchestrator choice.
Project summary
Secure secret management and automated rotation for Docker and Docker Compose.
Project description
DSO helps teams get secrets into containers securely when they aren't using Kubernetes. Most standalone Docker setups still rely on insecure .env files or fragile manual scripts to pull secrets from vaults. DSO replaces this with a simple Go-based agent that syncs secrets directly from HashiCorp Vault, AWS, Azure, and others into your containers. It uses in-memory streaming so secrets never touch the host's disk, and it can automatically reload or restart containers when a secret is rotated. It's built to give the millions of Docker Compose users the same level of security and automation that Kubernetes users already enjoy.
Org repo URL (provide if all repos under the org are in scope of the application)
https://github.com/docker-secret-operator
Project repo URL in scope of application
https://github.com/docker-secret-operator/dso
Additional repos in scope of the application
No response
Website URL
https://dso.skycloudops.in/
Roadmap
https://github.com/docker-secret-operator/dso#roadmap
Roadmap context
DSO aims to bring enterprise-grade secret management to the vast landscape of non-Kubernetes Docker workloads. We are currently finalizing the v3 production-ready core, which includes a pluggable provider model and event-driven triggers.
Contributing guide
https://github.com/docker-secret-operator/dso/blob/main/CONTRIBUTING.md
Code of Conduct (CoC)
https://github.com/docker-secret-operator/dso/blob/main/CODE_OF_CONDUCT.md
Adopters
https://github.com/docker-secret-operator/dso/blob/main/ADOPTERS.md
Maintainers file
https://github.com/docker-secret-operator/dso/blob/main/MAINTAINERS.md
Security policy file
https://github.com/docker-secret-operator/dso/blob/main/SECURITY.md
Standard or specification?
N/A
Business product or service to project separation
DSO is an independent, community-driven project with no corporate product ties. It was created to solve a fundamental security gap in the Docker ecosystem and is not part of any commercial offering.
Why CNCF?
We want to give DSO a long-term, neutral home where it can grow. While there is a lot of great innovation in the Kubernetes space, the millions of containers running on standalone Docker engines are often left behind with outdated or unsafe security practices. We believe DSO can become the go-to standard for secret injection in these environments, and joining the CNCF is the best way to build community trust and a sustainable path forward.
Benefit to the landscape
DSO fills a gap by extending cloud-native security patterns to non-Kubernetes environments. It ensures that projects like HashiCorp Vault (a graduated CNCF project) can be easily and securely consumed by standard Docker workloads. By making cloud-native secret management accessible to edge computing, IoT, and standard server environments, we’re helping a massive group of developers improve their security posture without forcing them to move to Kubernetes.
Cloud native 'fit'
DSO is built around "reconciliation"—the core idea that makes Kubernetes work. Instead of just pushing a secret once, DSO continuously watches the provider and ensures the container’s state matches what's declared in the config. It handles the difficult parts of container lifecycles, health checks, and rollbacks automatically, bringing a truly declarative and resilient approach to standard Docker workloads.
Cloud native 'integration'
Directly integrates with HashiCorp Vault (Graduated) and major cloud providers.
Cloud native overlap
Shares conceptual goals with the External Secrets Operator but focuses exclusively on non-Kubernetes runtimes, filling a unique gap in the CNCF Runtime and Provisioning layers.
Similar projects
The closest CNCF project is the External Secrets Operator (ESO). While ESO is fantastic, it is built exclusively for Kubernetes. DSO brings that same "reconciliation" pattern to the millions of containers still running on standalone Docker and Docker Compose. Other similar tools include HashiCorp Vault Agent, though DSO is designed to be provider-agnostic (supporting AWS, Azure, etc. in a single setup).
Landscape
N/A
Insights
N/A
Trademark and accounts
IP policy
Will the project require a license exception?
N/A (Project is licensed under Apache-2.0)
Project "Domain Technical Review"
N/A (We look forward to engaging with TAG Security for a formal review after entering the Sandbox).
Application contact email(s)
umairmd385@gmail.com
Contributing or sponsoring entity signatory information
| Name | Country | Email address |
| Md Umair | India | umairmd385@gmail.com |
CNCF contacts
N/A
Additional information
DSO was created to solve a "last-mile" security problem that has existed for a decade in the Docker ecosystem. While Kubernetes has excellent secret management, standalone Docker users are often forced to choose between "easy" (insecure .env files) and "secure" (complex custom scripts). Proper, automated secret rotation should be accessible regardless of the orchestrator choice.