Nomad bin-packs by default. If no one wrote a spread stanza in the job specification, the cluster has been making the scheduling decision for you. The scheduler does not know what you are paying for. You do.

The choice between spreading work across many nodes and packing it onto a few is not a technical preference. It is a financial and operational calculation based on the capacity contract and the workload’s failure mode. Getting it wrong means paying for idle capacity on metered infrastructure, or starving live workloads of burst capacity on owned hardware.

The Capacity Contract

On owned hardware or reserved instances, the hardware is a sunk cost. Spreading tasks reduces CPU contention, limits thermal throttling, and gives every job access to unused RAM and disk I/O. Idle capacity is free throughput. A central platform team that runs continuous integration on reserved instances but leaves the scheduler set to bin-pack will watch eight nodes sit at 95 percent CPU while twenty-four nodes sit idle but paid for. Spread would have provided free throughput.

On metered cloud infrastructure, idle capacity is a continuous charge. Bin-packing is the only way to completely empty a node so the autoscaler can terminate it. A build farm on owned hardware and a bake farm on spot capacity are not the same workload, even if they run the same binary. The invoice dictates the algorithm.

The Autoscaler and the Drain Story

Autoscalers scale node pools based on allocation count, but they only terminate nodes that are completely empty. If you spread work across a fleet of elastic instances, every node sits at 15 percent utilization. Because no node is entirely empty, the autoscaler never shuts them down. The monthly bill matches on-demand pricing. The spread policy is the reason.

Bin-packing creates empty nodes, but only if you have a drain story. If your autoscaler cannot detach persistent volumes quickly, or if a minimum node count keeps the fleet alive, packing just crams work onto fewer nodes while you pay for the whole fleet. The drain policy is the second half of the bin-packing strategy. Without it, you are just cramming.

Workload Profiles and the Unit of Damage

The right placement rule depends on what happens when a node fails or gets reclaimed. The unit of damage differs by workload.

CI and Build Farms

Continuous integration and build jobs are short, idempotent, and resumable. A reclaimed spot node is an inconvenience. Bin-pack these onto spot instances. The scheduler concentrates allocations, the autoscaler sees fewer busy nodes, and the fleet scales down.

Watch out for I/O starvation. Schedulers pack based on declared CPU and memory requests. They rarely account for disk IOPS or network bandwidth. Cramming four heavy shader compiles onto one machine because the CPU and RAM technically fit will cause all four to stall waiting for disk queues. A compile that usually takes 15 minutes will take 45.

Asset Bakes

Lighting builds and texture compression are long, I/O heavy, and often uncheckpointed. A bake that restarts from zero after a spot reclamation makes the cost savings an illusion. If the tool checkpoints, you can pack it and absorb the reclaim. If it does not, you must spread it.

Spreading also protects against the noisy neighbor effect. Scheduler isolation is cgroups-based, not a hard partition. Two memory-heavy bakes on one node risk the out-of-memory killer if the reservation is wrong. On a GPU pool for lighting bakes, where nodes are reserved because GPU spot capacity is unreliable, spreading the jobs across nodes avoids PCIe contention and limits the blast radius of a single GPU failure.

Live Game Servers

Match servers need predictable execution time to maintain a stable tick rate. Tightly packing dedicated servers leaves no burst capacity. If one server instance handles a massive physics event or a 100-player collision, it steals cycles from the other instances on the node, causing rubber-banding across entirely different matches. A node at 95 percent utilization is a victory for the finance department and a disaster for the physics engine.

For live operations, spread game server instances across failure domains like availability zones or racks. Pack new sessions onto fewer instances during off-peak hours so you can drain and release the empty hosts. The spread attribute should be the failure domain, not the individual node.

The Mechanics of Placement

When you write the policy, you are balancing fragmentation against tail latency.

Spread reduces contention but increases the tail. The critical path is set by the slowest node, not the average node. If you spread a batch job across 40 nodes, the slowest node in the fleet dictates the completion time. The job takes three times longer than if it had been packed onto 10 fast nodes. Spread also causes fragmentation. It leaves a little free capacity on many nodes, meaning a large job may not fit anywhere. Bin-pack leaves whole nodes free.

You can layer these policies. You can spread across topology, like availability zones, and bin-pack within them. This is the standard shape for spot capacity, where failures correlate by zone. Use max_parallel to cap how many allocations from a spread block land on a node at once. Without it, a burst of placements can hit the same node before the scheduler’s state updates.

Decision Criteria

Use these conditions to determine the placement policy for a given job or node pool.

Favor spreading when:

  • The capacity is already paid for, such as owned hardware, reserved instances, or flat monthly leases.
  • Jobs compete heavily for shared node resources like disk I/O, network bandwidth, or PCIe lanes.
  • Lost work is expensive to repeat, such as long, uncheckpointed asset bakes.
  • Live workloads require burst headroom for physics calculations or garbage collection.
  • You need to minimize the blast radius of a single hardware failure.

Favor bin-packing when:

  • The infrastructure is metered and nodes can actually be released by an autoscaler.
  • Jobs are short, idempotent, or checkpoint frequently.
  • Resource requests are highly accurate and predictable, preventing the out-of-memory killer from triggering.
  • You are managing off-peak game server sessions and need to drain hosts to reduce the fleet size.

Check these conditions before changing a policy:

  • Scale-down eligibility: Will an empty node actually disappear, or is it held open by a minimum node count, a persistent volume, or a slow scale-down policy?
  • Restart behavior: Does the tool resume from the last completed chunk, or start over from zero?
  • Bottlenecks: Is the workload bound by CPU and memory, which the scheduler sees, or disk and network, which it ignores?
  • Drain time: How long does it take to cordon a node, reschedule its tasks, and pull images on the replacement capacity?

The scheduler places the allocations. The capacity contract determines whether that placement saves money or wastes it.