Nomad

What it is

Nomad is a workload orchestrator built by HashiCorp. It schedules and manages containers, standalone binaries, JVM apps, and VMs across a cluster, using a single Go binary for both client and server roles. Unlike Kubernetes, it doesn't try to be a full platform — no built-in ingress, no CNI-mandated networking stack, no CRD ecosystem. You bring Consul for service discovery, Vault for secrets, and Terraform for provisioning if you want that. Job specs are written in HCL. It runs as a thin scheduler with pluggable task drivers (Docker, exec, Java, QEMU, and others), which is the core design bet: broader workload support, smaller footprint, less operational surface area than K8s.

Who builds it and why

HashiCorp builds and maintains Nomad. Founding date and CNCF maturity data are not publicly available — and that's not an oversight: Nomad has never been a CNCF project. It's a HashiCorp product, part of the same suite as Terraform, Consul, and Vault, and it's built to interoperate tightly with them. The commercial motive is straightforward: Nomad is the free/open entry point into HashiCorp's infrastructure stack, with Nomad Enterprise (namespaces, multi-cluster federation extras, advanced ACLs, sentinel policies) sold on top.

Production readiness signal

936 contributors and 16,670 GitHub stars is a real, established project — not a toy. Last commit dated 2026-07-01 with a v2.0.3 release indicates active, ongoing maintenance and a mature major-version line, not early-stage churn. That said, the license field returns NOASSERTION, which is a flag worth taking seriously: HashiCorp moved its repos off pure open-source licenses (MPL) to the Business Source License in 2023, and IBM's acquisition of HashiCorp has added uncertainty to long-term licensing terms. Before adopting Nomad at scale, pull the actual LICENSE file from the repo and read it — don't assume OSS terms.

Who should use this

• Teams running mixed workloads — containers alongside legacy binaries, batch jobs, or VMs — where forcing everything into a container/K8s model adds unnecessary translation overhead.
• Ops teams that want a small, understandable control plane and are willing to trade Kubernetes' ecosystem breadth for operational simplicity.
• Shops already invested in Consul and Vault, where Nomad slots in as a natural third leg rather than a bolted-on scheduler.
• Edge or resource-constrained deployments where running full Kubernetes control plane overhead isn't practical.

Who should NOT use this

• Teams that need the Kubernetes ecosystem itself — Helm charts, operators, service meshes built K8s-native, managed cloud offerings (EKS/GKE/AKS). Nomad's ecosystem is a fraction of that size, and you'll be writing more glue yourself.
• Organizations with strict open-source licensing requirements or legal review processes — the NOASSERTION license status and BSL history will trip up procurement and compliance review. Get this settled before you commit engineering time.
• Anyone expecting a batteries-included platform (ingress controllers, autoscaling, policy engines) out of the box — Nomad expects you to assemble those from Consul, Vault, and third-party tools.
• Teams without existing HashiCorp tooling experience who'll get more community support and hiring pool depth from Kubernetes instead.

Alternatives

• Kubernetes — the default choice for container orchestration; larger ecosystem, steeper operational complexity, CNCF-governed.
• Docker Swarm — simpler still than Nomad, but effectively in maintenance mode with a shrinking community.
• Amazon ECS — AWS-native container orchestration with less operational overhead if you're fully committed to AWS and don't need multi-cloud or non-container workloads.

Pricing

Nomad itself is source-available and free to run (verify current license terms directly in the repo given the NOASSERTION status). Nomad Enterprise is a paid tier layered on top, with pricing not publicly listed — you'll need to talk to HashiCorp sales for a quote.