HashiCorp Nomad vs Kubernetes
HashiCorp Nomad and Kubernetes compared: architecture, workloads beyond containers, networking and service discovery, ecosystem, licensing (BSL vs Apache-2.0), release support and operating cost as of October 2026.
Quick Answer
Kubernetes is the Apache-2.0, CNCF-governed default for container orchestration: a control plane of several components, a huge ecosystem (Helm, operators, Gateway API, every cloud's managed service) and three supported minor releases at a time with about a year of patches each. Nomad is a single binary from HashiCorp (now IBM) that schedules containers, plain binaries, Java and VMs with one job spec, and leans on Consul and Vault for production networking and secrets; since 1.7 it is source-available under the Business Source License. Pick Kubernetes for ecosystem, hiring and managed offerings; pick Nomad for a small team running mixed workloads that values operational simplicity.
Last updated October 30, 2026. Covers Nomad v2.1.1 (29 Oct 2026) and Kubernetes v1.37.2 (28 Oct 2026), with Nomad's BSL licence terms, Enterprise features, production requirements and Kubernetes' release-support dates, as of 30 Oct 2026.
| Feature | HashiCorp Nomad | Kubernetes |
|---|---|---|
| Licence | Business Source License 1.1 (Nomad 1.7.0+); production use allowed except competing hosted/embedded offerings | Apache-2.0 |
| Governance / Vendor | HashiCorp, an IBM company (licensor: IBM); community and Enterprise editions | CNCF / Linux Foundation, vendor-neutral |
| Architecture | Single binary in server or client mode; 3–5 Raft servers per region, clients over RPC | Control plane (kube-apiserver, etcd, scheduler, controller manager) + worker nodes (kubelet, optional kube-proxy) |
| Workload Types | Docker containers, isolated and raw fork/exec binaries, Java, QEMU VMs; service, batch and system jobs | Containers in Pods (Deployments, StatefulSets, DaemonSets, Jobs, CronJobs); others via CRDs and add-ons |
| How You Define Workloads | HCL job specification (jobspec) with variables | YAML/JSON manifests against the Kubernetes API; Helm, Kustomize on top |
| Service Discovery / Networking | Lightweight native service discovery; Consul recommended for production and service mesh | Built-in Services and cluster DNS; Gateway API recommended over the frozen Ingress API |
| Secrets | Nomad Variables built in; Vault integration (multiple Vault namespaces in Enterprise) | Built-in Secrets objects; external stores via operators/CSI drivers |
| Multi-Region | Native multi-region federation; multi-region job deployments in Enterprise | One cluster per region typically; multi-cluster via add-on tooling |
| Ecosystem | Terraform, Consul, Vault, Packer integrations; community task drivers and plugins 6/10 | Largest in the space: Helm, operators, Argo CD/Flux, service meshes, CSI/CNI plugins 10/10 |
| Managed Offerings | Self-managed only on the pages we read (community or Enterprise) | Widely available as managed services from cloud providers; distributions like K3s for self-hosting |
| Resource Guidance | Production servers: 4–8+ cores, 16–32 GB+ RAM, 40–80 GB+ fast disk, sub-10 ms latency between servers | kubeadm: 2 GB+ RAM per machine, 2+ CPUs for control-plane machines, full network connectivity |
| Release Support | Community releases on GitHub; Enterprise follows IBM's enterprise lifecycle with paid support options | Three most recent minors maintained; ~1 year patch support plus 2-month maintenance mode |
| Latest Release (Oct 2026) | v2.1.1 (29 Oct 2026); v2.1.0 on 28 Oct 2026; v2.0.0 on 21 Apr 2026 | v1.37.2 (28 Oct 2026), with 1.36.6 and 1.35.10; v1.38.0-alpha.3 in testing |
HashiCorp Nomad
Workload orchestrator from HashiCorp (an IBM company) that runs containers, non-containerized binaries, Java apps, VMs and batch jobs from one declarative job specification, distributed as a single self-contained binary.
Pros
- Single binary with no external dependencies for storage or coordination, so a cluster is just Nomad servers and clients
- Schedules more than containers: bundled Docker, isolated exec, raw exec, Java and QEMU task drivers, plus device plugins for GPUs
- One HCL job spec covers service, batch and system jobs; v2.1.0 adds an experimental batch job queue with FIFO and dynamic-priority options
- Built-in federation links regions so jobs can be submitted from anywhere in the cluster
- Tight integration with Consul (service discovery, mesh) and Vault (secrets) for teams already on the HashiCorp stack
- Runs on Linux, Windows and macOS
Cons
- Business Source License since 1.7.0: production use is allowed, but competing hosted or embedded offerings are not, so it is no longer open source
- Built-in service discovery is described by HashiCorp as lightweight; production setups are pointed to Consul, adding another system to run
- Much smaller ecosystem than Kubernetes: far fewer operators, charts, managed services and engineers with experience
- Governance features such as resource quotas, Sentinel policies, audit logging and multi-region deployments are Nomad Enterprise only, with no public price
Best For
Small platform teams running mixed workloads (containers plus legacy binaries, Java or VMs) on their own servers, especially if they already use Consul, Vault and Terraform.
Kubernetes
Open-source container orchestration system governed by the CNCF, with a control plane (API server, etcd, scheduler, controller manager) managing Pods on worker nodes and an extensible API that most cloud-native tooling builds on.
Pros
- Apache-2.0 licence with vendor-neutral governance; nobody can relicense it out from under you
- Largest ecosystem in infrastructure: Helm charts, operators, CRDs, GitOps tools and observability stacks assume Kubernetes first
- Every major cloud and many hosts offer managed control planes, and lightweight distributions such as K3s cover VPS and edge
- Gateway API is the recommended, role-oriented successor to Ingress for advanced traffic routing
- Clear release policy: the three most recent minor releases are maintained with about a year of patch support each
- Deep hiring pool and documentation, from tutorials to certification
Cons
- More moving parts: API server, etcd, scheduler, controller manager, kubelet and usually kube-proxy, CNI, CSI and an ingress or gateway controller
- Containers only out of the box; VMs or raw binaries need add-ons such as KubeVirt or wrapping in images
- Upgrades are mandatory to stay supported: each minor reaches end of life roughly 14 months after release (1.34 went EOL on 27 Oct 2026)
- YAML manifests and the API surface have a steep learning curve for small teams
Best For
Teams that want the industry-standard platform, managed cloud options and an ecosystem of operators and tools, and that can invest in running or buying a control plane.
Architecture: one binary vs a control plane of components
Both systems split work between servers that schedule and clients that run workloads, but they package that very differently. A Kubernetes control plane is several components: kube-apiserver as the front door, etcd as the key-value store holding cluster state, kube-scheduler to place Pods, and kube-controller-manager running controllers for nodes, jobs, service accounts and more. Worker nodes run kubelet to keep containers in Pods running and, usually, kube-proxy for service networking. On top of that you choose a container runtime, a CNI network plugin, a CSI storage driver and an ingress or Gateway API controller. HashiCorp's own Kubernetes-practitioner guide notes that the control plane runs separately from workers and that each controller is an additional component. Nomad is one binary that runs in server or client mode. HashiCorp describes it as entirely self-contained, combining resource management and scheduling, with no external services needed for storage or coordination. Servers replicate state with Raft and HashiCorp recommends an odd number, usually 3 to 5 per region and no more than 7; clients register with their region's servers over RPC and send heartbeats. Regions are independent and are linked by gossip-based federation rather than sharing one stretched cluster. The practical effect is the size of the system you have to understand when something goes wrong. A three-server Nomad cluster with a few clients is three processes' worth of logs and one config format. A self-managed Kubernetes cluster is a stack of components, each with its own failure modes, which is exactly why most teams run it as a managed service or a packaged distribution like K3s.
Workloads: containers only vs containers, binaries, Java and VMs
Kubernetes schedules containers. Its building block is the Pod, a group of one or more tightly coupled containers, managed by controllers such as Deployments, StatefulSets, DaemonSets, Jobs and CronJobs. Anything else, such as a virtual machine or a legacy binary, needs an extension: a CRD and operator such as KubeVirt for VMs, or wrapping the binary in a container image. For teams that have already containerized everything, this is not a limitation at all. Nomad's pitch is that you do not have to containerize first. Its bundled task drivers are Docker, isolated fork/exec, raw fork/exec, Java and QEMU, and device plugins detect GPUs, FPGAs and TPUs for ML workloads. One HCL job file can define service jobs (long-running), batch jobs and system jobs (one per node), with constraints, affinities and resource requests. Nomad is also supported on Windows and macOS, not just Linux. Version 2.1.0, released on 28 October 2026, adds an experimental batch job queue on node pools with FIFO ordering or dynamic priority based on age and fairness, which is aimed squarely at teams running large batch fleets. HashiCorp is careful to say that task drivers' resource isolation varies by driver and OS and that the client-to-task interface is not a security boundary, so raw exec is a convenience, not a sandbox. If your estate is a mix of Docker services, a JVM monolith and some VMs, Nomad lets one scheduler manage all of it. If it is all containers, Kubernetes' extra breadth is wasted on Nomad.
Networking, service discovery and secrets
Kubernetes ships the networking primitives most apps need. Services give Pods stable virtual IPs and DNS names inside the cluster, and for traffic entering the cluster the project now recommends Gateway API, a role-oriented family of custom resources for advanced routing, over Ingress, whose API is frozen. Actual packet handling depends on the CNI plugin you choose. Secrets are a built-in object type, and external stores such as Vault or cloud secret managers plug in through operators or CSI drivers. Nomad keeps the core smaller. It has a native service discovery feature, but HashiCorp's docs describe it as lightweight and suitable for edge computing and basic requirements, and recommend Consul for production workloads; Consul's catalog, health checks and service mesh are where most production Nomad networking ends up. For secrets, Nomad has built-in Variables and a first-class Vault integration that hands tasks tokens based on their job; Enterprise adds multiple Vault namespaces and multiple Consul and Vault clusters per Nomad cluster. This is the hidden cost in comparisons that call Nomad 'one binary': a production Nomad platform is often Nomad plus Consul plus Vault, three HashiCorp systems with BSL licences. That is still simpler than many Kubernetes stacks, and it is very natural for teams already on HashiCorp tooling, but it is not one process.
Licensing, governance and the long-term bet
This is where the two have diverged most in recent years. Kubernetes is Apache-2.0 and governed by the CNCF under the Linux Foundation. Many vendors contribute, many sell distributions and managed services, and no single company can change its licence. Nomad 1.7.0 and later are released under the Business Source License 1.1, with IBM Corp. named as licensor. The Additional Use Grant allows production use as long as you are not offering Nomad to third parties on a hosted or embedded basis in a way that competes with IBM's paid versions; a 'competitive offering' is defined as a paid product that significantly overlaps with those paid versions, and unpaid products are not competitive. For an internal platform team this means Nomad is still free to run. For a company building a hosted PaaS or selling a product with Nomad embedded, it means a legal review. Nomad also has a commercial edition. Nomad Enterprise adds resource quotas, Sentinel policies, audit logging, multi-region deployments and Autopilot features such as automated upgrades and redundancy zones, follows IBM's enterprise software lifecycle and has paid support packages. HashiCorp warns that an Enterprise cluster cannot be downgraded to the community edition. No public price was shown on the pages we read, so budget a sales conversation. On release cadence, both are active: Kubernetes shipped 1.37.2, 1.36.6 and 1.35.10 on 28 October 2026, and Nomad shipped 2.1.0 the same day and 2.1.1 a day later.
Operating cost, upgrades and when to pick each
Kubernetes' minimum footprint looks small on paper: the kubeadm docs ask for 2 GB or more of RAM per machine and 2 or more CPUs for control-plane machines. The real cost is upkeep. The project maintains only the three most recent minor releases, each with roughly a year of patch support followed by a two-month maintenance mode. Kubernetes 1.34 reached end of life on 27 October 2026, 1.35 follows on 28 February 2027 and 1.37 on 28 October 2027. Staying supported means upgrading a minor version a few times a year, plus every add-on you installed. Managed services and distributions like K3s absorb much of that work, which is why self-managing vanilla Kubernetes rarely makes sense for small teams. Nomad servers need to be sized for scheduling throughput. HashiCorp's production requirements suggest 4 to 8 or more cores, 16 to 32 GB or more of memory and 40 to 80 GB or more of fast disk for servers in large deployments, with sub-10 ms latency between servers. Smaller clusters can run on far less, but the guidance makes clear the servers are the critical tier. Upgrades are generally a rolling binary replacement, though major versions carry breaking changes: 2.1.0 now requires agent:write for server joins and removed deprecated server-level retry_join and start_join blocks. Pick Kubernetes for container-native teams that want managed options, a vast ecosystem and portable skills. Pick Nomad for small teams with mixed workloads on their own hardware, especially if Consul and Vault are already in place and the BSL terms suit your business.
Verdict
Choose Kubernetes unless you have a concrete reason not to. It is Apache-2.0 under the CNCF, every cloud sells it as a managed service, K3s and similar distributions make it practical on a VPS, and almost every operator, Helm chart and GitOps tool assumes it. That ecosystem, plus a large hiring pool, outweighs its complexity for most teams. Choose Nomad when your team is small, you run your own servers, and your workloads are mixed: containers alongside plain binaries, Java services, QEMU VMs or heavy batch jobs that you do not want to containerize. A single binary with one HCL job spec is easier to operate, and it fits naturally if you already run Consul and Vault. Before choosing Nomad, read the BSL terms: internal production use is fine, but building a paid hosted platform on it may not be. If you mainly deploy web apps in containers, use Kubernetes (managed, or K3s on your own boxes).