A primer on HashiCorp Nomad, a lightweight orchestrator that declares and maintains desired state, schedules containers and binaries, and simplifies deployments for small teams.
At 14 minutes past two in the morning, the disk on Tidepool’s third machine filled up with old log files.Docker stopped.The container running Tidepool’s API stopped with it.And then nothing happened.Nothing moved that work to another machine, and nobody was told.The API stayed down on that box for 31 minutes until a customer in Berlin sent an email asking why her dashboard was empty, and Maya woke up and read it.Tidepool is six people. Customers upload spreadsheets, Tidepool turns them into dashboards, and the whole thing runs on four virtual machines that Maya inherited when she joined.Shipping a new version means opening a terminal, connecting to each machine one at a time, pulling the new image, and starting it again — four machines, four times, in the right order, by hand.
$ ssh maya@box-1$ docker compose pull$ docker compose up -d# repeat for box-2, box-3, box-4
Maya’s first instinct that morning was to fix the disk.
Add a rule that deletes old logs.
Add an alert that warns her at 80%.
Maybe attach a bigger volume.
All sensible responses. But Sam, who had run similar setups before, asked a better question:What actually failed at two in the morning?The disk filling up was not the ultimate failure. Disks fill up. Machines die. Network cards fail. The real failure was systemic: when Machine 3 stopped, the work that had been running on it stayed stopped because the only thing that knew where Tidepool’s software should be running was Maya’s memory.
So what’s needed to reduce those 31 minutes to zero? Three things:
A source of truth — something that holds the answer to “what should be running right now” as data rather than in a person’s head.
A decision-maker — something that decides which machine each piece of software should run on.
A watcher/actor — something that notices when a machine stops responding and moves the work elsewhere automatically.
That combination has a name: an orchestrator — a program whose job is to decide which machine each piece of your software runs on and to move it when a machine stops answering. You declare what should be true, and the orchestrator makes that true and keeps it true.
An orchestrator provides a declarative control plane: you declare the desired state (what to run and how many copies), and the orchestrator continuously reconciles the actual state to match it. This enables self-healing, automated placement, and easier deployments.
Nomad is one of these orchestrators. It’s made by HashiCorp, the same team behind Terraform and Vault. The first thing to know about Nomad is how small and simple it is operationally.
Nomad is a single executable file.
There is no separate database to install alongside it, no complicated set of processes to wire together before anything works — just one binary.
You run the exact same binary on every machine in your cluster. What changes is the mode you start it in.
Start Nomad as a server: those processes join the small group that makes placement decisions. Servers hold the authoritative record of what should be running and decide where work goes.Start Nomad as a client: the same binary reports what that machine can offer (CPU, memory, disk, existing allocations) and runs the workloads the servers assign.Servers decide. Clients do.
Choose the number of Nomad servers deliberately — it determines fault tolerance. The server count is generally odd (1, 3, 5) to ensure a consistent quorum for leader election and to tolerate failures.
Table: Servers vs Clients
Role
Responsibility
Typical Config
Server
Holds cluster state, schedules work, elects a leader
Run on multiple machines (odd number for quorum)
Client
Reports resource availability and executes tasks
Run on every node that should host workloads
Nomad is not limited to scheduling Docker containers. It schedules:
Docker containers
Plain executables (binaries) on disk
Java applications, native services
Virtual machine images (via drivers)
Tidepool’s log shipper is a binary Maya copies by hand today; Nomad can run that binary under the same scheduling and lifecycle rules as the API container.
Once an orchestrator is in the middle, you stop naming machines.Instead of: “deploy to machine-1, machine-2, machine-3, machine-4,” you declare the work and how many copies of it you want. The orchestrator then answers the question “where” and keeps those copies running across the cluster.
But Maya works at a company with six people and no platform team, which begs the same question Tidepool’s founder asked her the next morning:Why aren’t we running Kubernetes like everyone else?If you want to evaluate Nomad versus Kubernetes, consider these factors:
Operational complexity: Nomad is a single binary with a simpler operational model; Kubernetes is more feature-rich but operationally heavier.
Workload types: Nomad handles containers and non-container workloads natively; Kubernetes primarily targets containers (with some ways to run non-container workloads).
Ecosystem and integrations: Kubernetes has a larger ecosystem of controllers, CRDs, and managed services; Nomad integrates smoothly with HashiCorp tools (Consul, Vault) and focuses on simplicity.
For small teams who want a lightweight, flexible scheduler that can run containers, binaries, and VM images with minimal operational overhead, Nomad is worth evaluating. It gives you the three essential capabilities that fixed machines and SSH-based deploys lacked: a source of truth, an automated decision-maker, and automatic recovery when things fail.
