Skip to main content
Let’s rewind to 14 minutes past 2:00 AM on the same host: the disk fills, Docker stops, and the container running Tidepool’s API goes down. Nomad detects the node is unresponsive, creates an evaluation, and the scheduler produces a plan to replace the work that was running on that node. The leader accepts the plan and a new allocation starts on a machine with capacity. The replacement instance comes up, authenticates to Vault using an identity it cannot forge, retrieves its database credentials, renders configuration from a template variable, registers itself under the service name the frontend queries, and begins answering requests. The other two replicas carried traffic while this happened, nobody was paged, and no customer in Berlin emailed support.
A slide showing a failure flow: a disk fills, Docker stops, and the allocation moves so "the other copies carry the traffic." Four replica boxes (box-1 to box-4) with server and Docker icons are illustrated.
Maya checked the allocation events the next morning just out of curiosity and read the audit trail there. The incident looked routine to her because Nomad had automated the replacement and registration steps. Operationally, this workflow implies a few deliberate design choices.

​
She stopped naming machines

Treating hosts as fungible resources changes how you design and operate services:
  • Run multiple replicas rather than depending on a single named host.
  • Use service discovery so frontends look up services by name instead of by IP.
  • Avoid baking secrets into images; tasks should authenticate with a machine/task identity and retrieve credentials from a secrets store such as Vault.
  • Accept that a task might start on any node the scheduler chooses, so make tasks stateless where possible and parameterize configuration.
Each change follows from the previous one: fungible nodes → more replicas → service discovery → identity-based secret delivery → safer, more resilient deployments.
An infographic titled "She Stopped Naming Machines" that uses icons and short captions (no names, many copies, announced by name, identity not a password) to explain machine naming and identity. The right side reads "Maya read about it the next morning," and the bottom shows server/container illustrations labeled box-1 through box-4.

​
What Nomad does not provide out of the box

Nomad is a compact, flexible orchestrator, but it intentionally focuses on core scheduling and allocation. There are a few gaps you should plan for:
  • It does not autoscale workloads automatically by itself; scaling is declared in the job spec. Use the Nomad Autoscaler when you need dynamic scaling.
  • Its built-in service discovery reports health but does not perform advanced filtering to remove unhealthy instances from results — running Consul provides richer health checks and service discovery semantics.
  • Nomad does not include a service mesh; integrate with Consul or another mesh provider for mTLS, traffic control, and observability.
  • The ecosystem and third-party integrations around Nomad are smaller than those for some other orchestrators; you may find fewer ready-made plugins or community answers for niche issues.
A presentation slide titled "What Nomad Does Not Do" that lists limitations: no autoscaling alone, no health filtering, no mesh without Consul, and a smaller ecosystem. The slide includes illustrative icons (graph, lifebuoy, globe, Docker/servers) and four server boxes labeled box-1 through box-4.
Nomad reduces host-level operational work and gives you a simpler control plane for mixed workloads. However, you should account for the extra components (Autoscaler, Consul, Vault) and the people required to operate them when estimating operational effort.
Therefore, count the people and the operational tasks required to run the system. If your team is small and your workloads are mixed, Nomad often delivers most of the benefits of a larger orchestrator while keeping your operational footprint leaner.

Watch Video