Nomad: What If You Don't Need Kubernetes?

There’s a reflex in this industry that nobody questions anymore. You have a few services to run. Maybe a handful of containers, a couple of background workers, a cron job or two. And the very first architecture decision — before anyone has asked what the workload actually needs — is “so which Kubernetes are we using?”

Kubernetes is the default answer to a question most teams never bothered to ask. Nomad is the question. Specifically: do you actually need all of that?

I’ve run Kubernetes in production for years — RKE2 on bare metal, K3s in the home lab, EKS when someone else was paying the control-plane bill. I like Kubernetes. I’m not here to tell you it’s bad. I’m here to tell you that HashiCorp’s Nomad is the tool I reach for when the workload doesn’t justify the Kubernetes tax, and that more people should at least look at it before they sign up for the full machine.

What Nomad actually is

Nomad is a workload orchestrator that ships as a single Go binary. That’s not marketing shorthand — it’s the literal deployment story. One binary, nomad, runs as a server agent on your control nodes and as a client agent on your workers. There is no separate scheduler process, no separate API server, no separate controller manager, no etcd you have to babysit. It’s one file.

What it schedules is broader than Kubernetes, too. Nomad runs Docker containers, sure — but it also runs raw binaries, Java applications, QEMU virtual machines, and a long tail of community runtimes including containerd, Firecracker microVMs, LXC and WebAssembly. Kubernetes assumes the thing you’re running is a container in a pod. Nomad assumes the thing you’re running is a task, and a task can be almost anything you can put on a Linux box.

The deliberate part — the part that defines the whole product — is what it doesn’t include. There is no CNI plugin you must choose, no CSI storage layer you must wire up, no ingress controller baked in, no service mesh assumed. Nomad does scheduling. It leaves the rest of the platform to you, or to its HashiCorp siblings. Where Kubernetes is a platform that wants to own the whole stack, Nomad is a scheduler that minds its own business.

The architecture, in one paragraph

Nomad is a single Go binary running in one of two roles. Server agents hold cluster state and make scheduling decisions; they form a small consensus group — three or five of them — using Raft for the replicated state log, exactly like etcd does for Kubernetes, except it’s built in. Client agents run on every worker node, register their resources, and execute tasks through task drivers — docker, exec, raw_exec, java and qemu ship in the box; podman, containerd, Firecracker and others are community drivers you drop in. Membership and health — which nodes exist, which are alive — is handled by Serf, a gossip protocol, so the cluster discovers and heals itself without a central registry. You describe what to run in HCL, the same configuration language as Terraform, in a “job” spec. For service discovery and a real service mesh you add Consul; for secrets you add Vault — both HashiCorp, both optional, both integrate without glue code. That’s the entire mental model, and you can hold all of it in your head at once. That last sentence is not something I can honestly say about Kubernetes.

A job file looks like this — readable on the first pass, which is more than YAML usually manages:

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

  group "frontend" {
    count = 3

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

    task "server" {
      driver = "docker"

      config {
        image = "registry.internal/web:1.4.2"
        ports = ["http"]
      }

      resources {
        cpu    = 500
        memory = 256
      }
    }
  }
}

nomad job run web.nomad.hcl, and three instances are scheduled across your clients. No Deployment plus Service plus Ingress plus ConfigMap spread across four files. One job, one command.

Where Nomad sits in 2026

The honest context matters here, because the corporate story around HashiCorp has gotten complicated and you deserve the real version.

IBM owns HashiCorp now. The acquisition was announced in 2024 and closed in February 2025 for around $6.4 billion. Nomad, Terraform, Vault, Consul and the rest are IBM products today. So far Nomad has kept shipping — but “so far” is doing real work in that sentence, and I’ll come back to it.

The version story changed. Nomad spent years on tidy semantic versioning, and the line many shops still run is 1.10.x, which is the last Long-Term Support release in the old scheme — the conservative, boring, supported-for-ages choice. From 2.0 onward Nomad has moved to IBM’s Version-Modification-Fix lifecycle model, so the current line reads like an IBM product now, not a HashiCorp one. 1.10 added dynamic host volumes for stateful workloads and finished the move to Workload Identity for Consul and Vault integration (the old token workflow is gone — plan for it if you’re upgrading).

The licence is the part people get wrong. Nomad is not open source in the OSI sense anymore. In August 2023 HashiCorp relicensed everything — Nomad included — from MPL-2.0 to the Business Source License (BUSL) 1.1. It’s “source available”: free to read, free to run in production, free for basically every normal use. The one thing it forbids is offering Nomad as a competing managed service, and each release converts to a true open-source licence four years after it ships. For you and me running clusters, nothing practical changed. But if you’ve been calling Nomad “open source,” correct yourself — it’s the same BUSL story that drove the Terraform/OpenTofu split, and Nomad has no high-profile fork riding to the rescue.

Nomad vs Kubernetes vs Docker Swarm

The table compresses the real story into one line: Swarm is the past, Kubernetes is the maximum, and Nomad is the sane middle that almost nobody evaluates. Swarm still technically works and is gloriously simple, but Docker/Mirantis put it in maintenance long ago and nobody is betting new infrastructure on it. Kubernetes is the right answer when you genuinely need everything it offers. Nomad is the answer when you need scheduling and you’d rather not adopt an entire ecosystem to get it.

Where Nomad shines

• The single binary is not a gimmick. One file to install, one file to upgrade, one process to reason about. No control-plane distribution to assemble, no CNI/CSI/ingress trifecta to choose and maintain. The day-two operational surface is a fraction of a Kubernetes cluster’s, and day-two is where infrastructure actually lives.
• It runs things that aren’t containers. This is the feature Kubernetes people forget exists. A legacy Java app, a raw Go binary, a QEMU VM, a batch process — Nomad schedules all of them with the same job spec. You don’t have to containerise something just to orchestrate it.
• HCL beats YAML. I’ve written a lot of words about how YAML became the default and why that’s a problem. HCL has real types, real comments, real structure, and it’s the same language as Terraform — so the muscle memory transfers.
• Lower operational overhead, full stop. Three servers, N clients, a gossip protocol that heals itself. A small team can actually own a Nomad cluster without a dedicated platform group, which is more than most teams can honestly claim about their Kubernetes.
• The HashiCorp stack composes. Add Consul and you get native service discovery and a Connect service mesh. Add Vault and you get secrets injected into tasks. They snap together because they’re built by the same people to do exactly that.

Where Nomad doesn’t shine

I owe the honest version, the same way I do for everything I actually run.

• The ecosystem is a rounding error next to Kubernetes. No Helm. No CRDs. No operators. No thousand-strong catalogue of off-the-shelf controllers. When you hit a problem, the Stack Overflow answer assumes Kubernetes, the blog post assumes Kubernetes, the vendor integration assumes Kubernetes. With Nomad you are regularly the first person Googling your exact issue.
• No native pod networking. Kubernetes gives every pod an IP and a flat network as a baseline assumption. Nomad makes you think about networking deliberately — host mode, bridge mode, or a CNI you bring yourself. More honest, but more work.
• A real service mesh means running Consul. That’s a second HashiCorp product to operate. Powerful when you want it, but it’s no longer “single binary” once you do.
• Hiring is harder. The market is full of people who know Kubernetes. The pool that knows Nomad is small. Onboarding is easy — the tool is simple — but you can’t recruit for existing Nomad experience the way you can for K8s.
• Few managed offerings. Nobody is selling you a one-click Nomad the way every cloud sells managed Kubernetes. You run it yourself, or you run it on HashiCorp/IBM’s terms.
• The IBM question mark. I won’t pretend it isn’t there. Nomad has always been the quieter sibling next to Terraform and Vault, and quieter products under big-company ownership are exactly the ones that get “rationalised.” Nothing has happened. But it’s a factor in a long-term bet, and pretending otherwise would be dishonest.

When to pick Nomad

• Small teams who can’t afford a platform group. If nobody on the team wants to become a full-time Kubernetes operator, Nomad’s lower overhead is the entire argument.
• Mixed workloads. Containers plus raw binaries plus the odd VM or Java service. This is Nomad’s home turf and Kubernetes’s weakest fit.
• Batch and simple scheduling. Periodic jobs, parametrised batch runs, “spread this across the fleet” — Nomad does these cleanly without ceremony.
• When Kubernetes is plainly overkill. A dozen services on a few nodes does not need the full cloud-native machine. It needs a scheduler.
• Teams already invested in Consul and Vault. If you’re running the HashiCorp stack already, Nomad slots in like it was designed to — because it was.

When not to pick Nomad

• Large-scale, ecosystem-heavy container platforms. If you want Helm charts, operators, CRDs and the whole CNCF buffet, that’s Kubernetes, and Nomad will feel like swimming upstream.
• When managed Kubernetes is right there. On a hyperscaler with EKS/GKE/AKS one click away, the maths often favours letting the cloud run the control plane.
• When you need CRDs or operators. If your architecture depends on extending the orchestrator’s API, Nomad doesn’t have that model. Full stop.
• When the team is already K8s-fluent and happy. Don’t migrate a working Kubernetes shop to Nomad for purity points. The cost of changing tools is almost always higher than it looks, and “simpler” is not a business case on its own.

The way I actually use it

My rule is boring: Kubernetes when the workload earns it, Nomad when it doesn’t.

The RKE2 clusters I wrote about are still where the serious, ecosystem-heavy, GitOps-driven workloads live — the stuff that genuinely benefits from operators, CRDs and a managed ingress story like the one in the reverse-proxy roundup. But there’s a whole class of work that doesn’t need any of that: a handful of internal services, a batch pipeline, a mix of containers and a couple of plain binaries that were never going to be containerised. For that, standing up a Kubernetes cluster is paying a tax on complexity I’ll never use. Nomad is one binary, an afternoon, and an HCL file I can read out loud.

That’s the whole pitch. Nomad isn’t a Kubernetes-killer and it’s not trying to be. It’s the tool for when the Kubernetes-shaped hole in your architecture turns out to be smaller than you assumed.