Migrate to RunxBuild today!! Deploy More while Spending Less

Calculate your savings
unxBuild
Back to Blog Explainer

Nomad Container Orchestration: What It Is and When to Use It

Sean

Platform Writer

Sep 22, 2026
8 min read

Nomad is HashiCorp’s cluster scheduler: a single binary that runs on each machine in a cluster and places workloads, containers, but also raw binaries, Java applications, and virtual machines, across whichever nodes have capacity. It solves a narrower problem than Kubernetes, with fewer moving parts and no separate control-plane components to install, at the cost of a smaller ecosystem and fewer built-in primitives like Kubernetes’ Ingress or Service objects. It genuinely needs a cluster of machines to be worth running at all; a single server or a handful of small services do not need a scheduler, they need a place to deploy to.

Nomad Container Orchestration: What It Is and When to Use It

Nomad gets recommended as the simpler alternative to Kubernetes often enough that the recommendation deserves a closer look: simpler than what, at what cost, and for whom. The honest answer depends on whether you actually have a cluster problem or just a deployment problem wearing a cluster’s clothes.

Table of contents

What Nomad Actually Is

Nomad is one binary that runs in two modes: server, the control plane, an odd number of them for consensus via Raft, and client, the workers that actually run jobs. You describe a job in HCL or JSON, how many instances, what resources, what constraints, and Nomad’s scheduler decides which client nodes run it, watching for node failures and rescheduling as needed.

There is no separate etcd, no API server as a distinct component, no kubelet, server and client are the same binary in different modes, which is most of what people mean by simpler. Installing Nomad on a machine is one binary and one config file specifying which mode it runs in.

Containers and Non-Container Workloads

Nomad’s task drivers are pluggable, and Docker is one of several, alongside raw executables, Java, QEMU virtual machines, and community-maintained drivers for other runtimes. A single Nomad cluster can run a Docker container, a JAR file, and a legacy binary as three job types side by side, which Kubernetes cannot do without wrapping the non-container workload in a container first.

That matters specifically for teams with a mix of containerized and legacy workloads and no appetite for containerizing everything just to get a scheduler. A batch job that has always run as a cron-launched binary can join the same cluster as a newly containerized service without either one changing shape.

Nomad vs Kubernetes, Honestly

Kubernetes has a larger ecosystem: more off-the-shelf operators, a bigger pool of engineers who already know it, and built-in concepts, Services, Ingress, StatefulSets, CRDs, that Nomad either does not have or delegates to Consul and other HashiCorp tools to provide. Nomad is smaller to operate, fewer components, a simpler mental model, a gentler learning curve for a team that has never run either.

The honest trade is: Kubernetes does more out of the box and costs more in operational complexity to run; Nomad does less out of the box and costs less to run, and you feel that difference on day one and again on the day you need a feature Nomad does not have natively.

The Consul and Vault Question

Nomad alone gives you scheduling and placement. Service discovery and a service mesh come from Consul; secrets management commonly comes from Vault. Running all three is a more capable but larger stack than Nomad by itself, and the marketing around them tends to present them as one thing when they are three separate services to operate.

A minimal Nomad-only cluster is genuinely minimal. The full stack is not, and evaluating Nomad against Kubernetes should be honest about which version is being compared, a bare Nomad install against bare Kubernetes, or the full HashiCorp stack against Kubernetes plus its own common ecosystem additions.

The BSL License Change

HashiCorp relicensed Nomad, along with Terraform, Vault, and Consul, from the Mozilla Public License to the Business Source License in 2023, which restricts competing commercial offerings while remaining free for internal use. The practical effect for most users running their own cluster is minimal, the restriction targets companies reselling Nomad as a hosted service, not teams running it themselves, but it is worth knowing before standardizing on it, since a subset of the community forked the pre-BSL tools rather than accept the change.

The fork, OpenTofu for Terraform being the most visible example, does not currently have a Nomad equivalent with comparable adoption, which means teams uneasy with the BSL have fewer alternatives for Nomad specifically than they do for HashiCorp’s other tools.

What a Minimal Cluster Actually Costs

A production-minded Nomad cluster wants an odd number of server nodes for Raft consensus, three is typical, plus however many client nodes actually run workloads. Three small server nodes and two or three client nodes is a realistic floor, which on general-purpose cloud instances runs to several hundred dollars a month before a single application workload is deployed, and that is before Consul and Vault if the full stack is in scope.

That fixed cost is the number worth comparing against the problem being solved. It buys resilience and multi-node placement, and it is wasted if the actual workload is two or three services that would run fine on a single host.

Who Should Use Neither, and Pick a Platform Instead

A scheduler earns its cost when there are enough machines and enough workloads that manual placement and failover become real operational work. A handful of services, a database, and a cron job or two do not have that problem, they have a deployment problem, and a platform that builds from a repository and runs the container is a smaller, cheaper answer than a cluster built to solve a scale that has not arrived yet.

The failure mode worth avoiding is adopting Nomad or Kubernetes because the workload is containerized, not because the cluster problem is real. Containerized and clustered are different questions.

How this fits the rest of the stack

A three-node Nomad cluster is worth its cost when the workload actually needs multi-node placement and failover; it is a fixed monthly bill for capacity a handful of services will not use. For the latter, pushing a Docker image at a repository and letting a platform run it covers the same containerized deployment without the server count. What that costs against a Nomad cluster’s baseline is on the RunxBuild hosting calculator.

Useful related references:

FAQ

Is Nomad better than Kubernetes?

Neither is better in general, Nomad is simpler to operate with fewer components and a smaller ecosystem; Kubernetes does more out of the box with more operational complexity to run it. Nomad suits teams that want a lighter scheduler and are willing to trade off built-in primitives and community size for that simplicity.

Is Nomad free?

Nomad is source-available under the Business Source License, free to run yourself, including in production, with the restriction aimed at companies reselling it as a competing hosted service rather than at teams operating their own cluster. HashiCorp also sells a paid Nomad Enterprise tier with additional features.

Is Nomad still maintained?

Yes, HashiCorp continues to release and support Nomad, though the 2023 BSL relicensing led part of the open-source community to fork the pre-license tools instead of tracking new HashiCorp releases. Nomad’s release cadence and issue tracker are both active as of this writing.

Does Nomad need Consul?

No, Nomad schedules and runs workloads on its own. Consul adds service discovery and a service mesh, which becomes useful once services need to find each other dynamically across a cluster, but a Nomad cluster without Consul is a complete, working setup for scheduling alone.

How many machines does a Nomad cluster need?

A production setup typically runs three server nodes for Raft consensus, plus however many client nodes are needed to run the actual workloads, often two or three at minimum. That floor exists before any application is deployed, which is the fixed cost worth weighing against the size of the workload.

#nomad container orchestration#nomad vs kubernetes#hashicorp nomad#nomad scheduler#container orchestration