DEV Community: Md Umair

A Better Way to Handle Docker Secrets — No Cloud, No .env, No Leaks

Md Umair — Fri, 01 May 2026 17:47:08 +0000

🚨 The "Invisible" Security Hole in Your Docker Setup

We've all heard it: "Don't commit .env files to Git."

So you .gitignore them, pat yourself on the back, and move on. But here's the uncomfortable truth — your secrets are still exposed. They're sitting in plain text on your server's disk, and more embarrassingly, they're baked right into your container's metadata.

Don't believe me? Try this on any Docker host you have access to:

docker inspect <container_id> | grep -A10 "Env"

There they are. DB passwords, Stripe keys, API tokens — readable by anyone with basic Docker access. No hacking required.

That’s why I rebuilt Docker Secret Operator (DSO).

🚀 DSO v3.2: Local-First, Cloud-Optional

The original DSO was designed for production environments — AWS, Vault, that sort of thing. But v3.2 is different. It's built for every developer, including you on your laptop right now.

The headline feature: "Zero-Cloud" Local Mode.
No AWS account.
No root access.
No background daemon.

Just a clean, secure way to handle secrets locally.

Feature	`.env` Files	Docker Secrets (Swarm)	DSO v3.2
Storage	Plaintext on disk	Encrypted (Swarm only)	AES-256-GCM Vault
Git Safety	High risk	Safe	Native (`~/.dso`)
Inspect Leak	❌ Exposed	✅ Secure	✅ Secure (`dsofile://`)
Cloud Sync	❌ Manual	❌ None	✅ AWS / Vault / Azure
Complexity	Low	High (needs Swarm)	Low (one command)

🔄 The "Before & After"
Most setups today:

services:
  api:
    env_file: .env  # ❌ Plaintext secrets sitting on your disk

With DSO:

services:
  db:
    image: postgres:15
    environment:
      POSTGRES_PASSWORD_FILE: dsofile://app/db_pass

What happens under the hood:

DSO parses your compose file (AST-level, not string replace)
Detects dsofile://
Mounts a tmpfs (RAM disk) inside the container
Streams the secret directly into memory

Result:

❌ No disk storage
❌ Not visible in docker inspect
✅ Exists only in RAM
👻 Disappears when container stops

☁️ Production Mode: Fully Real Now

If you're running production workloads, Cloud Mode is now fully implemented (not stubs anymore):

**HashiCorp Vault
AWS Secrets Manager
Azure Key Vault
Huawei CSMS**

Setup:

sudo docker dso system setup

It:

installs plugins
verifies SHA256 checksums
configures systemd
starts the agent

🩺 The Doctor Command (No More Guessing)
When something feels off:

docker dso system doctor

Example output:

DSO System Diagnostics — v3.2.0
════════════════════════════════════════════════════════════
Component         Status     Detail
────────────────────────────────────────────────────────────
Binary            OK         /usr/local/bin/dso (v3.2.0)
Effective UID     1000
Detected Mode     LOCAL      Reason: auto-detected (~/.dso/vault.enc)
Config            NOT FOUND  /etc/dso/dso.yaml
Vault             OK         /home/user/.dso/vault.enc
Systemd Service   NOT FOUND  dso-agent.service
Plugin: vault     MISSING
════════════════════════════════════════════════════════════

You instantly know:

mode (Local vs Cloud)
vault health
plugin status
system issues 👉 Works great as a CI/CD pre-check too.

📦 Zero-Dependency Setup

No Go. No build. No friction.

# Install
curl -fsSL https://raw.githubusercontent.com/docker-secret-operator/dso/main/scripts/install.sh | bash

# Initialize vault
docker dso init

# Store secret
docker dso secret set myapp/db_pass

# Run stack
docker dso up -d

Done. No .env file. No plaintext secrets.

🔗 Links
GitHub: https://github.com/docker-secret-operator/dso
Docs: https://dso.skycloudops.in/docs/

💬 Final Thought

Most secret leaks don’t happen in production.

They happen in:

laptops
staging environments
“temporary setups”

If you're still using .env files… try this once.

🚀 Feedback

What are you using today?
Google Secret Manager?
1Password?
Something custom?

Drop a comment — it directly shapes what I build next.

Stop Using .env Files for Docker Secrets — Try This Instead

Md Umair — Thu, 16 Apr 2026 16:49:45 +0000

Managing secrets in Docker usually starts simple—a .env file here, a hardcoded variable there. But once you move past a single local machine, things get messy quickly.

Kubernetes users are spoiled for choice with tools like External Secrets Operator (ESO), but for those of us running standalone Docker or Compose on a handful of VMs, the options have always felt a bit "hacked together." You’re often stuck with the manual overhead of syncing files, or worse, hard-coding "temporary" credentials that inevitably end up in a Git commit.It works — until it doesn’t.

I started Docker Secret Operator (DSO) as a side project to solve a specific headache: I wanted my containers to talk to cloud secret managers without managing local files or SSHing into servers every time a password changed.

What is DSO?

DSO is a lightweight way to manage secrets in plain Docker environments. It consists of two parts: a background Agent that talks to your cloud provider (AWS, Azure, Vault, etc.) and a Docker CLI Plugin that lets you run containers with those secrets injected at runtime.

The goal was simple: your application code should just see an environment variable like DB_PASSWORD, but that password should never exist as a plain text string on your server’s disk.

Comparison: How do we handle secrets?

Feature	.env Files	Docker Secrets (Swarm)	DSO
Storage	Plaintext on disk	Encrypted (Swarm only)	In-memory (RAM)
Cloud Sync	Manual	No	Native (AWS/Vault/etc)
Rotation	Manual restart	Manual	Automatic

What Problem It Solves

If you aren't on Kubernetes, your options are usually a bit messy. You're either hoping nobody with read access to the server steals your .env files, or you're setting host environment variables manually, which makes automation a nightmare.

DSO fills this gap. It fetches secrets directly from your source of truth and injects them into your containers. If you update a secret in your cloud console, DSO can detect that change and automatically rotate the credentials in your running containers—no manual intervention needed.

How It Works

At a high level, it works like this:

DSO Agent: Runs as a systemd service. It authenticates with your provider, fetches secrets, and keeps them in an in-memory RAM cache. They never touch the physical disk.
CLI Plugin: You use docker dso up instead of docker compose up.
Communication: The CLI talks to the agent over a secure Unix domain socket (/var/run/dso.sock).
Injection: The plugin overlays the secrets onto your container's environment just as it starts.

Key Features

Zero-Persistence: Secrets live in RAM, never on disk.
Multi-Cloud: Native support for AWS Secrets Manager, Azure Key Vault, HashiCorp Vault, and Huawei CSMS.
Auto-Rotation: Refreshes the cache and can trigger rolling restarts when a secret changes.
Native UX: It’s a Docker plugin, so it works seamlessly with the standard docker command.
Tiny Footprint: Written in Go with minimal resource usage.

Installation & Quick Setup

You can get up and running on Ubuntu or Debian with a single command:

curl -fsSL https://raw.githubusercontent.com/docker-secret-operator/dso/main/install.sh | sudo bash

Next, create your configuration file at /etc/dso/dso.yaml. Here’s what a typical AWS setup looks like:

providers:
  aws-prod:
    type: aws
    region: us-east-1    # Change to your AWS region
    auth:
      method: iam_role

agent:
  cache: true
  watch:
    polling_interval: 5m    

defaults:
  inject:
    type: env
  rotation:
    enabled: true
    strategy: rolling # Default strategy for all secrets

secrets:
  - name: arn:aws:secretsmanager:REGION:ACCOUNT:secret:YOUR_SECRET_NAME
    provider: aws-prod
    rotation:
      strategy: restart # Override global default for this specific secret
    mappings:
      DB_USER: MYSQL_USER
      DB_PASSWORD: MYSQL_PASSWORD

Start the agent:

sudo systemctl start dso-agent.service

Example Usage

In your docker-compose.yaml, you just reference the keys without values:

services:
  api:
    image: my-app:latest
    environment:
      - DB_USER      # DSO will fill this
      - DB_PASSWORD  # DSO will fill this

Now, instead of the standard compose command, run:

docker dso up -d

DSO will fetch the credentials from AWS, map them to your environment variables, and start your stack. No .env files to manage.

Why I Built This

I built this because I was tired of the "secret drift" problem. I'd update a database password in the cloud console, and then have to remember which five EC2 instances needed an .env update and a manual docker compose restart.

Missing even one instance usually led to a production fire at 2 AM. I wanted a "set it and forget it" solution—something that felt native to the Docker CLI but had the brains to handle fetching and rotating secrets automatically. DSO is the result of that frustration.

Closing

DSO is open-source, and I’m looking for feedback. If you're running Docker without Kubernetes, this might save you a lot of headaches.

GitHub: docker-secret-operator/dso
Documentation: https://dso.skycloudops.in/docs/

I'd love to hear what other providers or features you'd like to see. PRs and feedback are always welcome!