Why we built dockguard: Docker Compose security shouldn't need a PhD
If you've ever copied a docker-compose.yml from a GitHub README and run it in production, you're not alone. Most self-hosters do. And most of those files ship with security configurations that would make any sysadmin wince.
The problem
We looked at hundreds of Docker Compose files from popular open-source projects. The patterns were consistent:
privileged: trueon containers that don't need it- Exposed ports bound to
0.0.0.0instead of127.0.0.1 - No resource limits — a runaway container eats the whole host
- Plaintext secrets in environment variables, committed to Git
CAP_SYS_ADMINand other capabilities granted "just in case"- No read-only root filesystem on containers that only need to write to specific paths
Each of these is individually fixable. But knowing which fixes apply to which images requires context. A Postgres container needs different capabilities than an Nginx container.
What dockguard does
dockguard scan docker-compose.yml
dockguard reads your Compose file, identifies each service's base image, and checks it against a library of service-aware security rules. It knows that Postgres needs write access to /var/lib/postgresql/data but doesn't need NET_RAW. It knows Nginx needs to bind port 80 but shouldn't have SYS_ADMIN.
Then it generates a hardened version:
dockguard fix docker-compose.yml -o docker-compose.hardened.yml
The output is a drop-in replacement. Same services, same behavior, fewer attack surfaces.
Who it's for
Self-hosters running services on a VPS, NAS, or home server. People who know Docker well enough to deploy but don't want to become container security experts. If you're running Traefik, Postgres, Redis, Grafana, or any of the other 20+ images dockguard understands, it works out of the box.
Try it
dockguard is free and open source. One binary, no dependencies, no account needed.