[aayushshah15]

The setup step waits for the Docker daemon on its critical path. Its first Docker call is docker version in the "Docker info" group, and that call blocks until dockerd has finished starting. On our own step-duration-regression run on main (run 39735830544), docker version took 0.96 s to print anything. Buildx setup and the Blacksmith builder start then ran another 0.77 s, and neither needs the daemon.

This starts that wait in the background as soon as the step begins, and prints the Docker info group once buildx and the builder are set up:

let dockerWarmup: Promise<unknown> | null = null;
if (process.env.BLACKSMITH_DOCKER_WARMUP === "false") {
  await printDockerInfo();
} else {
  dockerWarmup = execAsync("docker version").catch(() => undefined);
}
try {
  // ... Setup buildx, Starting Blacksmith builder ...
} finally {
  if (dockerWarmup) {
    await dockerWarmup;
    await printDockerInfo();
  }
}

The Docker info group has the same contents and now comes right after "Starting Blacksmith builder" in the log. It's printed in a finally, so it still appears when the builder start throws (nofallback). The daemon starts at the same point in the step as before; the step just doesn't wait for it before moving on.

It also polls for the buildkitd PID every 50 ms instead of 300 ms. The PID usually shows up within a few tens of ms, so one missed pgrep costs a full 300 ms today.

Estimated impact. Across ~23k setup runs per hour in production (2026-10-21, 12:00-13:00 UTC), "Docker info" averaged 1.14 s, the builder start 1.4 s, and the buildkitd PID wait had p50 0.32 s. Hiding most of the daemon start behind the builder start and trimming the PID wait saves about 0.8-1.1 s per run, or ~5-7 runner-hours per hour: ~0.02-0.025% of all whole-job time (denominator: ~28,500 whole-job hours, same window). These fleet numbers are modeled.

Measured. On the step-duration-regression job, the setup step (from Run ./ to the next step) took 2.12 s, 2.04 s and 2.34 s on the last three scheduled runs on main (39735830544, 39557284551, 39382020583) and 1.13 s on this PR (39875460145). The Docker info group dropped from 1.09 s to 0.15 s, because the daemon was already up by the time it ran. That's one run, so treat it as a sanity check, not a distribution.

Edge cases:

• Docker missing or the daemon fails to start: the warm-up swallows its error, and the Docker info group prints the same message it does today.
• Daemon hangs: the step hangs at the same total point as before, since the old code also waited on docker version with no timeout.
• Fallback to the local builder: Docker info is printed before the fallback runs, as before.
• Ordering: nothing in buildx setup or the builder start talks to dockerd, writes its config or touches its socket. They only use the buildx CLI plugin, the sticky disk agent and buildkitd.
• CPU: dockerd and buildkitd now start concurrently. On a 2 vCPU runner that can slow each a little, but they ran back to back before, so the overlapped total should stay under the old serial time.
• PID polling: at most ~200 pgrep calls in the 10 s timeout instead of ~33, and in practice one or two.

BLACKSMITH_DOCKER_WARMUP=false restores the old order. dist/ is rebuilt in this PR.

---

^{Need help on this PR? Tag @codesmith-bot with what you need.}

---

Daemon start overlaps builder start

Before, buildx and the builder start waited ~1.3 s for docker version; after, they ran while dockerd started, Docker info printed after the builder with identical contents, and the step averaged ~0.38 s faster over 5 runs each.

_Merge-base

_{This PR fe4fcc13}

Also checked · 4 match

buildkitd PID poll at 50 ms
Docker info on nofallback failure
Daemon unavailable message unchanged
BLACKSMITH_DOCKER_WARMUP=false

_{Proof on fe4fcc13}

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is enabled. (Staging)}

[devin-ai-integration]

✅ Devin Review: No Issues Found

Devin Review analyzed this PR and found no bugs or issues to report.