# HashiCorp Nomad: a single-binary orchestrator for containers and everything else

> Nomad schedules containers, plain binaries, Java processes and QEMU virtual machines from one cluster, with no external coordination service. Here is what the repository and README actually document, and where the trade-offs sit.

**hashicorp/nomad** — Nomad is an easy-to-use, flexible, and performant workload orchestrator that can deploy a mix of microservice, batch, containerized, and non-containerized applications. Nomad is easy to operate and scale and has native Consul and Vault integrations.

- Repository: https://github.com/hashicorp/nomad
- Website: https://www.nomadproject.io/
- Stars: 16,982 · Forks: 2,141
- Language: Go
- License: NOASSERTION
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/hashicorp-nomad

## What Nomad schedules that a container-only orchestrator cannot

The README frames Nomad as a workload orchestrator for containers, non-containerized applications and virtual machines, and that mix is the whole argument. The task driver list names docker and podman for containers, exec and java for plain processes, and qemu for virtual machines. A team running a Java service next to a containerized API next to a batch job does not have to containerize the Java service just to get scheduling, placement and failure recovery. The README states that Nomad "brings core orchestration benefits to legacy applications without needing to containerize via pluggable task drivers".

Who is this for? Operators who want one control plane across on-prem and cloud infrastructure, and who value a small dependency surface over a large ecosystem of extensions. The README claims proven scaling to clusters of 10K+ nodes in production environments, which is a claim from the project rather than an independently verified figure. Treat it as a design target, not a measurement you can rely on for capacity planning.

## Single binary, leader election and replicated state: the actual mechanism

Nomad runs as one binary. The README states it is "entirely self contained - combining resource management and scheduling into a single system" and that it "does not require any external services for storage or coordination". That is the architectural difference worth understanding. There is no etcd to operate, no separate scheduler process to keep alive, no external database for cluster state.

High availability comes from leader election and state replication across servers, which the README describes as the mechanism that provides availability during failures. Clients run the workloads. The scheduler is described as optimistically concurrent, which the README links to higher throughput and lower latency. Federation is built in, so multiple regions and clouds can be addressed from the same system.

The code layout matches that description. The repository has separate top-level directories for client/, scheduler/, nomad/ (the server and core), drivers/, plugins/, acl/ and api/. The api/ and jobspec2/ modules are replaced with local paths in go.mod, meaning the API client and the job specification parser ship from the same tree as the server. If you vendor the API client, you are vendoring code that tracks the server version rather than an independently released library.

Integration with Consul and Vault is native, per the README, and Terraform is named alongside them for provisioning. None of those are required for Nomad itself to run, which matters if you want to adopt the scheduler without adopting the rest of the stack.

## Installing Nomad and running a first job

The README does not carry a copy-paste install sequence. It points to the Getting Started tutorials for setting up a local cluster for non-production use, and to the production reference architecture for real deployments. The repository does ship a Dockerfile and a terraform/ directory with manifests for bringing up a development cluster on a public cloud, so there are two documented paths: follow the tutorials, or build the image yourself.

The Dockerfile is a multi-stage build that copies the compiled binary into a Busybox base image and copies the LICENSE into /usr/share/doc/nomad/LICENSE.txt. The binary is expected at dist/$TARGETOS/$TARGETARCH/nomad, so you build the binary first and then the image:

```bash
make release
```

The GNUmakefile at the repository root is the build entry point; the release target produces the dist/ layout the Dockerfile expects. This is a Go project, and go.mod pins the toolchain:

```go
go 1.26.7
```

Once a cluster is running, the CLI is the way in. The README points to the CLI docs for the full command set, and the jobspec2 module is the parser behind job files. A first job is submitted with the job run command against a job file, and the CLI reports the evaluation and allocation. The README does not print that command sequence in the repository, so check the CLI docs for the exact subcommands and flags rather than guessing them. For a local cluster, the Getting Started tutorial is the source of truth for agent configuration and the bootstrap steps.

## Where Nomad is the wrong tool

If your team has already standardized on Kubernetes manifests, Helm charts and the Kubernetes API, Nomad is not a drop-in. The job specification format is its own thing, parsed by the jobspec2 module, and the README gives no compatibility layer with Kubernetes resources. Migrating means rewriting workload definitions, not translating them.

If you need an OSI-approved open source licence, this is a blocker. The README badge and the Dockerfile label both state BUSL-1.1. The repository metadata reports NOASSERTION, which means the licence could not be classified automatically, so the LICENSE file at the root is the document that governs. The README also notes that a commercial Nomad Enterprise edition exists, which tells you the project has a paid tier and the free tier is not the whole product.

There is a second limitation in the repository itself. The README states that product documentation lives in a separate repository, hashicorp/web-unified-docs, not in this one. Anyone who wants to fix a documentation error has to open a pull request somewhere else, and the docs in this repository will not match the published site by construction. The CHANGELOG-unsupported.md file at the root is another signal that some historical release lines are explicitly out of scope for support.

Finally, the README's roadmap disclaimer is unusually blunt. It says the roadmap is "a best guess at any given point", that dates and projects may change, and that items should not be taken as commitments, "especially ones later than one major release away". Plan upgrades around released versions, not around the roadmap.

## Nomad against Kubernetes and against a plain process supervisor

The nearest comparison is Kubernetes. The difference in approach is dependency count and workload model. Kubernetes assumes containers as the unit of work and expects you to run its control plane components and a datastore. Nomad assumes a job, which may contain containers, executables, Java processes or QEMU virtual machines, and the README states it needs no external services for storage or coordination. That single-binary property is the concrete difference: one process to install, one process to upgrade, no separate state store to back up and restore.

The cost is ecosystem. Kubernetes has a much larger set of controllers, operators and managed offerings. Nomad's extension point is the task driver and device plugin system, and the README names GPU, FPGA and TPU detection through device plugins as built-in support. If your workloads are all containers and you want the widest hiring pool and tooling, Kubernetes is the safer default. If a meaningful share of your workloads are not containers, Nomad's model fits them without a containerization project.

The other comparison is systemd or supervisord on each host. Those give you process supervision and restart, but not cluster-wide placement, leader election, replicated state or federation across regions. Nomad is the layer above them. Choosing it means accepting a scheduler that decides where work runs, not just whether a process stays alive.

## Licence terms, upgrade cadence and what they cost you

The licence is BUSL-1.1 according to the README badge and the Dockerfile's org.opencontainers.image.licenses label. The repository metadata reports NOASSERTION. Those two facts do not agree, and the LICENSE file at the repository root is the one that controls your use. Read it before you deploy. This is not legal advice, and the practical question (whether your specific use is permitted) is one for your own counsel, not for a review of the README.

Upgrade cost is shaped by the release cadence visible in the repository. Releases v2.0.5, v2.0.6 and v2.0.7 landed on 2026-08-13, 2026-09-09 and 2026-09-18 respectively, roughly monthly. The last push to the default branch was on 2026-09-18. That is a fast enough cadence that pinning a version and reading the CHANGELOG.md before each jump is the realistic operating model. The CHANGELOG-unsupported.md file at the root indicates that at least some release lines are outside support, so check which line you are on.

Because the API and jobspec2 modules are replaced with local paths in go.mod, the Go client you compile against is tied to the source tree. Upgrading the server generally means upgrading the client library in the same step. Budget for that in any tooling you build on top of the API.

## Conclusion

Adopt Nomad if you already run mixed workloads and want one scheduler with no external storage or coordination service, and if you accept the BUSL-1.1 terms for the current release. Do not adopt it if you need a Kubernetes-compatible API surface or an OSI-approved licence, because neither is offered here. Before committing, check the LICENSE file at the repository root and the version you plan to run, since the README badge and the Dockerfile both reference BUSL-1.1 while the repository metadata reports NOASSERTION.

## FAQ

### How do I install HashiCorp Nomad?

The README does not include install commands. It directs readers to the Getting Started tutorials for a local non-production cluster and to the production reference architecture for real deployments. The repository also ships a Dockerfile that expects a compiled binary under dist/$TARGETOS/$TARGETARCH/nomad.

### What licence does HashiCorp Nomad use?

The README badge and the Dockerfile label both state BUSL-1.1, while the repository metadata reports NOASSERTION. The LICENSE file at the repository root is the document that governs use.

### Does HashiCorp Nomad need an external database or coordination service?

No. The README states that Nomad is entirely self contained and does not require any external services for storage or coordination, using leader election and state replication for high availability instead.

## Sources

- [hashicorp/nomad on GitHub](https://github.com/hashicorp/nomad)
- [Issues](https://github.com/hashicorp/nomad/issues)
- [Project website](https://www.nomadproject.io/)
- [README](https://github.com/hashicorp/nomad/blob/main/README.md)
- [Releases](https://github.com/hashicorp/nomad/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/hashicorp-nomad