HashiCorp Nomad turned into a different product than the one most engineers remember from 2020. The company that built it now sits inside IBM, the license moved from open source to the Business Source License back in 2023, and the binary itself just crossed a major version jump. If your last exposure to Nomad was a conference talk about “the simple alternative to Kubernetes,” a lot has shifted underneath that pitch. This tutorial walks through installing Nomad, running your first job, standing up a production three-server cluster, wiring in Consul and Vault, and avoiding the mistakes that trip up almost everyone on their first deploy.
By the end you will have a working multi-node Nomad cluster, a complete three-tier job specification you can reuse, and a troubleshooting reference for the errors that show up most often in production. Every command below targets the current Nomad Community Edition release line, and every pricing figure reflects the post-IBM licensing structure that took effect through 2025 and 2026.
This guide is written for engineers who already run something in production, whether that is a Kubernetes cluster, a fleet of EC2 instances managed by hand, or a Docker Compose file that quietly grew past what Compose was built for. You do not need prior Nomad experience, but you should be comfortable reading a config file, running commands over SSH, and thinking in terms of services, health checks, and rolling deploys. Where a step depends on Consul or Vault, that dependency is called out explicitly so you can skip it if you only need bare scheduling.
Don't miss new tech stories on Google
Add Tech Insider once in the Google app and our stories appear in your news suggestions.
Why HashiCorp Nomad Still Matters in 2026
IBM completed its acquisition of HashiCorp on February 27, 2025, in a deal valued at roughly $6.4 billion, according to IBM’s official announcement. Nomad, along with Terraform, Vault, and Consul, came along in that deal. None of that changed the core value proposition: Nomad ships as a single binary that can act as both server and client, and it schedules containers, raw binaries, Java applications, and virtual machines from one job specification format. Kubernetes needs an API server, etcd, a scheduler, controller managers, kubelet, and a container runtime working together. Nomad needs one process.
The IBM acquisition also renamed the commercial tiers. What used to be called the Nomad Platform License is now the IBM Nomad Self-managed Premium Resource Value Unit Flexible Subscription License, documented in HashiCorp’s product renaming update. The Community Edition binary you will install in this tutorial did not disappear, and it remains free to run in production. HashiCorp’s own documentation describes Nomad as “a flexible workload orchestrator that enables an organization to easily deploy and manage any containerized or legacy application using a single, unified workflow,” a description that still holds up in the current release.
Nomad also picked up a new versioning scheme in 2026. Instead of the old 1.x line stretching indefinitely, HashiCorp’s self-managed products now target spring and fall feature releases with monthly patches in between. The Nomad Community Edition line moved past 1.10 into the 2.0.x series, with 2.0.7 shipping September 18, 2026 as the latest tagged release on the official GitHub releases page. If your organization needs longer support windows, the 1.10.x branch is designated a long-term support line with base and extended support running through April 2027.
Prerequisites: Versions, Hardware, and OS Requirements
Before you install anything, confirm your environment matches what this tutorial assumes. Nomad is forgiving about hardware for development work but production clusters have real requirements around network stability and disk I/O for the Raft log.
- Nomad version: 2.0.7 (Community Edition), the latest tagged release as of September 2026. Substitute 1.10.x if your organization needs the LTS branch instead.
- Operating system: 64-bit Linux (Ubuntu 22.04/24.04, RHEL 9, or Debian 12 are the most common production choices), macOS 13 or later for local development, or Windows Server 2022 for Windows-native workloads.
- Development machine: 2 CPU cores and 2 GB RAM are enough to run
nomad agent -devalongside Docker Desktop or a container runtime. - Production server nodes: a minimum of three dedicated servers per region for Raft quorum, each with reliable low-latency networking between them. Client node sizing depends entirely on workload density.
- Container runtime: Docker Engine 24 or later if you plan to run the
dockertask driver, which is what most of the examples in this tutorial use. - Optional companions: Consul 1.19 or later for service discovery, and Vault 1.18 or later if you want dynamic secrets injected into jobs.
- Network access: outbound access to
releases.hashicorp.comfor installation, plus open ports 4646 (HTTP API/UI), 4647 (RPC), and 4648 (Serf gossip, TCP and UDP) between cluster members.
None of these requirements are exotic, which is part of the pitch. A three-node Nomad server cluster with modest specs can supervise thousands of allocations once you add client capacity behind it.
Nomad vs Kubernetes: Which Orchestrator Fits Your Stack
Every Nomad tutorial eventually has to answer the comparison question, so let’s get it out of the way early. Nomad and Kubernetes solve overlapping problems with very different levels of operational weight. Kubernetes wins when you need the full ecosystem: CRDs, service meshes, a massive plugin catalog, and a job market full of people who already know it. Nomad wins when you want mixed workloads (containers next to raw-exec batch jobs, next to a legacy Java app) scheduled by one lightweight control plane, or when you are running at the edge where a full Kubernetes control plane is overkill.
| Factor | HashiCorp Nomad | Kubernetes |
|---|---|---|
| Control plane components | Single binary, server + client roles | API server, etcd, scheduler, controller manager, kubelet, CNI plugin |
| Supported workload types | Docker, raw binaries, Java, QEMU VMs, batch/periodic jobs | Primarily containers (plus VMs via KubeVirt add-ons) |
| Job definition format | HCL or JSON job specification | YAML manifests across many resource kinds |
| Typical time to first cluster | Minutes for dev mode, hours for a production 3-server cluster | Hours to days depending on distribution and add-ons |
| Service discovery | Optional Consul integration | Built-in kube-dns/CoreDNS and Services |
| Secrets management | Optional Vault integration | Native Secrets objects, often paired with external tools anyway |
| License (Community Edition) | Business Source License (BSL/BUSL) | Apache 2.0 |
| Best fit | Mixed workloads, edge sites, teams that want operational simplicity | Large container-first platforms with deep ecosystem needs |
If you are already committed to Kubernetes, our Docker vs Kubernetes comparison and our breakdown of K3s vs Kubernetes vs MicroK8s cover the lighter-weight distributions that compete for the same “I don’t want to run a full cluster” audience Nomad targets. The rest of this guide assumes you have decided Nomad’s simplicity is worth the smaller ecosystem, so let’s install it.
Where Nomad Fits: Real-World Use Cases
The teams that get the most out of Nomad tend to share one trait: their workloads do not fit neatly into a single container-only model. A financial services company running a mix of Dockerized microservices alongside a legacy Java batch process that nobody wants to touch is a textbook Nomad candidate, because both workload types run under the same scheduler without forcing the legacy app through a containerization project it was never designed for. Media and rendering pipelines are another common fit, since raw-exec and QEMU task drivers let Nomad hand off GPU-heavy encoding jobs without wrapping every tool in a container image first.
Edge computing is where Nomad’s small operational footprint pays off most directly. A retail chain running compute at hundreds of store locations does not want to babysit a full Kubernetes control plane at every site. A single Nomad client binary, reporting back to a handful of regional server clusters, does the job with far less hardware and far less to patch. Batch processing is the other classic use case: nightly ETL jobs, report generation, and scheduled maintenance scripts map directly onto Nomad’s batch and periodic job types, which this tutorial covers in Step 5 below.
None of this means Nomad is the right default choice for every team. A pure microservices shop that already has deep Kubernetes tooling, a service mesh, and an internal platform team built around kubectl workflows usually has little reason to introduce a second orchestrator. Nomad earns its place when the workload mix, the team size, or the deployment footprint makes Kubernetes’ operational overhead a cost rather than a benefit.
Step 1: Install the Nomad Binary
On Ubuntu or Debian, the cleanest path is HashiCorp’s apt repository, which keeps you on a patchable install rather than a loose binary in /usr/local/bin.
wget -O- https://apt.releases.hashicorp.com/gpg | sudo gpg --dearmor -o /usr/share/keyrings/hashicorp-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] https://apt.releases.hashicorp.com $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/hashicorp.list
sudo apt update && sudo apt install nomadOn RHEL 9 or Fedora, swap the apt steps for dnf:
sudo dnf install -y dnf-plugins-core
sudo dnf config-manager --add-repo https://rpm.releases.hashicorp.com/RHEL/hashicorp.repo
sudo dnf -y install nomadmacOS users can grab it through Homebrew (brew tap hashicorp/tap && brew install hashicorp/tap/nomad), and Windows users can download the zipped binary directly from releases.hashicorp.com and place nomad.exe somewhere on PATH. Whichever route you take, confirm the install before moving on.
Step 2: Verify the Installation and Start a Development Agent
Check the version first:
nomad versionExpected output looks like this:
Nomad v2.0.7
BuildDate 2026-09-18T14:22:03Z
Revision 3f30476Now start a development agent. This single command spins up a combined server and client in one process, which is exactly what you want for learning the CLI before touching a real cluster.
sudo nomad agent -dev -bind=0.0.0.0 -log-level=INFOHashiCorp’s own getting-started tutorial describes this exact pattern as a way to “create a Nomad cluster of one node that acts as both the server and client,” and that framing is the right mental model for what you just did. Leave that terminal running and open a second shell. Point your browser at http://localhost:4646 and you should see the Nomad web UI, which lists jobs, allocations, clients, and server members in real time. It is worth spending five minutes clicking through the UI now, because it will make the CLI output in the next steps easier to read.
Step 3: Write and Deploy Your First Job
Nomad jobs are described in HCL files with a predictable structure: a job block wraps one or more group blocks, and each group wraps one or more task blocks. Create a file called web.nomad.hcl:
job "web" {
datacenters = ["dc1"]
type = "service"
group "app" {
count = 1
network {
port "http" {
to = 8080
}
}
service {
name = "web"
port = "http"
provider = "nomad"
}
task "server" {
driver = "docker"
config {
image = "nginx:latest"
ports = ["http"]
}
resources {
cpu = 500
memory = 256
}
}
}
}Deploy it with:
nomad job run web.nomad.hclYou should see output confirming the deployment was placed and healthy:
==> 2026-09-27T10:14:02-04:00: Monitoring evaluation "8f2c1e91"
Evaluation triggered by job "web"
Allocation "a13d902f" created: node "3b7e4f21", group "app"
Evaluation status changed: "pending" -> "complete"
==> 2026-09-27T10:14:04-04:00: Evaluation "8f2c1e91" finished with status "complete"That HCL structure, with its top-level datacenters, type, and nested group/task blocks, matches the format documented in HashiCorp’s job specification reference, so anything you build here will transfer directly to real production jobs.
Step 4: Check Status, Scale, and Update the Job
Two commands cover most of your day-to-day Nomad diagnostics. The first inspects jobs:
nomad job status
nomad job status webThe second inspects nodes registered with the cluster:
nomad node statusTo scale the job, edit the count field in your HCL file and re-run nomad job run web.nomad.hcl. Nomad diffs the specification against the running job and only touches what changed, so bumping count = 1 to count = 3 triggers exactly two new allocations rather than a full redeploy. The same command handles rolling updates: change the container image tag, run the file again, and Nomad’s default update stanza handles a controlled rollout rather than killing every allocation simultaneously.
Step 5: Run Batch and Periodic Jobs
Not everything is a long-running service. Nomad’s batch and system job types cover one-off scripts, nightly reports, and node-level agents that need to run everywhere. A periodic batch job that runs a cleanup script every night looks like this:
job "nightly-cleanup" {
datacenters = ["dc1"]
type = "batch"
periodic {
cron = "0 2 * * *"
prohibit_overlap = true
}
group "cleanup" {
task "run" {
driver = "docker"
config {
image = "alpine:latest"
command = "sh"
args = ["-c", "find /data -mtime +7 -delete"]
}
resources {
cpu = 100
memory = 64
}
}
}
}The prohibit_overlap flag stops a slow run from colliding with the next scheduled invocation, which matters more than it sounds like it should once you have a job that occasionally hangs.
Step 6: Bootstrap a Production Three-Server Cluster
Development mode is a single point of failure by design. Production Nomad needs a server quorum, and HashiCorp’s own reference architecture calls for three servers as the baseline for high availability, since a three-node Raft quorum tolerates one server failure without losing consensus. Each server needs a config file like this one, adjusted per host:
datacenter = "dc1"
data_dir = "/opt/nomad/data"
bind_addr = "0.0.0.0"
server {
enabled = true
bootstrap_expect = 3
}
advertise {
http = "10.0.1.11"
rpc = "10.0.1.11"
serf = "10.0.1.11"
}Start the agent on each of the three hosts with nomad agent -config=/etc/nomad.d/server.hcl. The bootstrap_expect = 3 setting tells each server how many peers to wait for before electing a leader, which avoids a premature single-node “cluster” that later refuses to merge properly.
Step 7: Join Client Nodes, Enable ACLs and Gossip Encryption
Client nodes run your actual workloads and connect back to the server cluster. A minimal client config points at the server IPs:
datacenter = "dc1"
data_dir = "/opt/nomad/data"
client {
enabled = true
servers = ["10.0.1.11:4647", "10.0.1.12:4647", "10.0.1.13:4647"]
}Once the cluster is joined, enable access control lists so that not everyone with network access to port 4646 can run arbitrary jobs. Add acl { enabled = true } to every server config, restart the servers one at a time to preserve quorum, then bootstrap the ACL system:
nomad acl bootstrapSave the management token this command prints immediately. It is shown exactly once, and losing it means bootstrapping ACLs again from a broken state. For gossip encryption between server and client agents, generate a key and add it to every config file identically:
nomad operator gossip keyring generateCopy the output into an encrypt field under the server stanza on every node. A mismatched key on even one agent will silently keep it out of the gossip pool, which is one of the pitfalls covered later in this guide.
Step 8: Integrate Consul and Vault for Discovery and Secrets
Nomad handles scheduling, but it does not natively give services a way to find each other or manage credentials. That is where Consul and Vault come in, and both are optional add-ons rather than requirements.
For Consul, point Nomad at a running Consul agent in the config file:
consul {
address = "127.0.0.1:8500"
}Then switch the provider field in your job’s service stanza from "nomad" to "consul", and other services on the network can resolve web.service.consul through Consul DNS instead of hardcoding IPs. Full details live in HashiCorp’s Consul integration documentation. If you have not set up Vault as a companion secrets store yet, our own HashiCorp Vault setup guide covers that from scratch.
For Vault, add a similar block pointing at your Vault address and a role Nomad is allowed to use, then reference secrets in a job’s template stanza:
template {
data = <This pulls a credential out of Vault at allocation time and writes it into an environment file the task reads, so the password never sits in your job HCL or your version control history. See HashiCorp's Vault integration reference for the token renewal and policy setup this depends on.
Step 9: Configure the Nomad Autoscaler and GPU Scheduling
The Nomad Autoscaler ships as a separate binary rather than baked into the core agent, and it handles both horizontal application scaling and cluster-level node scaling through policy files. A basic horizontal scaling policy attached to a job's group looks like this:
scaling {
enabled = true
min = 1
max = 10
policy {
cooldown = "1m"
evaluation_interval = "30s"
check "cpu_usage" {
source = "prometheus"
query = "avg(nomad_client_allocs_cpu_total_percent)"
strategy "target-value" {
target = 70
}
}
}
}If you already run autoscaling on Kubernetes with KEDA or Cluster Autoscaler, the target-value strategy pattern here will look familiar. Our Karpenter vs Cluster Autoscaler vs KEDA comparison covers the equivalent Kubernetes-side tooling if you are running both platforms side by side.
GPU scheduling requires the Nomad device plugin for your GPU vendor to be loaded on the client agent. Once the plugin registers the device, request it in a task's resources block with device "nvidia/gpu" { count = 1 }. Do not assume GPU scheduling works out of the box on a fresh client install. It depends entirely on the device plugin being configured first, which is a step even experienced teams skip on their first attempt, usually discovering the gap only after a job sits pending with a constraint error that does not obviously point back to the missing plugin.
Step 10: Build a Complete Three-Tier Project on Nomad
Put everything together into a single job file that deploys a web frontend, an API backend, and a Redis cache as three separate groups inside one job. This is close to what a real small production workload looks like, and it shows how task groups isolate resources while still living under one deployable unit.
job "three-tier-app" {
datacenters = ["dc1"]
type = "service"
group "cache" {
count = 1
network {
port "redis" { to = 6379 }
}
service {
name = "redis"
port = "redis"
provider = "consul"
}
task "redis" {
driver = "docker"
config {
image = "redis:7-alpine"
ports = ["redis"]
}
resources {
cpu = 200
memory = 128
}
}
}
group "api" {
count = 2
network {
port "http" { to = 4000 }
}
service {
name = "api"
port = "http"
provider = "consul"
check {
type = "http"
path = "/healthz"
interval = "10s"
timeout = "2s"
}
}
task "api" {
driver = "docker"
config {
image = "myregistry/api:2026.09"
ports = ["http"]
}
env = {
REDIS_HOST = "redis.service.consul"
}
resources {
cpu = 500
memory = 512
}
}
}
group "frontend" {
count = 2
network {
port "http" { to = 8080 }
}
service {
name = "frontend"
port = "http"
provider = "consul"
}
task "frontend" {
driver = "docker"
config {
image = "myregistry/frontend:2026.09"
ports = ["http"]
}
resources {
cpu = 300
memory = 256
}
}
}
}Deploy it with nomad job run three-tier-app.nomad.hcl and confirm all three groups reach a healthy state with nomad job status three-tier-app. Because every service registers with Consul, the API group can reach Redis at redis.service.consul:6379 without a single hardcoded IP address anywhere in the file. That is the pattern worth carrying into every real Nomad job you write afterward.
Common Pitfalls When Deploying Nomad
Most first-time Nomad problems trace back to a short list of avoidable mistakes, and almost none of them are unique to Nomad itself. They are the same class of error every distributed system punishes: skipping a step that felt optional during a demo but turns out to be load-bearing in production.
- Treating dev mode as a real cluster.
nomad agent -devkeeps no persistent state and has no quorum. It is for learning the CLI and testing job files, not for anything that needs to survive a restart. - Setting the wrong bootstrap_expect value. If this number does not match the actual number of servers you intend to run, the cluster either waits forever for a peer that never joins or elects a leader prematurely with a split-brain risk.
- Mismatched gossip encryption keys. Copy-pasting the encrypt key inconsistently across servers and clients causes agents to fail silently rather than throw an obvious error. Always diff the config files across every host after generating the key.
- Skipping the ACL bootstrap token backup. The management token from
nomad acl bootstrapprints exactly once. Losing it before storing it in a secrets manager means starting the ACL system over. - Assuming GPU or custom device plugins work by default. Device scheduling depends on a plugin being loaded and configured on the client agent first. A job referencing a device that was never registered will sit in a pending state with a vague scheduling failure.
Troubleshooting Common Nomad Cluster Errors
These are the errors that show up most often once a cluster moves past the demo stage, along with the fastest path to a fix.
| Symptom | Likely Cause | Fix |
|---|---|---|
| "No cluster leader" errors in server logs | Fewer than a majority of servers are reachable | Check network connectivity between all three servers on ports 4647 and 4648, verify bootstrap_expect matches your server count |
| Job stuck in "pending" with no allocations placed | No client has enough free resources, or a constraint/device requirement cannot be satisfied | Run nomad job status <job> and read the placement failure summary, then check nomad node status for available capacity |
| ACL "Permission denied" on every CLI command | ACLs are enabled but no token is set in the environment | Export NOMAD_TOKEN with a valid token, or re-run nomad acl bootstrap if the management token was lost |
Client agent never appears in nomad node status | Gossip encryption key mismatch or a firewall blocking Serf ports | Confirm the encrypt key is byte-for-byte identical across agents and that UDP/TCP 4648 is open |
| Consul service registration missing | Job's service stanza still uses provider = "nomad" instead of "consul" | Update the provider field and redeploy the job |
| Vault template never renders secrets | Nomad's Vault integration is misconfigured or the token lacks policy access | Verify the vault stanza address and check the assigned Vault policy grants read access to the requested path |
| Raft errors after replacing a failed server | Stale peer data referencing the old server's address | Use nomad operator raft remove-peer to clear the dead peer before the replacement joins |
| Rolling update replaces every allocation at once instead of gradually | No update stanza defined in the job, so Nomad falls back to default behavior | Add an explicit update stanza with max_parallel and health_check settings to control rollout pace |
Advanced Tips for Production-Grade Nomad Clusters
Once the basics are solid, a handful of operational habits separate a stable Nomad deployment from one that pages someone at 3 a.m. First, separate server and client roles onto different hosts in production. Running both roles on the same node for a demo is fine; doing it in production means a noisy workload can starve the Raft process that keeps your cluster's control plane alive.
Second, back up the Raft snapshot on a schedule with nomad operator snapshot save. A three-server quorum protects against a single node failure, but it does not protect against an operator error that corrupts job state across the board. A snapshot from an hour ago is the difference between a rollback and a rebuild.
Third, use namespaces to separate teams or environments sharing a cluster. Nomad namespaces combined with ACL policies let a staging team run jobs without any visibility into production job specifications, which matters the moment more than one group starts using the same cluster.
Fourth, wire up monitoring before you need it rather than after an incident. Nomad exposes a Prometheus-formatted metrics endpoint on every agent, covering scheduling latency, allocation counts, and Raft health. Pointing a Grafana dashboard at that endpoint from day one turns "the cluster feels slow" into an actual number you can track, and it is also the data source the Nomad Autoscaler's target-value policies read from in Step 9.
Finally, if you are provisioning the underlying servers with infrastructure as code rather than by hand, our Terraform tutorial for AWS infrastructure pairs well with Nomad's own bootstrap process. Terraform can stand up the EC2 instances, security groups, and DNS entries a Nomad cluster needs, then hand off to the Nomad agent configs covered in this guide.
Deploying From CI/CD: Automating Nomad Job Runs
Running nomad job run from a laptop is fine for this tutorial, but production teams want deployments triggered by a merge to main, not a manual command. The good news is that Nomad's CLI is the only tool a pipeline needs; there is no separate deployment controller to install. A GitHub Actions job step can call the Nomad binary directly once it authenticates against the cluster's HTTP API.
- name: Deploy to Nomad
env:
NOMAD_ADDR: https://nomad.internal.example.com:4646
NOMAD_TOKEN: ${{ secrets.NOMAD_DEPLOY_TOKEN }}
run: |
nomad job run three-tier-app.nomad.hcl
nomad job status three-tier-appThe NOMAD_TOKEN secret should map to a scoped ACL policy that can only submit jobs in the relevant namespace, not the management token generated during cluster bootstrap. Teams already running CI/CD for their Kubernetes workloads will recognize the pattern from our GitHub Actions CI/CD tutorial, since the underlying philosophy, keeping deployment credentials scoped and short-lived, carries over directly.
For safer rollouts, pair the pipeline step with Nomad's built-in canary deployments. Adding a canary count to a job's update stanza tells Nomad to place a small number of new allocations, wait for health checks to pass, and only proceed to a full rollout after a manual or automatic promotion. This catches a bad image tag before it reaches every allocation, which matters far more once deployments are triggered automatically on every merge rather than run by hand.
Nomad Licensing and Pricing After the IBM Acquisition
The licensing question comes up in almost every Nomad evaluation, so here is where things stand as of September 2026. Nomad Community Edition runs under the Business Source License, not the Mozilla Public License it originally shipped under before HashiCorp's August 2023 license change. BSL still lets you run Nomad in production for free; the restriction targets companies that would resell Nomad itself as a competing hosted service, not ordinary internal use.
| Tier | License | Typical Use Case | Cost |
|---|---|---|---|
| Nomad Community Edition | Business Source License (BSL/BUSL) | Self-managed clusters, internal production use | Free |
| Nomad Enterprise (self-managed) | IBM Nomad Self-managed Premium Resource Value Unit Flexible Subscription | Multi-cluster governance, advanced ACLs, sentinel policies | Custom, quoted per resource under management |
| HCP Terraform (for comparison, provisioning layer) | Commercial SaaS | Provisioning the infrastructure Nomad runs on | Essentials $0.10/resource/month, Standard $0.47, Premium $0.99 |
For most teams evaluating Nomad for the first time, the Community Edition covers everything in this tutorial, including ACLs, gossip encryption, Consul and Vault integration, and the Autoscaler. Enterprise licensing becomes relevant once you need multi-cluster federation at scale or governance features like Sentinel policy-as-code enforcement across dozens of teams. Full current pricing details live on HashiCorp's pricing page, though note that page occasionally rate-limits automated requests, so checking it directly in a browser is more reliable than scripting against it.
Frequently Asked Questions
Is HashiCorp Nomad still free to use in 2026?
Yes. Nomad Community Edition is free to download and run in production under the Business Source License. The restriction in that license targets companies reselling Nomad as a hosted competing service, not internal or customer-facing production use.
What is the latest version of Nomad as of September 2026?
Nomad 2.0.7 is the latest tagged Community Edition release, published September 18, 2026 on the official GitHub releases page. Organizations that need a longer support window can stay on the 1.10.x long-term support line instead, which has base and extended support through April 2027.
Does Nomad require Kubernetes knowledge to get started?
No. Nomad's job specification format and CLI are designed to be learned independently of Kubernetes. Teams coming from a Kubernetes background will recognize concepts like service discovery and rolling updates, but nothing in this tutorial assumes prior kubectl experience.
Can Nomad run alongside an existing Kubernetes cluster?
Yes. Many teams run Nomad for batch jobs, edge deployments, or legacy workloads that do not containerize cleanly, while keeping their primary container platform on Kubernetes. The two are not mutually exclusive within one organization.
Do I need Consul and Vault to run Nomad?
No, both are optional. A Nomad cluster schedules and runs jobs entirely on its own. Consul adds service discovery and Vault adds dynamic secrets management, but plenty of production Nomad deployments run without either.
How many servers does a production Nomad cluster need?
Three is the standard minimum for high availability, since a three-node Raft quorum tolerates one server failure without losing the ability to elect a leader. Larger deployments sometimes run five servers per region for additional fault tolerance.
What happened to Nomad's license after the IBM acquisition?
Nomad's license did not change as a result of the IBM acquisition, which closed in February 2025. It remains under the Business Source License that HashiCorp adopted in August 2023, before IBM's involvement. IBM did rename the commercial Enterprise subscription tiers under its own product naming conventions.
What is the Nomad Autoscaler and do I need to install it separately?
Yes, the Nomad Autoscaler is a separate binary from the core Nomad agent. It reads scaling policies attached to job groups or cluster nodes and adjusts capacity based on metrics from sources like Prometheus. It needs to be installed and run independently alongside your Nomad cluster.
What are the main alternatives to HashiCorp Nomad?
Kubernetes is the most common alternative, along with lighter Kubernetes distributions like K3s and MicroK8s for teams that want a smaller footprint but still want to stay inside the Kubernetes ecosystem. Docker Swarm is a simpler option for teams that only need basic container orchestration without Nomad's mixed-workload support.
Can I migrate an existing Docker Compose setup to Nomad?
Yes, in most cases. A Docker Compose file's services map fairly directly onto Nomad task groups, with each Compose service becoming a task and each Compose network mapping onto Nomad's network stanza. The migration is usually more mechanical than a Compose-to-Kubernetes conversion because Nomad's job specification stays close to how Compose already models a single application.
Related Coverage
- Gameye Game Server Setup: Deploy Docker in 15 Steps [2026]
- Azure Storage Explorer Setup: Manage Blobs in 13 Steps [2026]
- Amazon Athena Setup: 13 Steps, Query S3 at $5/TB [2026]
- Cloudflare Tunnel Setup: 13 Steps, Free vs $7/User [2026]
- Colyseus Cloud Setup: 12 Steps, $15/Mo, 90 Min [2026]
