Nomad: product and architecture
This Nomad review covers HashiCorp's workload orchestrator, and the case it makes is about scope rather than features. Nomad schedules and supervises applications across a cluster, but it schedules more than containers: raw executables, JVM applications and batch jobs are first-class workload types. It ships as a single binary that runs as both client and server, and it integrates with Consul for service discovery and Vault for secrets rather than implementing either itself. We evaluated it on its documentation, its licence, and its GitHub repository, which carried 16,953 stars when we checked on 19 September 2026.
Overview
Nomad exists for estates where the orchestrator is not the point. Most teams reaching for a scheduler want workloads placed on machines, restarted when they fail, and moved when a host drains. Kubernetes does that and a great deal more, and the "great deal more" is what a smaller platform team ends up operating.
Nomad's design decisions follow from that. One binary, running in either client or server mode, rather than a control plane of several components. A job specification in HCL describing what to run and where it may run. Bin-packing placement with constraints and affinities. No ingress controllers, no CRDs, no operator pattern to learn before the first deployment.
The other defining choice is workload breadth. A team with containerised services, a legacy JVM application that will not be containerised this year, and a nightly batch job can schedule all three through one system. That is unusual: most orchestrators assume containers and leave everything else to the hosts.
Key Features and Architecture
Task drivers are the mechanism behind the breadth. A driver knows how to run one kind of workload — Docker containers, Podman containers, raw executables, Java applications, QEMU images — and the scheduler treats them uniformly. The job specification names the driver, and placement, health checking and restart behaviour work the same way regardless.
The scheduler places work by bin-packing against declared resource requirements, with constraints restricting where a job may run and affinities expressing preference. Update strategies cover rolling deployments, canaries and automatic rollback on failed health checks, which is the part that matters for production rather than for a demo.
Federation is built in rather than bolted on. Nomad has a first-class notion of regions and datacentres, and a job can be submitted to one region and scheduled across datacentres within it, which suits estates that span sites.
Integration is deliberately narrow. Service discovery and health checking come from Consul, and secrets come from Vault, with native templating that renders secrets into a task's environment or files and restarts the task when they rotate. Nomad ships its own basic service discovery for teams that do not want Consul, but the integrated path is the one the design assumes.
Operationally, the single-binary model is the feature. Adding capacity is running the binary on another machine in client mode; the server quorum is a Raft cluster of three or five. Upgrades are a binary replacement rather than a coordinated control-plane migration, which is the difference a small team feels most often, because it turns a planned maintenance event into a routine one.
Ideal Use Cases
Nomad fits an estate that is not container-only. If a meaningful share of workloads are JVM applications, static binaries or batch jobs, scheduling them through one system rather than two is a real simplification.
It fits a small platform team. The operational surface of a single binary with a Raft quorum is substantially less than a Kubernetes control plane, and a team of two or three can run it without that becoming their whole job.
It fits organisations already using Consul and Vault, where the integration is native and the operational model is familiar.
It fits edge and multi-site deployments, where the region and datacentre model maps onto physical reality and the lightweight agent runs on modest hardware.
It fits teams migrating gradually. Because Nomad schedules raw executables as readily as containers, an estate can be brought under one scheduler before every workload has been containerised, rather than treating containerisation as a prerequisite for orchestration.
Do not use Nomad if you need the Kubernetes ecosystem. The gap is not scheduling — Nomad schedules well — it is everything built on top: operators that manage databases, service meshes, Helm charts, managed offerings from every cloud, and a hiring pool that already knows the concepts. Choosing Nomad means choosing to build or buy those separately, and for many organisations that ecosystem is the actual product they are adopting.
Pricing and Licensing
Nomad's source is available under the Business Source Licence. That permits production use with one exception — you may not offer it as a competing managed service — and converts to the MPL-2.0 open-source licence after the change date attached to each release.
For most teams that distinction is legal rather than practical: you can run the community binary in production at any scale without paying, and there is no node count or feature gate in the free version. For vendors that sell managed infrastructure, the exception is the whole question and warrants a legal reading rather than a summary.
HashiCorp sells Nomad Enterprise for governance features, multi-region federation, and support, at prices quoted rather than published. Those additions target organisations with compliance requirements or estates spanning several regions.
We recommend treating the licence as a procurement question to settle early rather than a detail. Some organisations have policies that exclude non-OSI licences outright, and discovering that after building on the tool is an expensive way to learn it.
Strengths & Trade-offs
Pros
- Schedules more than containers. Raw executables, JVM applications and batch jobs are first-class, not workarounds.
- One binary, client or server. The operational surface is small enough for a two-person platform team.
- Native Vault and Consul integration. Secrets render into tasks and rotate with restarts handled.
- Regions and datacentres are built in. Multi-site scheduling is a core concept rather than an add-on.
- Production update strategies included. Rolling deploys, canaries and automatic rollback on health-check failure.
Cons
- The ecosystem is the trade. No equivalent of operators, Helm charts, service meshes or managed offerings from every cloud.
- Business Source Licence. Permitted for production use but not OSI-approved, which some procurement policies exclude outright.
- Smaller hiring pool. Engineers who already know Kubernetes concepts are common; Nomad experience is not, and that is a staffing cost.