One template with parallel builders or sequential packer builds: which for a latency-sensitive CI runner?

Packer build concurrency vs sequential latency on single-host CI runners

The trade-off

For a latency‑sensitive CI runner constrained to a single host with limited CPU cores and disk throughput, sequential Packer builds generally keep per‑build latency predictable, while one template with parallel builders reduces total wall‑clock time when the pipeline truly needs many images in parallel and the host disk can sustain the I/O.

1. Likely explanation – concurrent builds in one template share PACKER_CACHE_DIR; when multiple plugins download or extract the same base image, disk I/O contends, adding latency beyond plugin startup costs. On a CPU‑constrained host, the scheduler also introduces variable wait time as parallelism approaches core count, an effect absent in sequential runs.
2. Confirmed fact – Packer 1.10+ does not serialize base‑image downloads across concurrent builds. The OS filesystem and network stack handle retries, so repeated cache misses under concurrency can inflate total wall‑clock time even when a cache directory exists. The -parallel-builds flag can serialize N builds at a time, reducing cache contention but increasing pipeline latency if many images are needed.

Verification step – run two builds of the same image, one with -parallel-builds=3 and one sequential, measuring per‑build wall‑clock and CPU/disk usage via pidstat or iotop; compare latency gaps to host resource saturation. Inspect PACKER_CACHE_DIR timestamps during concurrent builds to detect repeated downloads versus cache hits.

To finalize the recommendation, I need one diagnostic detail: is the CI runner's primary storage SSD or HDD, and what is its sustained IOPS? On a high‑IOPS SSD, parallel builds may contend less and total wall‑clock improves. On a low‑IOPS or shared disk, sequential builds from separate templates are safer for per‑build latency.