Choosing a Nomad Update Strategy: Rolling vs. Canary vs. Blue/Green

The decision: how should Nomad replace your allocations?

Every time you submit a new version of a Nomad service job, the scheduler has to decide how to swap old allocations for new ones. The update block in your job spec controls this, and picking the wrong strategy is a common source of outages: rolling updates can push a broken version everywhere before anyone notices, while blue/green can fail to schedule entirely on a capacity-constrained cluster.

The useful takeaway: rolling is the safe default for stateless services, canary is the right choice when you want a human (or automated test) to approve a small live sample first, and blue/green is for workloads where instant rollback justifies double capacity. All three depend on health checks being configured correctly — the strategy only gates on what you tell Nomad to check.

This guide assumes Nomad 1.x with service-type jobs. Exact parameter defaults vary by version, so confirm against the docs for your cluster's release.

Comparing the three supported strategies

Trade-offs that actually matter

Rolling: simple, but no smoke test

Rolling updates are the default and the least operationally demanding. They work well when your service is stateless, tolerant of mixed versions running side by side, and when a bad deploy is cheap to fix by rolling forward. The weakness is blast radius: with no promotion gate, a version that passes health checks but misbehaves under real traffic will propagate to the whole job. If that risk is unacceptable, you need a gate.

Canary: limited blast radius with a promotion decision

Setting canary = N tells Nomad to place N new-version allocations first and pause the deployment in a running state awaiting nomad deployment promote. This lets you smoke-test against live traffic — or run automated checks against the canary allocs — before committing. auto_promote = true removes the human step, at which point canary becomes "rolling with a staged first batch," which is still useful because auto_revert can then roll back a failing deploy automatically.

Blue/green: instant rollback, at a price

Blue/green keeps the entire old allocation set running until you promote. Rollback is effectively a routing decision, which makes it the best fit for services where a bad deploy must be undone in seconds. The hard constraint is capacity: your cluster must fit both versions at once. On a cluster already at 60% utilization, a job using half the remaining headroom may simply fail to place its green set. Check free capacity with nomad node status before committing to this strategy.

The prerequisite everyone skips: health checks

None of these strategies protect you if Nomad can't tell healthy from broken. Progression is gated by service checks plus the update block's min_healthy_time and healthy_deadline. Without registered checks (via Consul or Nomad native service discovery — the configuration differs between the two), Nomad may treat allocations as healthy the moment they start. Verify checks exist and actually fail when the app is broken before relying on any strategy.

Note also that canary and blue/green apply to service jobs only — system and batch jobs don't support them.

Concrete example: a canary deployment with automatic rollback

The following job spec runs a web service with a two-allocation canary, manual promotion, and automatic revert if the new version fails its health check. Run nomad job plan (any operator with job-submit permissions) before applying to confirm the update block parses and shows the intended strategy.

job "web" {
  datacenters = ["dc1"]
  type        = "service"

  update {
    max_parallel     = 2
    canary           = 2
    min_healthy_time = "30s"
    healthy_deadline = "5m"
    auto_revert      = true
    auto_promote     = false
  }

  group "web" {
    count = 6

    network {
      port "http" { to = 8080 }
    }

    service {
      name     = "web"
      port     = "http"
      provider = "nomad"

      check {
        type     = "http"
        path     = "/healthz"
        interval = "10s"
        timeout  = "2s"
      }
    }

    task "web" {
      driver = "docker"
      config {
        image = "registry.example.com/web:1.4.0"
        ports = ["http"]
      }
      resources {
        cpu    = 300
        memory = 256
      }
    }
  }
}

Submit with nomad job run web.nomad.hcl. During the rollout, watch the deployment:

nomad deployment status <deployment-id>

You should see the two canary allocations created and the deployment waiting for promotion. Promote with nomad deployment promote <deployment-id> once the canaries look good.

Validating the strategy before you trust it

Don't wait for a real incident to learn whether your gating works. A practical validation sequence:

1. Plan first. nomad job plan web.nomad.hcl confirms the update block is accepted and shows the diff Nomad intends to apply.
2. Observe the pause. Deploy a trivial version bump and confirm via nomad deployment status that the deployment waits for promotion after the canaries go healthy.
3. Break the health check deliberately. Deploy a version whose /healthz fails. Confirm the deployment never becomes promotable, then run nomad deployment fail <deployment-id> and verify the previous job version is restored. With auto_revert = true, a failed deployment should revert on its own within healthy_deadline.
4. For blue/green, check capacity first. Confirm via nomad node status that your cluster can place a full second copy of the job; otherwise the green set will never schedule and the deployment will stall.

Limitations

Parameter names and defaults in the update block have shifted across Nomad releases — validate against your version's documentation. Health-check behavior differs between Consul-registered and Nomad-native services, so test the failure path on your actual setup. Finally, promotion gating only helps if someone (or some automation) actually evaluates the canary; a canary that gets promoted blindly is just a slower rolling update.