Skip to main content

Security Considerations

AKA Don't Be a Dumb Dumb

Exposing Dockman

Why Exposing Dockman to the Internet Is a Terrible Idea

Dockman has access to your Docker socket, which is essentially root access to your entire system. One compromised Dockman instance means a bad day for you.

It gets worse if you're using Dockman to manage remote Docker hosts. Since it connects via SSH, a breach doesn't just compromise one server it potentially compromises every connected machine in your setup.

How to Secure Dockman

Keep dockman local only. It's designed for your private network, not the wild west of the internet. When you need remote access, use a VPN like Netbird or Tailscale to securely tunnel into your network.

Also, enable Dockman's built-in authentication. On a private network, this gives you sufficient protection for most home setups without making things overly complicated.

Git Repository Security

Why Secrets in Git Are Usually Bad (But OK Here)

Your dockman repo breaks the usual rules about secrets in git repositories, and that's intentional. Unlike most projects, this repository lives permanently on your homelab server, which changes everything about secret management.

Git makes secret tracking easier here. When you update your Plex API key or database password and something breaks, you can roll back to the previous working configuration. Since this isn't a collaboration repo, the typical concerns about team access don't apply.

How People Usually Mess This Up

The stories about secrets in git involve one mistake: pushing to public repositories. Don't accidentally commit API keys to public GitHub repos. If you need remote backup, use private self-hosted solutions like Gitea on a VPS.

What Works

Keep secrets directly in your local repository; it makes change tracking easier. Your homelab repo should never touch public services like GitHub or GitLab.

If you prefer .env files with .gitignore, that works too; dockman doesn't enforce any particular convention.