Frequently Asked Questions

DSO is a runtime secret injection system for Docker containers. It eliminates the need to store secrets in environment variables or config files by injecting them from external sources (local encrypted vault, AWS Secrets Manager, Azure Key Vault, etc.) directly into container memory at startup.

No. DSO is explicitly designed for teams NOT using Kubernetes. It's built for Docker Compose and Docker-native deployments. If you're on Kubernetes, consider External Secrets Operator (ESO) instead.

Yes. DSO's Local Mode provides an encrypted vault for development without needing cloud accounts. It's perfect for learning DSO patterns before deploying to production.

DSO supports AWS Secrets Manager, Azure Key Vault, HashiCorp Vault, Huawei Cloud CSMS, and Local Mode (encrypted vault). See /integrations for complete setup guides.

Secrets are fetched at runtime and injected into container environment variables in memory. They're never written to disk, logs, or container inspect output. When the container stops, the secret is gone.

Yes. All communication with cloud providers (AWS, Azure, etc.) uses TLS 1.2+. Local Mode uses AES-256-GCM encryption for secrets at rest.

DSO polls your secret provider at configurable intervals (default 2 minutes). When a change is detected, DSO applies your reload_strategy: restart (restart container), rolling (rolling restart), or signal (send SIGHUP).

Yes. DSO works with any registry. Your images don't contain secrets—they only contain references like dso://my-secret. Actual secrets come from your configured provider.

Yes. DSO works seamlessly with Docker Compose. Use dso:// references in environment variables and run 'docker dso up' instead of 'docker compose up'.

Yes. Multiple containers can reference the same secret. Access control is managed by your provider's IAM (AWS IAM, Azure RBAC, etc.).

By default, DSO fails fast—the container won't start if secrets can't be fetched. This prevents containers from running with missing or stale secrets.

Yes. DSO works in CI/CD as long as the runner has credentials to access your secret provider. For Local Mode, use the encrypted vault in your repository.

Verify the secret name in dso.yaml matches exactly what's in your provider. Check that your credentials have permission to read that secret. Run 'docker dso doctor' for diagnostics.

Your credentials don't have permission to access that secret. For AWS: check IAM policy. For Azure: check RBAC role. For Vault: check AppRole permissions.

Check that dso.yaml uses dso://SECRET_NAME syntax (not hardcoded values). Verify the secret exists in your provider. Check logs: 'docker dso logs container-name'

Use 'docker dso doctor' to verify setup. Check 'docker dso logs' for detailed output. For container inspection: 'docker exec container env | grep SECRET' shows injected values.

Yes. DSO is open source under Apache 2.0. You only pay for the secrets infrastructure (AWS charges ~$0.40/secret/month, etc.).

Yes. Apache 2.0 allows commercial use. Check the LICENSE file for full details.

DSO is open source and designed for developers. Paid alternatives add GUI, audit dashboards, and enterprise support. Choose DSO if you prefer CLI-driven simplicity.