Nomad

✅ When is it appropriate

Nomad is suitable if most of the following apply:

the team needs to run applications on multiple servers and restart failed ones automatically, but does not want the setup complexity of Kubernetes
the cluster has tens to a few hundred nodes and does not require the advanced scheduling features Kubernetes provides at very large scale
the system needs to schedule a mix of Docker containers, standalone binaries, or batch jobs on the same cluster without maintaining separate orchestration tools for each type
the team is already using HashiCorp's Vault for storing secrets or Consul for service-to-service communication, and wants to keep tooling consistent
the priority is getting a cluster running quickly with a simple HCL job file rather than learning a large set of Kubernetes concepts and YAML manifests

Nomad uses a single binary for both the server and the client, so a basic cluster can be running in under an hour. Jobs are defined in HCL files that are shorter and less verbose than the YAML manifests Kubernetes requires, which lowers the barrier to getting started.

❌ When is it NOT appropriate

Nomad may not be ideal if:

the project relies on Kubernetes-specific tools such as Helm charts, custom resource definitions, or operators that have no equivalent in Nomad
the cloud provider offers managed Kubernetes services that simplify cluster management, and the team wants to take advantage of those integrations
the organisation requires all infrastructure to follow a single company-wide standard and that standard is already Kubernetes
the system needs a built-in service mesh with automatic mTLS between services, which Nomad does not provide natively and requires adding Consul Connect or a separate solution

Nomad does not have equivalents for every Kubernetes concept. Tools like Helm for package management, custom resource definitions for extending the API, or advanced admission controllers have no direct counterpart in Nomad. If the project depends on that ecosystem, Kubernetes is the more practical choice.

👍 Advantages

a basic cluster can be set up with a single binary; no separate control-plane components or certificate authorities to configure before the first job can run
running and updating jobs requires fewer moving parts than Kubernetes, so there is less to break and less to monitor
the core concepts fit on a single page; most teams can schedule and manage jobs confidently within a day of learning
Docker containers, standalone executables, Java applications, and batch scripts can all be scheduled by the same Nomad cluster without separate tools
integrates directly with Vault for injecting secrets into jobs and with Consul for automatic DNS-based service discovery between jobs
does not follow rapid release cycles with breaking changes; the configuration format and API stay stable across versions

👎 Disadvantages

fewer third-party tools and plugins exist compared to Kubernetes; some integrations must be built manually
managed Nomad services from cloud providers are rare; running Nomad in production means managing the cluster yourself
fewer engineers have Nomad experience, which can make hiring and onboarding harder
because it is less widely adopted, less community-written documentation, tutorials, and Stack Overflow answers are available

🛠️ Typical use cases

small to medium production clusters
mixed workloads (containers, VMs, batch jobs)
teams using HashiCorp tools like Vault and Consul
projects prioritizing simplicity and low overhead
lightweight CI/CD pipelines
internal tools and self-hosted services

⚠️ Common mistakes (anti-patterns)

using Nomad to run a very large cluster with thousands of services requiring advanced scheduling policies; at that scale Kubernetes has more mature tooling and a larger support community
assuming Nomad can replace every Kubernetes feature without checking; features like custom resource definitions, admission webhooks, and managed cloud integrations do not exist in Nomad
deploying without setting up log aggregation and health checks; failed allocations are hard to diagnose without centralized logs and alerting
adopting Nomad when the rest of the organisation uses Kubernetes, creating two separate orchestration platforms that the team must maintain and learn simultaneously
trying to replicate a complex Kubernetes service mesh architecture in Nomad without Consul Connect; the result is manual networking configuration that is fragile and hard to audit

The most common mistake is adopting Nomad and then gradually needing features it does not have. Before committing, check whether any required integrations such as Helm charts, cloud-provider managed services, or Kubernetes operators have a Nomad equivalent, or whether they would need to be rebuilt from scratch.

💡 How to build on it wisely

Recommended approach:

Begin with a small cluster and minimal configuration.
Integrate Vault so that jobs receive secrets such as database passwords and API keys at runtime without storing them in job files or environment variables; integrate Consul so services can find each other by name rather than hardcoded IP addresses.
Run containers, VMs, or batch jobs as needed.
Use namespaces or job groups to isolate dev, staging, and prod.
Add logging, metrics, and alerts early.
Use Nomad's periodic job scheduler for tasks that need to run on a fixed schedule, such as nightly database backups or hourly report generation, instead of managing separate cron jobs on individual servers.
Expand cluster and workloads based on real usage and feedback.

Nomad is the right choice when a team needs multi-server orchestration without the full complexity of Kubernetes. The signal to reconsider is when the project requires Kubernetes-specific integrations that have no Nomad equivalent, when the organisation standardises on Kubernetes, or when the cluster grows to a scale where Kubernetes' more advanced scheduling features become necessary.

Feedback & Sharing

Give us your thoughts on this page, or share it with others who may find it useful.

Share with your network:

Feedback

Found this helpful? Let me know what you think or suggest improvements 👉 Contact me.