Docker vs Kaniko: Building Images Without a Daemon
Docker builds images via a privileged daemon; Kaniko builds them from a Dockerfile inside a container with no daemon and no root, ideal for Kubernetes.
Docker is the standard image builder, but it needs a daemon and typically privileged access. Kaniko (Google) builds images from a Dockerfile entirely in userspace inside a container - no daemon, no Docker socket - which is why it is popular for building images in unprivileged Kubernetes-based CI.
| Docker | Kaniko | |
|---|---|---|
| Daemon required | Yes | No |
| Privilege | Often privileged | Unprivileged |
| Best environment | VMs, standard runners | Kubernetes, restricted runners |
| Local dev parity | High | Build-only |
| Caching | Layer cache + BuildKit | Layer cache to registry |
In CI
On standard VM runners with a Docker daemon, Docker (with BuildKit) is simplest and fastest. Kaniko earns its place when you build inside Kubernetes or on runners that forbid a Docker socket or privileged mode - it builds and pushes from a Dockerfile without any daemon. Kaniko caching works via a registry cache rather than a local daemon cache.
Speed it up
Push and reuse a layer cache in your registry so rebuilds skip unchanged stages. Both run on CI runners; faster managed runners shorten the image build itself.
The verdict
Standard runners with a daemon: Docker with BuildKit. Daemonless, unprivileged, or in-Kubernetes builds: Kaniko. Choose by your runner's security and isolation constraints.