Nomad

Definition

Nomad is a workload orchestrator developed by HashiCorp that schedules and manages applications across a cluster of machines, supporting containers, standalone binaries, virtual machines, and other job types through a single unified scheduler. It is designed as a simpler, more flexible alternative to container-only orchestrators, running as a single lightweight binary that handles both cluster management and job scheduling, which keeps its operational footprint considerably smaller than orchestrators requiring many separate control-plane components.

Overview

Nomad was built by HashiCorp to address a gap left by orchestrators that assume every workload is a container. Many organizations run a mix of containerized applications, legacy binaries, Java applications, and even virtual machines, and Nomad's founding premise is that a single scheduler should be able to place and manage all of these workload types across a shared pool of infrastructure, rather than requiring separate tooling for each. This matters most for organizations with a long operational history, where legacy applications rarely disappear even as newer services adopt containers, leaving teams to manage both worlds at once. Mechanically, Nomad runs as a single binary in either server or client mode, with servers forming a consensus-based control plane using the Raft protocol and clients running on each machine that can execute work. Jobs are submitted as declarative specifications describing the task, its resource requirements, and which driver should execute it, where drivers are pluggable executors for Docker, raw executables, Java, QEMU virtual machines, and other runtimes. The scheduler bin-packs jobs onto available client nodes based on resource availability and constraints, continuously monitoring and rescheduling failed tasks elsewhere in the cluster. Nomad is most often compared to Kubernetes, the dominant container orchestrator. Kubernetes offers a much larger ecosystem of controllers, operators, and extensions but assumes containers as its primary workload abstraction and carries substantially more operational complexity. Nomad trades some of that ecosystem breadth for a smaller footprint, simpler operational model, and native support for non-containerized workloads, and it integrates closely with other HashiCorp tools like Consul for service discovery and Vault for secrets management. In practice, organizations adopt Nomad when they need to orchestrate a heterogeneous mix of workloads, when they want a lighter-weight alternative to running a full Kubernetes control plane, or when they are already using other HashiCorp tools and want a scheduler that integrates natively with that ecosystem. It is used both for general application deployment and for batch and scheduled job processing. The trade-off is ecosystem size: Kubernetes has a much larger community, more third-party integrations, and broader vendor support, which means teams choosing Nomad may need to build more tooling themselves for capabilities that come pre-built in the Kubernetes ecosystem. Organizations already standardized on Kubernetes-native tooling, such as Helm charts or operators, would need to forgo that ecosystem to adopt Nomad. Nomad tends to fit best where workload diversity or operational simplicity outweighs the value of that larger surrounding ecosystem.

Key Features

• Single lightweight binary handling both scheduling and cluster management
• Support for containers, raw binaries, Java, and virtual machine workloads
• Raft-based consensus for server cluster coordination
• Pluggable task drivers for different runtime types
• Bin-packing scheduler optimizing resource utilization across nodes
• Native integration with Consul for service discovery
• Native integration with Vault for secrets management
• Support for both long-running services and batch job scheduling

Use Cases

Alternatives

Frequently Asked Questions

Related in DevOps