engineering
Docker architecture for CI engineers
Daemon, containerd, BuildKit and the snapshotter — what each one does, and which one is making your build slow.
Tomás Rivera · Performance engineering · 2026-04-21 · 10 min read
Most Docker performance advice is a list of Dockerfile tricks. It works better if you know which component each trick is actually addressing.
The pieces
| Component | Responsibility | Where it shows up in CI |
|---|---|---|
| dockerd | API, networking, orchestration of the rest | Daemon startup cost on a cold runner |
| containerd | Container lifecycle and image management | Image pull and unpack time |
| snapshotter | Filesystem layers on disk | Layer extraction — heavily disk-bound |
| BuildKit | Executes the build graph | Everything about build parallelism and caching |
| runc | Actually starts the process | Rarely the bottleneck |
Which one is slow
- Slow before any step runs → daemon start and image pull; fix with a warm runner and a pull-through cache
- Slow during COPY and RUN with high I/O wait → the snapshotter on network-attached disk; fix with local NVMe
- Rebuilding layers that did not change → BuildKit cache; fix instruction order and cache backend
- arm64 catastrophically slow → QEMU, not Docker; fix with native runners
Your next build could be twice as fast, at half the price
Start free. Migrating away is the same one line, and we publish that diff too.
Related
CI when your teammates are agentsAI coding agents push far more often than humans. Here is how that changes pipeline design and cost control.Why we publish instructions for leavingEvery migration page on this site includes the diff to migrate back off us. Here is the reasoning.What we learned running a million CI jobsQueue time, cache behaviour, right-sizing and the failure modes that only appear at scale.Stop retrying flaky testsAutomatic retries convert a real bug into an intermittent one, and train your team to distrust every failure.