2.1.2.3 Local Daemon Access
A focused guide to Local Daemon Access, connecting core concepts with practical Docker and container operations.
Local daemon access is the default mode of Docker usage, where the client and daemon both run on the same machine and communicate over a local Unix socket, which is how most individual developers interact with Docker day to day.
The Default Local Setup
When Docker is installed on a machine, the daemon starts as a local service and the CLI, by default, talks to it through a local socket rather than a network address, requiring no additional configuration to start using it.
docker ps
This command works immediately after installation because the client's default configuration already points at the local daemon's socket.
Socket-Based Permissions
Access to the local daemon is controlled by filesystem permissions on its Unix socket, typically restricted to the root user and members of a dedicated docker group, meaning any user in that group can issue commands with the same level of control as root, since the daemon itself runs with elevated privileges.
sudo usermod -aG docker $USER
Adding a user to the docker group is a common setup step, but it is worth treating with the same caution as granting that user root access, given what daemon control implies.
Why Local Access Is the Common Case
For development, testing, and single-host deployments, there is no need to expose the daemon over the network at all — every interaction happens on the same machine, which is both the simplest and the most secure configuration, since the daemon's API is never reachable from outside that machine.
docker context ls
This typically shows a single default context pointing at the local daemon, confirming there is no remote daemon configuration involved.
Verifying Local Daemon Health
Because the daemon is a local service, its health can be checked the same way any other system service would be.
systemctl status docker
docker info
When Local Access Is Not Enough
Local daemon access stops being sufficient once a workflow needs to manage containers on a different machine — at that point, either a remote connection to that machine's daemon, or an orchestrator that abstracts away which specific machine a container runs on, becomes necessary.