Packer 1.8+ HTTP Provisioner: Latency When Concurrent Builds Run

Short answer

Yes — the latency you are seeing is consistent with all builders contending for the same default HTTP port (55555). Packer's HTTP file-serving component binds one listener per Packer process, not one shared daemon, so the real failure mode is a bind conflict or queuing on a single socket when several builds start together. The practical fix is to give each concurrent build its own http_port (or let Packer pick a free port). There is no documented connection pooling, request deduplication, or automatic per-build isolation in the core provisioner as of the 1.8 line — verify against your exact version, since port-allocation behavior has changed across releases.

What is confirmed vs. likely

Confirmed behavior: the HTTP server is a plain Go http.Server started inside each Packer run, bound to http_bind_address/http_port (defaulting to localhost:55555 in many templates). Two processes cannot bind the same TCP port simultaneously, so a second build starting while the first holds 55555 will either fail to bind or, depending on timing, retry — which shows up as stalls in the log before provisioning begins.

Likely, but verify: the latency spikes mid-build (not just at startup) suggest requests are being serialized through one listener or that a retry loop is running. Packer's documentation does not state whether the socket is shared or per-build, and there is no documented pooling or deduplication layer. Small local templates rule out transfer time, so contention at bind/accept time is the plausible explanation.

Mitigation: isolate the port per build

Set a unique port per builder, or use a port range so Packer picks a free one:

source "null" "a" {
  communicator = "none"
}

build {
  sources = ["source.null.a"]
  # Packer will choose a free port in this range
  http_port_min = 8600
  http_port_max = 8699
}

If your version only supports a fixed http_port, assign distinct values per build (55556, 55557, …) from your orchestration layer. Then verify:

1. Run two builds concurrently and check startup logs for "bind: address already in use" or retry messages.
2. Confirm each build reports a different bound port and that the latency spikes disappear.
3. If contention persists, check whether builds run in separate network namespaces/containers — identical ports are fine there.

Caveats

Port-binding semantics changed around the 1.8.x line and may differ in newer releases; check the changelog for your installed version (packer version). If you can share whether the spike appears at provisioner startup or mid-build, that would distinguish a bind conflict from accept-queue saturation and would change whether port isolation alone is sufficient.