If you need to start the Docker daemon, you are usually here for one of two reasons. Either you just ran a docker command and got hit with Cannot connect to the Docker daemon, or you are trying to understand what this background service is and why the CLI cannot work without it. Both problems have the same root. The docker command you type is only a client. The real work happens in a separate process called dockerd, and if that process is not running, nothing else does.
This guide explains what the Docker daemon is, how to start it correctly on Linux, macOS, and Windows, and how to diagnose the classic connection error step by step. It also covers the honest part most tutorials skip. In production you often do not start or manage a Docker daemon at all.
The short answer: To start the Docker daemon on Linux, run sudo systemctl start docker, then sudo systemctl enable docker so it launches on boot. On macOS and Windows, open Docker Desktop, which runs the daemon inside a virtual machine. Confirm it is running with docker info. The classic Cannot connect error almost always means the daemon is stopped or your user lacks socket access.
What the Docker daemon actually is
Docker is split into two parts that people often confuse. The command line tool (docker) is a thin client. It takes your input, turns it into an API request, and sends it somewhere. The daemon (dockerd) is the service that receives those requests and does the heavy lifting.
The Docker daemon (dockerd) is a long-running background process that builds images, creates and runs containers, and manages networks and volumes. The docker command line tool is a separate client that sends requests to the daemon over a local socket or a network endpoint.
By default the client and daemon talk over a Unix socket at /var/run/docker.sock. When you run docker ps, the client opens that socket and asks the daemon for a list of containers. If the socket file is missing, if the daemon is stopped, or if your user cannot read the socket, the request fails and you see the connection error. Understanding this split is the whole game. Every fix below is about making sure the daemon is alive and that your client can reach it.
This design is also why building an image feels the way it does. When you run a build, the client packages your context and hands it to the daemon, which executes each step. If you want a deeper walkthrough of that build path, read our guide to building Docker images from a Dockerfile.
The classic "Cannot connect to the Docker daemon" error
The full message looks like this:
Cannot connect to the Docker daemon at unix:///var/run/docker.sock.
Is the docker daemon running?
That last question is a genuine hint, not just politeness. There are four common causes, in rough order of frequency.
First, the daemon is simply not started. This is the default on a fresh Linux server or after a reboot where the service was never enabled. Second, your user is not in the docker group, so you can reach the socket file but not read it, which surfaces as a permission error. Third, on macOS or Windows, Docker Desktop is installed but not launched, so no daemon exists yet. Fourth, the socket path is wrong because you set DOCKER_HOST to a stale value or a remote endpoint that is no longer reachable.
Work through them in that order. Ninety percent of the time the fix is starting the service or fixing group membership, both of which take one command.
How to start the Docker daemon on Linux
Most modern Linux distributions manage Docker with systemd. The daemon runs as a system service, so you control it the same way you control any other service.
To start the Docker daemon right now:
sudo systemctl start dockerTo make it start automatically on every boot, so you never hit the error again after a restart:
sudo systemctl enable dockerTo do both in one command:
sudo systemctl enable --now dockerTo check what is actually happening, ask systemd for the status:
systemctl status dockerA healthy daemon reports active (running). If it says inactive (dead), it is stopped and the start command will fix it. If it says failed, the daemon tried to start and crashed, usually because of a bad /etc/docker/daemon.json config file or a storage driver problem. In that case, read the logs with journalctl -u docker --no-pager -n 50 to see the real reason. The official dockerd reference on docs.docker.com documents every flag and config key the daemon accepts, which is the right place to check when a config option is rejected.
Fixing the permission denied variant
If the daemon is running but you still see a permission error, your user is not allowed to read the socket. The socket is owned by the docker group, so add yourself to it:
sudo usermod -aG docker $USERGroup membership is only applied at login, so log out and back in, or run newgrp docker in your current shell. After that, docker ps works without sudo. Be aware that membership in the docker group is equivalent to root access on the host, because the daemon runs as root and will do whatever the socket tells it. On a shared machine that matters.
The rootless alternative on Linux
If handing out root-equivalent access is a concern, Docker supports a rootless mode where the daemon itself runs as an unprivileged user.
Rootless mode runs the entire Docker daemon and its containers inside your own user account, without root privileges. It lowers the impact of a container breakout because a compromised process is confined to your unprivileged user rather than the host root account.
In rootless mode the daemon is not a system service. It is a user service managed by your own systemd session, so the commands change:
systemctl --user start docker
systemctl --user enable dockerYou also need to point the client at the rootless socket, which lives under your user runtime directory rather than /var/run. The setup script that ships with Docker handles the environment variables for you. The tradeoffs, requirements, and known limitations are documented in the official Docker rootless mode guide. Rootless is a strong choice for developer laptops and multi-tenant build hosts, though a few features (certain network modes, some cgroup controls) behave differently.
Starting the daemon on macOS and Windows
There is no systemctl on macOS or Windows, and there is no native Linux daemon either. Docker containers are Linux processes, so on these operating systems the daemon runs inside a lightweight virtual machine that Docker Desktop manages for you.
That means the way you start the Docker daemon is simply to start Docker Desktop. Open the application from Launchpad, the Start menu, or your applications folder. The whale icon in the menu bar or system tray tells you the state. When it stops animating and settles, the VM is up, dockerd is running inside it, and your docker CLI on the host is wired to that daemon automatically.
If commands fail on these platforms, the checklist is short. Confirm Docker Desktop is actually launched and not just installed. Wait for the icon to report that the engine is running, because the CLI will fail during the few seconds the VM is still booting. On Windows, make sure the WSL 2 backend or Hyper-V is enabled, since Docker Desktop depends on one of them to host the VM. Quitting and reopening Docker Desktop restarts the daemon cleanly and clears most transient states.
Verify the daemon is running
Two commands tell you everything you need. Use them before assuming the daemon is broken.
docker versionThis prints two blocks, a Client section and a Server section. The client block always appears because it is just the local binary. The server block only appears if the client successfully reached the daemon. If the Server section is missing or replaced by an error, the client cannot connect, and you are back to the four causes above.
docker infoThis goes a step further and asks the daemon to describe itself: how many containers and images it holds, which storage and logging drivers it uses, and how much memory it sees. A full docker info output is proof that the daemon is running and reachable. If it errors, the daemon is down or the socket is wrong.
| Environment | Where dockerd runs | How to start it | Do you manage it? |
|---|---|---|---|
| Linux (systemd) | Directly on the host as root | sudo systemctl start docker | Yes, you patch and restart it |
| Linux (rootless) | Inside your own user account | systemctl --user start docker | Yes, per user |
| macOS / Windows | Inside a Docker Desktop VM | Launch Docker Desktop | Desktop manages the VM, you keep it updated |
| Managed platform (PaaS) | On the platform's build and run infrastructure | Nothing to start | No, there is no daemon you touch |
The production reality: often there is no daemon to start
Everything above matters on a laptop or a single server you administer yourself. The picture changes in production. When you self-host containers on your own machines, you own the daemon completely. You start it, patch it against CVEs, watch it for crashes, and keep it running through reboots. That is real operational work, and if you go that route our guide to self-hosting apps with Docker covers the daemon lifecycle you sign up for.
A platform as a service removes that layer entirely. Instead of you running dockerd and babysitting it, the platform runs the build and the container on infrastructure you never log into.
A platform as a service (PaaS) runs your application without exposing the servers underneath. You provide code or a Dockerfile, the platform builds the image and runs the container, and it handles the daemon, the operating system, and the networking so you do not operate any of it.
On Out Plane this is the normal path. You push code or a Dockerfile, and the platform builds an image and runs your app for you. There is no dockerd for you to start, no socket permissions to configure, no service to enable on boot, and no daemon to patch when a security advisory lands. Out Plane also runs a managed PostgreSQL database next to your app on a private network, with automated backups and point in time recovery, so a stateful application works without you provisioning anything by hand. HTTPS is automatic, and your app comes up on a public URL like {name}-{port}-{teamSlug}.outplane.app.
This is not a claim that the Docker daemon disappears from the universe. It runs on the platform's infrastructure, out of your sight, the same way the Desktop VM hides it on your laptop. The point is that the entire class of "is the daemon running" problems stops being yours. If you want the fuller comparison of running your own container host versus a managed one, see our breakdown of Docker hosting options and our explainer on what a PaaS is.
Frequently Asked Questions
How do I start the Docker daemon on Linux?
On a systemd based distribution, run sudo systemctl start docker to start it immediately, then sudo systemctl enable docker so it launches on every boot. Combine them with sudo systemctl enable --now docker. Check the result with systemctl status docker, which should report active (running) when the daemon is healthy.
What does "Cannot connect to the Docker daemon" mean?
It means your docker client tried to reach the daemon over the socket at /var/run/docker.sock and failed. The daemon is the background process that does the real work, and the client cannot function without it. The usual causes are a stopped daemon, missing socket permissions, or Docker Desktop not being launched.
Why do I get permission denied on the Docker socket?
The socket is owned by the docker group, so a user outside that group cannot read it even when the daemon runs. Add yourself with sudo usermod -aG docker $USER, then log out and back in for the change to apply. Note that this grants root-equivalent access to the host, so use it deliberately.
How do I start the Docker daemon on macOS or Windows?
You start it by launching Docker Desktop. On these operating systems the daemon runs inside a virtual machine that Desktop manages, because containers are Linux processes. Open the app, wait for the whale icon to stop animating, and the daemon is ready. There is no systemctl command to run on either platform.
How do I check if the Docker daemon is running?
Run docker info. If it prints the daemon's details, containers, images, storage driver, and memory, the daemon is running and reachable. You can also run docker version and look for a Server block. If that block is missing or shows an error, the client could not connect and the daemon is likely down.
Can I run the Docker daemon without root?
Yes, through rootless mode, which runs the daemon and its containers inside your own unprivileged user account. You start it with systemctl --user start docker rather than the system service. It reduces the blast radius of a container breakout, with some feature differences around networking and cgroups documented in the official rootless mode guide.
Does a managed platform need me to start a Docker daemon?
No. On a platform as a service the build and run infrastructure hosts the daemon, and you never interact with it. On Out Plane you push code or a Dockerfile, and the platform builds the image and runs the container. There is nothing to start, no socket to configure, and no daemon to patch or keep alive.
Why won't the Docker daemon start after a reboot?
Usually because the service was never enabled to start on boot. Run sudo systemctl enable docker once, and it will launch automatically after every restart. If it starts and then fails, check journalctl -u docker for the reason, which is often a malformed /etc/docker/daemon.json file or a storage driver conflict.
Conclusion
To start the Docker daemon, match the command to your environment. On Linux use sudo systemctl start docker plus enable for persistence, or systemctl --user start docker for rootless mode. On macOS and Windows, launch Docker Desktop and let it run the daemon inside its VM. When the classic Cannot connect error appears, verify with docker info, then check whether the daemon is stopped, your user is outside the docker group, or Desktop simply is not open.
The deeper lesson is that all of this maintenance belongs to whoever owns the daemon. In production you can hand that off. Out Plane builds from your Dockerfile and runs the result, so there is no dockerd to start, patch, or keep alive. Create your first app in the console at https://console.outplane.com, and see the free Hobby tier and pay-as-you-go pricing on /pricing.