Non-root containers and rootless Docker solve different security problems

Setting USER in a container image and running Docker in rootless mode are related but different controls. The first changes the application’s user inside a container. The second runs the Docker daemon and its containers without host root privileges, using user namespaces. A deployment can use one approach without using the other.

Identify the boundary you are changing

A non-root application reduces the privileges available to that process inside its container. It does not turn a conventional rootful Docker daemon into a rootless daemon. Conversely, rootless Docker changes the host privilege model, but the application still needs sensible file permissions, a restricted filesystem and only the capabilities its workload requires.

Start by documenting how the current host manages Docker, where persistent data lives and which service starts containers at boot. On an existing production machine, switching the daemon is an operational migration. Do not disable a working system service before you understand how the replacement will preserve data and recover after restart.

Verify prerequisites and the selected daemon

Docker’s documentation lists the required user-namespace tooling and subordinate user and group ID configuration. The setup tool checks prerequisites and creates a user service and a rootless context. Review its output rather than assuming that installing an additional package completed the transition.

docker context show
docker info
systemctl --user status docker

These commands inspect the selected context and service. In docker info, check the server-side security options for the rootless entry. A client can still point to a different daemon through its context or environment, so the existence of a user service alone does not establish where your containers run.

Rehearse the operational differences

Test published ports, volume ownership, storage behavior and resource controls with the exact application. Verify that a non-root process can read its configuration and write only to the intended persistent or temporary directories. Plan how the user service starts without an interactive login; Docker documents the relevant systemd lingering arrangement.

Keep the original data and a rollback procedure until the new arrangement has passed application and restart checks. Avoid exposing a daemon socket to a web container simply to make administration convenient. The result should be a clearly documented privilege boundary and a deployment that still behaves correctly, rather than a security label that hides an untested migration.