Docker Web UI Security in 2026: Who Actually Publishes a Threat Model

Recently I posted a comparison of 10 Docker web UIs on r/selfhosted. A commenter asked a question I hadn't answered in the original article:

If I were selecting a Docker web UI, I think my first and highest concern would be security. If you're running rootful Docker, compromising the Docker web UI means achieving root access to the host.

Do any of these options support rootless Docker?

Do they publish any information about their security architecture and how they approach minimizing their attack surface?

Fair question. I went through the docs of all 10 tools and built a matrix. This is that writeup.

TL;DR:

• Only Portainer explicitly documents rootless Docker support (with caveats)
• Only Rancher and Portainer publish comprehensive security architecture
• Dockhand and Arcane publish serious security-adjacent artifacts (hardened image / SBOM / disclosure policy)
• Almost everyone else is silent on the topic
• "Connect via TCP" is not a rootless workaround - it's a common misconception worth clearing up

First: a technical point nobody in my Reddit thread got right

Several commenters (including me, initially) reached for "you can expose Docker via TCP so it doesn't need root." That's wrong, and Docker's own documentation is explicit about it.

Docker's remote-access docs state:

If steps aren't taken to secure the connection, it's possible for remote non-root users to gain root access on the host.

Translation: the transport (Unix socket vs TCP) is orthogonal to whether the daemon runs as root. Exposing the API over TCP just changes how you connect - the daemon behind the socket is still rootful unless you specifically configured rootless mode. TLS on the TCP connection protects against network sniffing, not against "compromise the client = root on host."

Rootless mode is a separate daemon configuration - different install script (dockerd-rootless-setuptool.sh), user-namespace based, with real functional limitations (some storage drivers, cgroups behavior, networking). It's the only meaningful mitigation for the "UI compromise = host root" risk.

That's the frame. Now the matrix.

The matrix

Fetched from each tool's official documentation. Where I couldn't find explicit documentation, I marked "not documented" rather than guessing.

What jumps out

Rancher is in a different league

Rancher publishes CIS Benchmark alignment, integrates kube-bench for automated compliance scanning, ships SELinux packages, supports Pod Security Standards, and has public pentest reports from Cure53. That's a mature enterprise-grade security posture. If you're running Kubernetes at any real scale and security is your primary lens, this is the only serious answer in the list.

Portainer is the mature Docker-native option

Every recent release note includes explicit CVE remediation entries (upgrading containerd, oras-go, grpc, go-git, etc. to address specific CVEs). They publish a security email, run GitHub Security Advisories, and their rootless docs at least exist even if they say "some limitations." That's more than 7 of the other 9 tools can claim.

Dockhand and Arcane are punching above their weight

Both are much smaller projects than Portainer or Rancher but ship real security artifacts:

• Dockhand: hardened container image built from Wolfi packages (rather than Alpine), AES-256-GCM at rest, Grype+Trivy scanning with "safe-pull protection" (new images scanned before deployment)
• Arcane: published SBOM, formal SECURITY.md disclosure process, an explicit AI_POLICY.md for security reports (they've clearly been hit by AI CVE farming - refreshingly honest about it)

Neither has full architecture documentation, but they've done the meaningful work.

Almost nobody explicitly documents rootless

This surprised me. Rootless Docker has been GA for years. It has real limitations (some storage drivers, cgroup v2 requirements, no --privileged, no host network mode) - but the fact that even security-focused UIs don't clearly say "we support it" or "we don't" is a gap the category as a whole should fix.

"Connect via TCP" is not a mitigation

I already covered this above, but it bears repeating because I've seen it as commentary in multiple threads: exposing the Docker API over TCP does not reduce root privilege risk. Rootless mode is the only real answer here.

What "rootless" actually costs you

Rootless Docker isn't free. If you're evaluating it, the trade-offs are:

• Storage drivers: overlay2 requires kernel ≥ 5.11 with fuse-overlayfs fallback. Some setups end up on the slower vfs driver.
• Networking: no host network mode. Port publishing < 1024 requires additional capability setup. Some overlay networks behave differently.
• --privileged containers: don't work.
• cgroup v2 required for full functionality (fine on modern distros, painful on older ones).
• Some Docker features unavailable: no docker run --sysctl, limited access to certain namespaces.

For most self-hosted workloads (web apps, databases, background workers), these limitations are fine. For workloads that need privileged containers, host networking, or specialised kernel features, rootless will be too restrictive.

Docker's rootless docs list the current known limitations - worth reading before committing.

Recommendations by risk profile

"I run 5 self-hosted apps at home and my threat model is 'don't get pwned by a drive-by'"

• Portainer or Dockge are both fine. Put them behind a reverse proxy with auth, don't expose them to the internet, and you're covered against 95% of what actually gets you in a home setup.

"I run this at a small company and someone will eventually run an audit"

• Portainer CE at minimum, Portainer BE if you can afford it. The published CVE remediation trail is what an auditor will actually check. Enable rootless mode if your workloads support it.

"I'm hosting client workloads and my liability is real"

• Rancher if you're on Kubernetes. If you're on plain Docker, no tool in this category really meets a "clients pay us to protect their data" bar - you'll be layering on your own controls (Falco, Sysdig, network policies) regardless.

"I care about supply chain and provenance"

• Dockhand (Wolfi-from-scratch image) or Arcane (published SBOM) are the standouts. Both are much less established than Portainer, so you're trading feature depth for a better security artifact.

"I want infrastructure-as-code and no web UI at all"

• This is where Stacker (my project) fits - config-file-first, one YAML per stack, no dashboard by default. But the "no dashboard" position is a security posture choice, not a rootless-Docker feature. Stacker itself doesn't currently document rootless mode either - fixing that is on my list.

What I updated after doing this research

Two things worth mentioning honestly:

1. Added a SECURITY.md to the Stacker repo. I was calling out other tools for not publishing one - felt fair to close my own gap first. It's at github.com/trydirect/stacker/blob/main/SECURITY.md - includes disclosure contact, response SLA, in/out-of-scope definitions, and coordinated disclosure timing.

2. Rootless documentation is a real gap for the entire category. I'm going to actually test Stacker + rootless Docker on the target server, document the result, and publish either "supported" or "here's what breaks and why" - because right now I don't know for certain and neither do most of the tools in this list.

What I'd like to hear from readers

• Anyone running any of these tools successfully against a rootless daemon? What broke, what worked?
• If you use Portainer BE at work, does the "rootless with some limitations" story hold up in practice?
• Anyone at Coolify / Dokploy / Komodo / Runtipi able to say officially where their teams stand on rootless support?

Drop it in the comments. I'll update this article as answers come in.

This article was assisted by an AI in drafting and structuring; every technical claim above was verified against a source I fetched from the tool's official documentation, GitHub repository, or docs.docker.com. Links are all verified working as of publication. If something's wrong, tell me and I'll correct it.