HashiCorp Nomad

A scheduler in one binary that places containers, plain executables, Java apps and VMs across a cluster.

What it is: Container orchestration
Type: Commercial product
Made by: HashiCorp, an IBM company
License: Business Source License 1.1 since Nomad 1.7 (source-available, not OSI open source); MPL 2.0 up to 1.6.x
Facts checked: 5 October 2026

What it is

Nomad is a single Go binary that runs on every machine, either as a server or as a client. Three or five servers per region form a Raft group: they accept jobs, elect a leader and keep the cluster state replicated among themselves, so there is no separate database like etcd to run. Clients register their CPU, memory, devices and installed task drivers with the servers, send heartbeats, and run whatever is allocated to them. A job, written in HCL, holds groups of tasks that must run together on one machine; each task names a driver: docker, exec (isolated with the operating system’s cgroups and namespaces), raw_exec (no isolation, off by default), java or qemu for full virtual machines. The scheduler filters out nodes that fail the job’s constraints, then ranks the rest by bin packing, filling busy machines before empty ones, unless the operator switches the cluster or a node pool to the spread algorithm.

Nomad schedules and restarts work; most other things it delegates. Since 1.3 it has basic built-in service discovery, but HashiCorp still recommends Consul for health-filtered DNS and service mesh in production. For secrets, each task gets a signed workload identity (a JWT) that Vault can trust, so Vault hands the task a token with only its own policies; since 1.10 this is the only way to log in to Vault. Nomad moved from MPL 2.0 to the Business Source License with version 1.7 in December 2023, and IBM completed its purchase of HashiCorp in February 2025. There is a free Community Edition and a paid Enterprise edition, but no managed cloud version: you run the servers yourself.

Why teams pick it

One binary for servers and clients, with no external database or coordination service to operate
Runs more than containers: plain executables, Java apps, Windows apps such as IIS and QEMU virtual machines sit in the same cluster through task drivers
Clients use the host network and dynamic ports by default, so no overlay network is needed to join an existing enterprise network
Several regions can be federated, so a job can be submitted to any region from one place

Watch out for

No longer OSI open source: the BUSL forbids offering it as a competing hosted or embedded product
No managed service from HashiCorp or the big clouds, unlike Kubernetes with EKS, GKE and AKS; you run, back up and upgrade the servers
Production setups usually add Consul for service discovery and mesh and Vault for secrets, so “one binary” often becomes three systems
Audit logging, resource quotas, Sentinel policies, multiregion deployments and automated backups need Nomad Enterprise
A far smaller ecosystem than Kubernetes: Nomad Pack exists, but most vendors ship Helm charts and Kubernetes operators first

Alternatives

What all container orchestration have in common →

KubernetesOpen sourceThe standard open-source orchestrator: declare the containers you want, and controllers keep the cluster matching it.+14 Amazon EKS, Azure Kubernetes Service, Google Kubernetes Engine, K3s…

How it fits with other technologies

What HashiCorp Nomad uses

What uses HashiCorp Nomad

Podmanruns tasks as a task driver forHashiCorp NomadContainers

A web service on Docker with native service discovery and a Vault secret · hcl

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

  group "web" {
    count = 3

    spread {
      attribute = "${node.datacenter}" # don’t bin-pack all copies into one DC
    }

    network {
      port "http" { to = 8080 } # dynamic host port mapped to 8080 in the container
    }

    service {
      name     = "web"
      port     = "http"
      provider = "nomad" # built-in discovery; "consul" for production meshes
    }

    task "app" {
      driver = "docker"
      config {
        image = "ghcr.io/acme/web:1.4.2"
        ports = ["http"]
      }

      vault {} # log in to Vault with this task’s workload identity

      template {
        data        = "{{ with secret \"secret/data/web\" }}DB_PASSWORD={{ .Data.data.db_password }}{{ end }}"
        destination = "secrets/app.env"
        env         = true
      }

      resources {
        cpu    = 500 # MHz
        memory = 256 # MB
      }
    }
  }
}

Nomad and Kubernetes compared#

Both take a declared desired state and keep a cluster matching it. They differ in how much they include and how much you have to run.

	Nomad	Kubernetes
Processes to run	One `nomad` binary, started as a server or a client agent	Control plane: kube-apiserver, etcd, kube-scheduler, kube-controller-manager; on each node: kubelet, a container runtime and usually kube-proxy
Where cluster state lives	Replicated with Raft among the 3 or 5 servers of each region	In etcd, a separate key-value store
What it can run	Containers, isolated or raw executables, Java apps and QEMU VMs, through task drivers	Containers in Pods, through a container runtime such as containerd
Networking	Host network with dynamic ports by default; no overlay required	An IP per Pod, virtual IPs for Services, usually an overlay network and an ingress controller
Service discovery	Basic built-in discovery since 1.3; Consul recommended for production	Built in: Services with stable addresses
Secrets	Nomad Variables, encrypted in Raft; Vault through workload identity	Secret objects in the API; the docs suggest external secret store providers
Job format	HCL jobspec: job, groups, tasks	YAML manifests: Deployment, Service, ConfigMap, Secret and more
Documented scale	HashiCorp cites production clusters above 10,000 nodes and a 2-million-container test (2020)	Supports up to 5,000 nodes, 150,000 Pods and 300,000 containers per cluster
Managed offerings	None; self-managed Community or Enterprise	Amazon EKS, Google GKE, Azure AKS and others
Packaging	Nomad Pack	Helm charts and operators
Licence and governance	BUSL 1.1, owned by IBM (HashiCorp)	Apache 2.0, a graduated CNCF project

The Nomad column’s scale figures and its own comparison come from HashiCorp’s documentation; the Kubernetes limits are from the Kubernetes docs’ large-cluster guidance.

Editions#

Community Edition

free, BUSL

The full scheduler, task drivers, ACLs, Variables, native service discovery, workload identity and federation. From 2.0, HashiCorp backports security and bug fixes to Community releases for two years.

Enterprise

paid

Adds Autopilot upgrades and redundancy zones, non-voting read servers, automated snapshots, audit logging, resource quotas, Sentinel policies, multiregion deployments, dynamic application sizing and multiple Vault or Consul clusters. An Enterprise cluster can’t be downgraded to Community.

Managed (HCP)

not offered

HashiCorp Cloud Platform runs Vault, Packer, Boundary and others as managed services, but has no Nomad service. Every Nomad cluster is self-managed.

See it in a real stack

No architecture uses HashiCorp Nomad yet. Drop it into the playground and wire it up yourself.Open playground →

Where it came from2015–2026

On September 28, 2015, HashiCorp’s Armon Dadgar announced Nomad, “a cluster manager and scheduler designed for microservices and batch workloads”. Developers declare in a job file what to run and how much CPU, memory and disk it needs; Nomad finds machines with room and packs as many applications onto each host as it can. Unlike most schedulers of the time it was not only for containers: drivers for Docker, QEMU virtual machines, Java JARs and any pre-installed executable shipped on day one.

The design borrowed from research and from HashiCorp’s own libraries. Cluster management followed Google’s Borg and Omega papers, including Omega’s optimistic concurrency, which lets every server work out placements in parallel. Leader election and replication reused the Raft implementation built for Consul, and regions federated over gossip from Serf. The result was one binary that needed no external coordination or storage.

HashiCorp stress-tested it with a one-million-container challenge in 2016 and two million in 2020, the year of Nomad 1.0. Version 1.3 (2022) added simple built-in service discovery, so small clusters no longer needed Consul. Nomad moved to the Business Source License from version 1.7 in 2023, and in April 2026, with HashiCorp part of IBM, Nomad 2.0 adopted IBM’s versioning and support lifecycle.

Why it’s built this way

One binary, no external dependencies: Using the Raft code already proven in Consul let Nomad keep its own state and elect a leader without ZooKeeper, etcd or a database, which is most of what makes it simple to operate.
Task drivers instead of containers only: Drivers for Docker, QEMU, Java and plain executables let teams bring scheduling and automatic restarts to existing applications without first packaging them as containers.
Optimistic concurrency from Google’s Omega: Every server computes placements in parallel and the leader only checks that plans don’t oversubscribe a client, which raises scheduling throughput as servers are added.
Schedule, and leave the rest to other tools: HashiCorp designed Nomad with a small scope, composing with Consul for service discovery and Vault for secrets rather than building everything in. The built-in service discovery added in 1.3 softened that rule for small clusters.

Timeline

2015
Announced and released as 0.1.0 on September 28
2016
The one-million-container challenge
2020
Nomad 1.0 in December; the two-million-container challenge
2022
Nomad 1.3 adds native service discovery
2023
Nomad 1.7 ships under the BUSL, with workload identity for Vault and Consul
2025
IBM completes its HashiCorp purchase; 1.10 drops token-based Vault logins
2026
Nomad 2.0 in April, on IBM’s support lifecycle

Sources35 · facts checked 5 October 2026

Improve this page on GitHub