Docker Rootful vs Rootless: Performance, Security & When to Use Each

Rootful and Rootless, Side by Side

Rootful Docker: the dockerd binary runs as UID 0 on the host. You talk to it via /var/run/docker.sock, a socket owned by root and readable by whoever is in the docker group. Containers the daemon launches default to UID 0 inside a PID namespace, which -- because of the shared kernel -- maps straight to UID 0 on the host unless you opt into user namespaces. A successful container escape is a successful host compromise. That is the default model on every stock Docker install since 2013.

Rootless Docker: the same dockerd binary runs as an unprivileged user (e.g. UID 1000) inside that user's session. Container UID 0 maps to a subordinate UID like 100000 on the host via newuidmap / newgidmap. Networking runs in userspace (slirp4netns or pasta) because creating kernel namespaces requires capabilities the user does not have. Storage uses the same overlay2 driver on kernel 5.11+ or falls back to fuse-overlayfs on older kernels. A container escape lands the attacker in an unprivileged user session with zero real root privileges on the host.

Everything after this paragraph is about what changes when you flip that switch. The security model is the reason to switch. The performance and compatibility trade-offs are the reason teams hesitate. Both sides have changed in the last three years -- kernel 5.11 and pasta networking eliminated most of the performance penalty -- which is why it is worth benchmarking again if the last thing you read on this topic was from 2021.

Shorthand glossary: rootful = daemon runs as root; rootless = daemon runs as a normal user with containers sandboxed in a user namespace. --userns-remap is a middle ground where the daemon still runs as root but containers get UID remapping.

Security Model Comparison

Property	Rootful Docker	Rootless Docker
Daemon UID	0 (root)	Unprivileged user (e.g., 1000)
Container UID 0 maps to host	UID 0 (real root)	UID 100000+ (subordinate range)
Docker socket access	Root-equivalent privilege	User-level, no escalation path
Container escape impact	Full host root access	Unprivileged user access only
Privileged containers	Supported (--privileged)	Not supported
Network namespace	Native kernel networking	slirp4netns or pasta (userspace)
Storage driver	overlay2 (native)	fuse-overlayfs or overlay2 (kernel 5.11+)
cgroup management	Full cgroup v1/v2 access	cgroup v2 with systemd user delegation

The security difference is not theoretical. CVE-2019-5736, a runc vulnerability that allowed container escape to host root, would have been mitigated by rootless mode because the escaped process would land in an unprivileged user namespace with no real root capabilities. CVE-2024-21626, another runc escape via leaked file descriptors, was similarly constrained in rootless configurations.

Setting Up Rootless Docker

Rootless mode requires a few prerequisites: a Linux kernel 5.11 or later (for native overlay2 support), cgroup v2 enabled, and subordinate UID/GID ranges configured for your user.

1. Verify prerequisites:

   # Check kernel version (need 5.11+ for native overlay2)
   uname -r
   
   # Verify cgroup v2
   stat -fc %T /sys/fs/cgroup
   # Should output: cgroup2fs
   
   # Check subordinate UID/GID ranges
   cat /etc/subuid
   # youruser:100000:65536
   cat /etc/subgid
   # youruser:100000:65536

2. Install rootless Docker:

   # Install prerequisites
   sudo apt-get install -y uidmap dbus-user-session
   
   # Install rootless Docker (run as your regular user, NOT root)
   dockerd-rootless-setuptool.sh install
   
   # The script adds environment variables to your shell profile
   # Source them or log out and back in
   export PATH=/home/youruser/bin:$PATH
   export DOCKER_HOST=unix:///run/user/1000/docker.sock

3. Enable lingering so the daemon survives logout:

   sudo loginctl enable-linger $(whoami)
   
   # Verify the rootless daemon is running
   systemctl --user status docker
   
   # Test it
   docker run --rm hello-world

Performance Benchmarks: Rootful vs Rootless

The benchmarks below were run on an Ubuntu 24.04 host with kernel 6.8, 16 GB RAM, NVMe SSD, cgroup v2, and Docker Engine 27.x. Each test was repeated 50 times. The rootless configuration used native overlay2 (kernel 5.11+) rather than fuse-overlayfs.

Container Startup Time

Metric	Rootful	Rootless	Delta
Cold start (no cache)	1.82s	2.41s	+32%
Warm start (cached)	0.34s	0.48s	+41%
p95 startup	0.42s	0.61s	+45%
p99 startup	0.58s	0.89s	+53%

The startup penalty comes primarily from user namespace setup and ID mapping overhead. Cold starts include image layer extraction through the user-namespaced storage driver. The p99 gap widens because rootless mode occasionally pauses during subordinate UID/GID mapping under contention.

Memory Overhead

Metric	Rootful	Rootless	Delta
Daemon RSS	62 MB	78 MB	+26%
Per-container overhead	8 MB	11 MB	+37%
100 containers total	862 MB	1,178 MB	+37%

The extra memory comes from the rootlesskit process, user namespace bookkeeping, and the userspace networking stack. At 100 containers, rootless uses about 316 MB more than rootful -- meaningful on memory-constrained hosts but negligible on modern servers.

Storage I/O: fuse-overlayfs vs Native overlay2

Operation	Rootful (native overlay2)	Rootless (fuse-overlayfs)	Rootless (native overlay2, kernel 5.11+)
Sequential write (1 GB)	1,240 MB/s	680 MB/s (-45%)	1,180 MB/s (-5%)
Sequential read (1 GB)	2,100 MB/s	1,350 MB/s (-36%)	2,020 MB/s (-4%)
Random 4K write IOPS	48,000	19,200 (-60%)	45,600 (-5%)
Random 4K read IOPS	62,000	31,000 (-50%)	59,500 (-4%)

Warning: If your kernel is older than 5.11, rootless Docker falls back to fuse-overlayfs, which runs the overlay filesystem in userspace via FUSE. This halves your storage throughput and decimates random IOPS. Upgrading to kernel 5.11+ and using native overlay2 in rootless mode nearly eliminates the storage penalty. Always verify which driver is active with docker info | grep Storage.

Networking: slirp4netns vs pasta

Rootless containers cannot create network namespaces directly (that requires CAP_NET_ADMIN as real root). Instead, they use a userspace network stack. Docker supports two options:

Property	slirp4netns	pasta (passt)
Throughput (iperf3)	~3.2 Gbps	~7.8 Gbps
Latency overhead	+0.15ms per hop	+0.04ms per hop
CPU usage (10 Gbps test)	~45% single core	~18% single core
IPv6 support	Limited	Full
Default in Docker	Yes (legacy)	Yes (Docker 25+)

Pasta (part of the passt project) replaces slirp4netns as the default in Docker 25+ and delivers roughly 2.4x the throughput with significantly lower CPU overhead. If you are running an older Docker version, switch to pasta explicitly:

# Use pasta networking for rootless Docker
# Add to ~/.config/docker/daemon.json
{
  "network-opts": {
    "driver": "pasta"
  }
}

# Or per-container
docker run --network pasta --rm -it nginx

Even with pasta, rootless networking adds measurable overhead compared to rootful's native kernel networking. For most web applications and microservices, this overhead is irrelevant. For high-throughput data pipelines or network-intensive workloads exceeding 5 Gbps, it matters.

Rootless Docker Limitations

Not every workload runs cleanly in rootless mode. These are the hard limitations:

• Privileged ports (below 1024) -- Rootless containers cannot bind to ports below 1024 by default. Workaround: use sysctl net.ipv4.ip_unprivileged_port_start=0 or map to a higher port and reverse-proxy.
• Privileged containers -- --privileged is not supported. Containers requiring raw device access, kernel module loading, or direct hardware access must run rootful.
• AppArmor/SELinux profiles -- Custom AppArmor or SELinux profiles require root-level policy loading. Rootless mode uses a default restricted profile.
• Volume mount permissions -- Host volume mounts see files owned by the subordinate UID range, not the host user. This causes permission issues with bind mounts unless you manage UID mapping carefully.
• cgroup v1 systems -- Rootless mode requires cgroup v2 with systemd user delegation. Older distributions using cgroup v1 (RHEL 7, older Ubuntu LTS) cannot run rootless Docker.
• Overlay network (Swarm) -- Docker Swarm overlay networks do not work in rootless mode. Use rootful for Swarm clusters.

Rootless Docker vs Rootless Podman

Podman was designed rootless from the start, while Docker added rootless mode later. This architectural difference shows in practice:

Property	Rootless Docker	Rootless Podman
Architecture	Client-daemon (rootlesskit + dockerd)	Daemonless (fork-exec per container)
Idle resource usage	~78 MB (daemon always running)	~0 MB (no daemon)
Startup time (warm)	0.48s	0.52s
Docker Compose support	Native	Via podman-compose or compose with Podman socket
Systemd integration	User-level systemd unit	Generates systemd units via podman generate systemd
OCI compliance	Partial (Docker image format)	Full OCI runtime and image spec
Kubernetes pod support	No	Yes (podman pod maps to K8s pod concept)
Build system	BuildKit	Buildah (integrated)
Default network stack	pasta (Docker 25+)	pasta (Podman 4.x+)

Podman's daemonless architecture means zero idle overhead -- there is no background process consuming memory when no containers are running. This matters for CI runners where you spin up containers, run tests, and tear down. Docker's daemon model means faster subsequent container starts (the daemon is already warm) but wastes resources when idle.

# Rootless Podman is a drop-in replacement for most Docker commands
# Install on Ubuntu/Debian
sudo apt-get install -y podman

# No setup script needed -- rootless is the default
podman run --rm hello-world

# Use podman-compose for docker-compose.yml files
pip install podman-compose
podman-compose up -d

# Or use Docker Compose with Podman's compatibility socket
systemctl --user enable --now podman.socket
export DOCKER_HOST=unix:///run/user/1000/podman/podman.sock
docker compose up -d  # Uses Podman under the hood

Container Density Benchmarks

How many containers can you run on a single host before hitting resource limits? Tested on a 16 GB RAM, 8-core host running Alpine-based containers with minimal workload:

Metric	Rootful Docker	Rootless Docker	Rootless Podman
Max containers (16 GB RAM)	~1,480	~1,120	~1,350
Overhead per container	8 MB	11 MB	9.2 MB
Time to start 100 containers	18s	29s	34s
Time to stop 100 containers	4.2s	6.8s	5.1s

Rootful Docker achieves the highest density because it has the lowest per-container overhead. Rootless Podman places second due to its daemonless architecture -- no persistent daemon consuming memory. Rootless Docker trails because the rootlesskit process and daemon add fixed overhead. For high-density container hosts running hundreds of containers, rootful mode provides roughly 32% more capacity.

Hardening Rootful Docker When You Must Use It

Some workloads genuinely require rootful Docker: privileged containers for device access, Swarm overlay networks, or high-throughput networking that cannot tolerate userspace overhead. When rootful is necessary, apply these mitigations:

# 1. Never run containers as root inside the container
docker run --user 1000:1000 --rm -it myapp

# 2. Drop all capabilities and add only what you need
docker run --cap-drop=ALL --cap-add=NET_BIND_SERVICE --rm -it nginx

# 3. Enable seccomp (default profile blocks ~44 dangerous syscalls)
docker run --security-opt seccomp=default --rm -it myapp

# 4. Enable AppArmor (loaded by default on Ubuntu)
docker run --security-opt apparmor=docker-default --rm -it myapp

# 5. Make the root filesystem read-only
docker run --read-only --tmpfs /tmp --rm -it myapp

# 6. Disable inter-container communication
docker network create --opt com.docker.network.bridge.enable_icc=false isolated

# 7. Use user namespace remapping (rootful with namespace isolation)
# Add to /etc/docker/daemon.json:
# { "userns-remap": "default" }
# This gives rootful mode some rootless-like isolation

Pro tip: Even in rootful mode, --userns-remap in the daemon configuration remaps container UID 0 to an unprivileged host UID, similar to rootless mode but without the networking and storage driver changes. This is a middle ground that provides namespace isolation while keeping rootful performance and compatibility.

Failure Modes I've Hit With Rootless

The performance numbers earlier in this article are measured on a clean host. The rough edges do not show up in benchmarks -- they show up at 2 AM.

subuid/subgid Exhaustion

The default subordinate UID range from useradd is 65,536 IDs starting at 100000. If you run multiple rootless daemons (say, one per CI runner job) or use nested user namespaces (rootless Docker-in-rootless-Podman), you can run out. Symptom: newuidmap failed: Invalid argument. Fix: expand the range with usermod --add-subuids 100000-1065536 youruser or edit /etc/subuid directly. Give CI hosts at least 500,000 IDs per user.

Volume Mount Permission Chaos

You bind-mount $HOME/project into a rootless container that writes as "root" inside. On the host you now have files owned by UID 100000, unreadable by your regular user. Every new rootless adopter hits this. Fix options: use named volumes instead of bind mounts, mount with :U on Podman to remap ownership, or run the container as your host UID with --user $(id -u):$(id -g). For Docker Compose the cleanest pattern is named volumes for anything the container writes to, bind mounts only for read-only code.

cgroup v2 Controller Delegation

On systems using systemd-cgroup but where the user's slice is not configured to delegate the memory or cpu controller, rootless Docker cannot enforce resource limits. docker run --memory=512m silently has no effect. Verify delegation: cat /sys/fs/cgroup/user.slice/user-$(id -u).slice/user@$(id -u).service/cgroup.controllers. Should include cpu memory pids io. If not, drop a config:

sudo mkdir -p /etc/systemd/system/user@.service.d
sudo tee /etc/systemd/system/user@.service.d/delegate.conf <<EOF
[Service]
Delegate=cpu cpuset io memory pids
EOF
sudo systemctl daemon-reload

Port Binding Below 1024

Rootless containers cannot bind to privileged ports (below 1024) by default. An nginx container with EXPOSE 80 and -p 80:80 fails. Options: map to a high host port (-p 8080:80) and reverse-proxy with a systemd socket-activated unit, use sysctl -w net.ipv4.ip_unprivileged_port_start=80 globally, or set the CAP_NET_BIND_SERVICE capability via setcap on rootlesskit. The sysctl approach is the least surprising on a dev box.

Docker-in-Docker (DinD) Nested Rootless

Running a rootless DinD build inside a rootless container requires both the outer and inner daemon to have enough subordinate IDs and cgroup delegation. It works (I have run full CI pipelines this way on GitLab runners) but the failure mode when anything is misconfigured is a cryptic newuidmap: uid range is out of bounds that does not point at the actual problem. Bake a pre-flight check into your CI image that runs dockerd-rootless-setuptool.sh check before builds.

CI Cost Impact of Rootless Docker

CI is where rootless Docker pays for itself fastest. A malicious dependency pulled during npm install, pip install, or docker build cannot escalate to root on the runner host. This matters because shared CI runners are a known supply-chain target.

Cost-wise, rootless CI is ~30 percent slower per job on kernel 5.11+ with pasta. Here is what that looks like on a 50-job-per-hour pipeline on GitLab self-hosted runners (AWS c7i.xlarge, $0.1785/h):

Metric	Rootful runners	Rootless runners
Jobs per hour per runner	50	38
Runners needed for 2000 jobs/hour	40	53
Monthly compute (730h)	$5,210	$6,903
Annualised delta	-	+$20,316/year
Expected annual cost of one runner compromise (assume 1 in 3 years)	~$150k-$2M	~$5k-$20k

Twenty thousand a year for two orders of magnitude reduction in blast radius is a trivial trade, which is why more CI providers are making rootless the default. GitLab runners support it natively; Buildkite's docker-login plugin handles it; GitHub Actions self-hosted runners need the dockerd-rootless-setuptool.sh bootstrap.

Decision Rubric

Situation	Use
Developer laptop, needs Docker Compose and BuildKit	Rootless Docker
CI runner, shared or cloud-hosted	Rootless Docker or rootless Podman
Production server running privileged workloads (GPU, raw devices)	Rootful with hardening (seccomp, userns-remap, AppArmor)
Docker Swarm cluster using overlay networks	Rootful (overlay network not supported in rootless)
High-throughput network workload (greater than 5 Gbps sustained)	Rootful (kernel networking) or pasta-based rootless with careful testing
Multi-tenant host where users must not see each other's containers	Rootless Docker or Podman per user
Single-node edge device with old kernel (less than 5.11)	Rootful (fuse-overlayfs penalty too high for rootless)
Regulated workload (PCI, HIPAA) on single host	Rootless Podman with SELinux

Frequently Asked Questions

Recommendation: Match the Mode to the Workload

There is no universal best choice. The right mode depends on the environment and threat model:

Development and CI: Use rootless Docker. The startup overhead is negligible for human-driven workflows, Docker Compose works and you eliminate an entire class of security risks during development. On CI runners, rootless mode prevents build jobs from escalating privileges even if a malicious dependency is pulled during the build.

Security-sensitive production: Use rootless Podman. The daemonless architecture reduces the attack surface to the absolute minimum. Native systemd integration means your containers are managed like any other system service. OCI compliance ensures portability. If a container escape occurs, the attacker lands in an unprivileged namespace with no path to root.

Rootful only when genuinely required: Privileged device access, Swarm overlay networks, or workloads where userspace networking overhead is unacceptable. When you must run rootful, always enable seccomp (the default profile is good), AppArmor or SELinux, drop all unnecessary capabilities, run container processes as non-root, and consider userns-remap for namespace-level isolation without the full rootless trade-offs.

The direction of the ecosystem is clear. Rootless is becoming the default. Docker, Podman, containerd, and Kubernetes are all investing in rootless-first architectures. Start adopting rootless now -- the compatibility gaps are small and shrinking, the performance penalty on modern kernels is minimal, and the security improvement is substantial.