Nomad Tutorial: Learn Workload Orchestrator from Scratch (2026)
When Kubernetes felt too heavy for my batch processing workloads and simple web services, I discovered HashiCorp Nomad. It manages both containerized and non-containerized applications with a single binary and simple configuration.
By the end of this tutorial, you will know how to deploy a Nomad cluster, write job specifications for different workload types, use service discovery with Consul, and manage rolling deployments.
Nomad Architecture and Cluster Setup
Nomad has servers (manage cluster state, schedule jobs via Raft) and clients (run workloads). A single binary runs both modes. Production clusters need 3 or 5 servers. Consul integration provides service discovery and health checking.
# server.hcl
server {
enabled = true
bootstrap_expect = 3
}
bind_addr = "0.0.0.0"
Job Specification: The Heart of Nomad
A job spec describes what to run. Types: service (long-running), batch (run to completion), system (run on every client), parameterized batch. Each job has task groups that run together, and tasks define the driver, resources, and configuration.
job "web" {
datacenters = ["dc1"]
type = "service"
group "web-group" {
count = 3
task "nginx" {
driver = "docker"
config { image = "nginx:stable-alpine" }
}
}
}
Job Types: Service, Batch, System, Parameterized
Service jobs maintain desired allocation count with auto-rescheduling. Batch jobs run to completion for ETL and CI/CD. System jobs run on every client. Parameterized batch jobs accept input payloads. The periodic stanza schedules batch jobs on cron.
job "etl-pipeline" {
type = "batch"
periodic {
crons = ["0 2 * * *"]
prohibit_overlap = true
}
}
Service Discovery and Consul Integration
Nomad natively integrates with Consul. The service stanza registers the task with Consul for DNS and API discovery. Health checks monitor the service. The connect stanza enables Consul Connect sidecars for mTLS service mesh.
service {
name = "api"
port = "http"
tags = ["production", "v2"]
check {
type = "http"
path = "/health"
interval = "10s"
}
}
Updating Jobs: Rolling, Blue/Green, Canary
The update stanza configures deployment strategies. Rolling updates replace allocations gradually. Canary deployments test one allocation first. Auto-revert rolls back on health check failure. Blue/green uses max_parallel and min_healthy_time.
update {
max_parallel = 2
canary = 1
health_check = "checks"
auto_revert = true
}
Security, ACLs, and Production Operations
Nomad uses mTLS for all RPC communication. ACLs enforce API and CLI access. Vault integration gives tasks access to dynamic secrets. Namespaces isolate workloads by team. Audit logging captures all API requests.
nomad acl policy apply web-dev web-dev-policy.hcl
nomad acl token create -name "dev-token" -policy web-dev
nomad namespace apply -description "Development" dev
Frequently Asked Questions
What is the difference between Nomad and Kubernetes?
Nomad is simpler and runs containers, binaries, JARs, and VMs. Kubernetes has built-in service discovery and extensive APIs. Nomad excels for batch and legacy apps.
Does Nomad require Consul and Vault?
No, but Consul is strongly recommended for service discovery. Vault integration provides dynamic secrets. For production, Consul integration is critical.
How does Nomad handle persistent storage?
Nomad supports host volumes, Docker volumes, and CSI volumes. The CSI integration dynamically provisions volumes from providers like AWS EBS.
Can Nomad run on Kubernetes?
Yes, Nomad can run in a container on Kubernetes. More commonly, teams run them alongside each other on separate nodes.
Originally published on Ayodhyyya. Last updated June 1, 2026.