Nomad vs Kubernetes vs Docker Swarm: which to choose?

WebDisk Blog · category: Public cloud · reading time: ~22 minutes

In short:- These are not three versions of the same tool. Swarm is a feature of the Docker engine you already have; Kubernetes wants to be a platform and hands you the choice—and the upkeep—of networking, storage and ingress; Nomad confines itself to a single role: a workload scheduler.- Nomad's biggest advantage over Kubernetes has nothing to do with containers. It is one binary, one deployment file, and drivers that also run plain processes and Java applications—without packaging each of them into an image.- Choose by the cost of running it, not by the feature list: up to ten nodes—Swarm; mixed workloads and a small platform team—Nomad; large scale and regulatory requirements—Kubernetes. Nomad's price: the BUSL 1.1 licence (the licensor is IBM) and the end of the long-term support (LTS) branch on 30 April 2027. >Not a terminal person? Skip the code blocks—the description of the differences, the "How to choose?" section and the part on risks give you the full picture without a single command.

A conversation about container orchestration these days usually opens with "right, we'll take Kubernetes" and ends six months later with the question of who is actually supposed to run it. Between those two moments sits a whole class of decisions that are far easier to make at the start than to unwind later: how many layers do you really need, how many of them will somebody in the company be able to fix at three in the morning, and what happens when the tool's author changes the licence.

An orchestrator is a program that makes sure the declared number of copies of an application is running on the available servers: it picks the machine itself, moves a workload after a node fails, swaps a version without downtime, and records where a given service is currently running. In practice the choice today comes down to three tools: Docker Swarm, HashiCorp Nomad and Kubernetes—with the caveat that only the last of them is measured at all in the largest industry surveys.

This article shows how they differ not in terms of a feature table but in philosophy—and then gets concrete: what a deployment file looks like in Nomad, how to ship a new version using a canary release (one instance of the new version next to the old one, to be checked live), how to run an application that exists in no image at all, and where Nomad genuinely beats Kubernetes and where it just as genuinely loses. We are writing this for teams facing the choice for the first time, and for those that already have Kubernetes—and are starting to suspect it was a size too large for their scale. All figures and dates come from primary sources and are current as of the end of August 2026; where a number comes from vendor material rather than from a measurement, we say so outright.

What really separates Nomad, Kubernetes and Docker Swarm?

The most common mistake in comparisons is lining up feature lists. The difference starts earlier—in how broadly each tool defines its own responsibility.

Kubernetes wants to be a platform. It has APIs for networking, storage, policies, ingress and permissions. But "built-in" here usually means "a built-in interface plus an external implementation that you choose and then maintain". Kubernetes does not supply networking—it defines a model, and the work is done by CNI plugins (the standard for attaching containers to a network). Storage is CSI (the standard for attaching disks). Incoming traffic is Ingress—an interface frozen feature-wise, whose successor is the Gateway API. How painful that arrangement can get was shown in 2026: ingress-nginx, the most popular ingress controller, was retired by the project's networking team along with its security patches. A component carrying production traffic for thousands of companies changed underneath them.

Nomad wants to be nothing but a scheduler—and says so plainly in its own documentation: Kubernetes aims at the full set of features needed to run containerised applications, while Nomad focuses on cluster management and workload scheduling. The rest is delegated: the full service layer to Consul, secrets to Vault or OpenBao (separate products from the same vendor), networking beyond host and bridge mode to CNI, storage to CSI, autoscaling to a separate daemon. This is not an omission—it is a design decision with its own price and its own reward.

Docker Swarm implements everything itself, but the scope is narrow. Without installing anything extra you get cluster management from the ordinary Docker CLI, a declarative service description, scaling, an overlay network (a virtual network stretched over the real server network), service discovery through DNS with load balancing, rolling updates and—worth appreciating—mutual TLS authentication between nodes enabled by default, with certificates renewed every three months. What you do not get is namespaces or role-based access control in the engine itself, autoscaling, or mature storage support.

Where does the boundary of "one application" run in each of these tools?

This distinction determines how you will describe deployments for years to come.

Docker Swarm—there is no co-location layer (a task is a single container); the unit of scaling is the service; the whole thing is described by one Compose file with N services.
Nomad—co-location and scaling are the same thing: the group; the entire application is described by one job specification file.
Kubernetes—co-location is the pod, scaling is the Deployment (via a ReplicaSet); one application is usually 4–8 objects, often across several files.

Three things follow from this that are worth knowing before you choose:

Swarm has no co-location layer. A helper container—a network proxy, a log-collecting agent, a metrics exporter—is a separate service in Swarm, so it loses the guarantee of sharing a network namespace and a volume with the application. That blocks an entire class of architectures, not merely a convenience.
In Nomad the group is declared explicitly; in Kubernetes the pod appears as a side effect. In Kubernetes you describe a template inside a Deployment object and get pods you did not create yourself and that cannot be moved—they can only be created anew. In Nomad you write a group and you know it is simultaneously the unit of co-location and of scaling.
What in Kubernetes are separate kinds of object is a single field in Nomad. type = "service" corresponds to a Deployment, type = "batch" to a Job object, type = "system" to a DaemonSet, and type = "sysbatch" to a one-off workload run once on every matching node, which has no direct counterpart in Kubernetes. One file, one field, four behaviours.

There is one further difference that the Kubernetes documentation states itself: Kubernetes is not an orchestrator in the "do A, then B" sense, but a set of independent control loops driving current state towards the desired one. The consequence is thoroughly practical—there is no single place where you can watch a deployment unfold. In Nomad there is: nomad deployment status.

Is Docker Swarm dead? Not the one you are thinking of

The line "Swarm is dead" keeps circulating online. It is true and false at the same time, because it concerns two different things.

Docker Swarm "classic"—a separate 2014 product that tied together multiple Docker daemons—is indeed closed: the repository was archived on 1 February 2021, the image on Docker Hub carries a "deprecated" label, and support was removed from the engine in version 23.0. That is what most of the circulating "deprecation notices" are about.

Swarm mode, that is the mode built into Docker Engine since version 1.12, has no announced end-of-support date. The code is maintained: the moby/swarmkit repository has not been archived, and commits on the main branch date from the end of August 2026. The Docker Engine 29 line brought Swarm concrete fixes, including a fix for corrupted Raft snapshots with a large cluster state. Fairness requires the other half of the story, though: Docker's only official statement on the subject sits on the "deprecated and retired products" page and says that Swarm mode remains functional, but development has slowed in favour of Kubernetes-based solutions.

Swarm's practical limits are worth knowing before you bet on it:

There is no autoscaling. The issue proposing horizontal service scaling has sat open in the repository since August 2017—with no implementation.
CSI storage support is experimental: no snapshots, cloning or volume expansion.
docker stack deploy uses the old Compose version 3 format, incompatible with the current Compose specification. Some keys are silently ignored—the deployment prints a warning and carries on. "It works in Compose" and "it works in the stack" are two different statements about the same file.
Secrets are encrypted at rest, configs are not—and they land directly in the container's filesystem. The limit for both is 500 kB.
The recommended maximum is seven manager nodes, and a cluster of N such nodes survives the loss of (N−1)/2 of them. Swarm publishes no scalability thresholds at all.
There is also a signal worth watching when planning for the coming years: on a node with Swarm enabled you currently cannot enable nftables, and nftables is due to become Docker's default firewall mechanism—although the vendor gives neither a version nor a date.

Commercial support is offered by Mirantis. A July 2025 post declares support for Swarm "at least until 2030" as part of MKE 3, while the published lifecycle matrix currently reaches March 2028, and MKE 4 is already a Kubernetes-only product. Those two sources cover different horizons, so for multi-year planning the end-of-support date has to be confirmed with the vendor in writing.

When does Swarm make sense? When you have from a few to a dozen or so nodes, one team, predictable traffic and nobody whose full-time job is to maintain a cluster. That last point matters more than it seems: a Kubernetes cluster stood up by hand with kubeadm and left untouched for a year will simply stop working, because the one-year control-plane certificates expire—and only an upgrade renews them. In a managed service the provider does that for you. Swarm under those conditions ages more slowly. Mirantis's own data, incidentally—published in 2022 and repeated word for word in 2024, with no disclosed methodology—works out to an average of about ten nodes and a hundred containers per cluster. In the real world Swarm is not used to build large clusters, but many small ones. That is its honest niche, not a failure.

What does Kubernetes really cost before you serve your first application?

Kubernetes is today's default choice and has solid reasons for it: the Apache 2.0 licence, neutral governance under the CNCF foundation, the largest ecosystem and managed services from every major provider. According to the CNCF survey 82% of container users run Kubernetes in production (mind the base: that is a share of container users, not of all organisations).

The price, however, is countable, and it is worth seeing in numbers rather than in adjectives:

The control plane is a set of separate processes: the API server, the etcd database, the scheduler, the controller manager, and on the node the kubelet and a container runtime. On top of that CNI and CoreDNS, without which the cluster is practically non-functional.
The conceptual surface is large and countable: the official API reference lists 22 API groups. To serve a single HTTP application in production you have to understand pods, Deployment, ReplicaSet, Service, Ingress or the Gateway API, namespaces, ConfigMap, Secret, PVC/PV/StorageClass, resource requests and limits, three kinds of probe, a service account with a role and a binding, network policies—plus pick Helm or Kustomize, a CNI and a CSI.
Upgrades are an obligation, not an option. The three most recent branches are supported (currently 1.37 "Garhwal", released on 26 August 2026), and the support window for a single release is around 14 months. The API server cannot skip a release—versions are raised one at a time. What that costs is best seen in the price list: in Amazon EKS the control plane is 0.10 USD per cluster per hour, and extended support for an older version is 0.60 USD, six times more purely for not upgrading.
Scale is measured and published: up to 110 pods per node, up to 5,000 nodes, up to 150,000 pods. That is in fact an advantage, not a flaw—the other two tools publish no such thresholds. You just need to read them as written: these are measurement limits, and pushing two dimensions at once will break the cluster considerably earlier.

A frequent misunderstanding: k3s. That distribution genuinely lowers the cost of installation and resource consumption, but it does not lower the conceptual cost one iota—it is certified Kubernetes with the same API. Anyone reaching for k3s so that "Kubernetes will be simpler" is solving a different problem from the one they have. What good maintenance of such a cluster looks like—upgrades, backing up the etcd database, observability, on-call rotas—we covered separately in the article Kubernetes technical support: standing up the cluster is the easy part. How the cost of a tool translates into dependence on its author is in turn the subject of the article Vendor lock-in in the public cloud.

What do you get when the orchestrator is a single binary?

Nomad is a single program written in Go which, depending on its configuration, runs as a server or as a client. There is no external database—state consistency is provided by the built-in Raft consensus algorithm (a mechanism in which servers agree on one shared version of the truth), so there is no etcd equivalent to back up, upgrade and tune. A production region is three or five servers: three survive the failure of one, five the failure of two. The point is quorum, the majority that has to agree for the cluster to make decisions. The vendor sets no published threshold on the number of clients.

Scale is increased by adding regions, not by fattening the quorum. Regions are fully independent—they share neither workloads, nor clients, nor state—and are joined by a lightweight information-exchange protocol between servers (gossip), thanks to which an API call carrying a region parameter reaches the right region on its own. Access policies, roles, namespaces, node pools and quotas replicate from the authoritative region. By comparison: in Kubernetes multi-region is a problem of architecture rather than configuration—the KubeFed project has been archived, and the group working on multiple clusters deliberately ships an API with no reference implementation.

Two caveats, without which this picture would be an advertisement:

The multiregion block in a job specification requires the Enterprise edition and does not provide automatic failover between regions. Federating regions is not the same thing as high availability across locations.
Nomad's documentation says it plainly: "Nomad is not secure-by-default"—and access control lists (ACLs) are disabled by default. A cluster stood up in a hurry and exposed without turning them on is not a theoretical risk.

Three words that will keep coming back

Before you look at the first file: three concepts that everyday speech would happily lump together as "a task"—so let us separate them straight away.

job—the whole description of an application: one file, one name, one version. This is what gets deployed, rolled back and stopped.
task—a single process or container inside a job.
allocation—one copy of a task group running on a specific client, the counterpart of a pod in Kubernetes. Scaling to three instances means three allocations; a node failure means an allocation disappears and a new one is created elsewhere. If you see alloc in a command, this is what it means.

Nomad is described in HCL (HashiCorp Configuration Language)—the same configuration language as Terraform: blocks nest inside curly braces, indentation means nothing, and the language itself has variables, expressions and loops. Below is a complete file: two instances of a web application, resource limits, a dynamic port, service registration and a health check.

job "webapp" {
  # type defaults to "service"; stated explicitly for readability
  type = "service"
  datacenters = ["dc1"]

  group "web" {
    count = 2

    network {
      # a port without "static" = a dynamic port assigned by Nomad on the host;
      # "to" says which port the traffic reaches INSIDE the container
      port "http" {
        to = 8080
      }
    }

    service {
      name = "webapp"

      # NOTE: the default value is "consul". Without this line Nomad tries to
      # register the service in Consul and the job will not start if Consul is absent.
      provider = "nomad"

      port = "http"
      tags = ["web", "public"]

      check {
        # with provider = "nomad" ONLY the "http" and "tcp" types are allowed.
        # The check block inherits the port from the service - no need to repeat it.
        type = "http"
        path = "/health"
        interval = "10s"
        timeout = "2s"
      }
    }

    task "server" {
      driver = "docker"

      config {
        image = "hashicorp/http-echo:1.0"
        args = ["-listen", ":8080", "-text", "hello from nomad"]
        ports = ["http"] # a list of port LABELS from the network block
      }

      resources {
        cpu = 200 # MHz - Nomad reserves clock, not a fraction of a core as K8s does
        memory = 256 # MB
      }
    }
  }
}

Four things most beginners trip over—worth knowing before you lose an evening to them:

provider defaults to "consul". Without an explicit provider = "nomad", a workload in a cluster without Consul will not start. This is the most common start-up mistake.
With native registration, only http and tcp checks are allowed.
Ports are declared exclusively in group -> network and referenced through ports = [...] in the task configuration. Nomad injects the variables NOMAD_ADDR_<label>, NOMAD_PORT_<label> and NOMAD_IP_<label> into the task.
The native registry gives you no DNS. With provider = "nomad" there are no names of the webapp.service.consul sort; the address and port are read from the API, from nomad service info or from a template block. Anyone who types a service name as a hostname gets a name-resolution error and usually goes looking for it somewhere else entirely. This is one of the things Consul adds.

It is also worth debunking two myths that circulate in both directions. "Nomad does not work without Consul" is untrue—native service discovery has existed since version 1.3, and health checks for it since 1.4. But "Nomad does not need CNI" is an oversimplification—bridge networking mode requires CNI plugins on all Linux clients.

How do you ship a new version with no downtime and without waking anyone up?

The whole mechanism of a safe release fits into one block that you add to the group:

update {
  max_parallel = 2 # how many allocations are replaced AT ONCE (default 1)

  # how Nomad knows an allocation is healthy:
  # "checks" - the tasks are running AND the service checks are green (default)
  # "task_states" - it is enough that the tasks have started
  # "manual" - health is declared by an operator through the API
  health_check = "checks"

  min_healthy_time = "30s" # how long it must stay healthy to count as good
  healthy_deadline = "3m" # deadline for a SINGLE allocation
  progress_deadline = "10m" # PROGRESS deadline for the whole deployment; must be > healthy_deadline

  auto_revert = true # after a failed deployment, go back to the last STABLE version
  canary = 1 # how many canaries to stand up NEXT TO the running version
  auto_promote = false # false = promote by hand: nomad job promote webapp
}

A canary is a single instance of the new version running alongside the old one. Nomad does not switch traffic itself—it registers the canary under separate tags (canary_tags) and waits for your decision; it is your proxy that decides whether and when it starts sending requests to it. Until nomad job promote, the old version keeps working untouched. auto_revert, in turn, means a failed release returns by itself to the last working version, without waking anyone up.

One trap worth remembering: health_check = "checks" with no check block defined means a deployment that will never confirm health and will only fail on progress_deadline. This is the most frequent cause of "hanging" deployments.

Will the orchestrator run an application that exists in no container image?

If you had to name one thing that separates Nomad from the other two tools on a "can/cannot" basis, it would be the architecture of task drivers. Five are built into the binary: docker, exec, raw_exec, java and qemu—with the proviso that raw_exec runs a process with no isolation whatsoever and is therefore disabled by default. Three more official ones are installed separately: exec2, podman and virt. A driver is a plugin—you can write your own without recompiling Nomad.

In practice this means that the same scheduler, the same permissions and the same deployment mechanism handle a container, a plain process, a JAR archive and a virtual machine. Below is a legacy service run as a bare process—with no Docker on the host and no image build:

# FRAGMENT: a task block always sits inside job -> group -> task.
# The job skeleton is identical to the example above - what changes is
# ONLY the driver and config (port "http" comes from the group's network block).
task "api" {
  # isolated fork/exec: chroot (the process sees only a carved-out part
  # of the filesystem) + namespaces, ZERO Docker on the host
  driver = "exec"

  artifact {
    source = "https://artifacts.example/download/my-app-1.4.2"

    options {
      # checksum lives INSIDE options. Always verify - artifact downloads over the network.
      checksum = "sha256:0f5e...replace-with-the-real-one"
    }
  }

  config {
    command = "local/my-app-1.4.2" # the default artifact target is the local/ directory
    args = ["--listen", "${NOMAD_ADDR_http}"]
  }

  resources {
    cpu = 300
    memory = 256
  }
}

The rest of the file—job, group, network with a dynamic port and service with a health check—looks exactly the same as in the first example; that is the whole point. A task block on its own, however, cannot be deployed separately.

A Java application is run in the same way—only the driver and its configuration change (jar_path, jvm_options). The exec2 driver goes a step further: it isolates the process with native kernel mechanisms (cgroups v2, Landlock), with no container image and no chroot.

What does the same thing look like on the other side? In Kubernetes the model is container-based by definition. A virtual machine requires the KubeVirt project, that is a VM packaged into a pod—an extra layer and an extra system to maintain. A bare binary in practice always ends up in an image (if only FROM scratch), which forces a registry and a build pipeline for every application, including one that is a single file. In Swarm a task is a Docker container and a command—the list ends there.

One caveat, without which this would be an advertisement: the virt driver, which runs full virtual machines through libvirt, is flagged by the vendor itself as under active development and not intended for production.

What do a nightly job and a per-node agent look like?

Two further types show just how much fits into the single type field.

A periodic job—a database dump run every night:

job "nightly-db-dump" {
  # periodic works ONLY for the "batch" and "sysbatch" types
  type = "batch"

  periodic {
    # "crons" is a list of expressions; the "cron" field (singular) is deprecated since 1.6.2
    crons = ["0 3 * * *"]
    prohibit_overlap = true # do not start while the previous run is still going
    time_zone = "Europe/Warsaw" # UTC by default
  }
  # ...
}

Two things that cost people their data: the output of such a job has to leave the allocation directory, because that disappears along with it—you need a host volume or a push of the copy to object storage. And the second: an existing job cannot be turned into a periodic one in place—it has to be stopped with the -purge option. How a backup differs from a replica we covered at greater length in the article Cloud backup: the 3-2-1 rule, RPO/RTO and the copy ransomware cannot delete.

A system job—one allocation on every matching node, like a DaemonSet in Kubernetes; new nodes get it automatically when they join:

job "node-exporter" {
  type = "system" # in a "system" job you do NOT set count

  constraint {
    attribute = "${attr.kernel.name}"
    value = "linux"
  }
  # ...
}

A difference between versions that can catch you out on long-term support: deployments for system jobs only exist from Nomad 1.11.0 onwards. On the 1.10.x branch the update block will not behave for them the way the documentation for newer releases suggests.

Which commands do you start with in Nomad?

The shortest route to your own experiment is nomad agent -dev—a single-node in-memory cluster started with one command. A production cluster is the same program, only with a configuration file and a server or client role.

# dry run against the server: the diff versus current state + the scheduling result.
# Exit codes: 0 = nothing will change, 1 = there will be changes, 255 = error
nomad job plan webapp.nomad.hcl

# deploy
nomad job run webapp.nomad.hcl

# job state and deployment progress (with canaries: the Promoted / Canaries columns)
nomad job status webapp
nomad deployment status -monitor <deployment-id>
nomad node status

# the native service registry - works with provider = "nomad", not in Consul
nomad service list
nomad alloc checks <alloc-id>

# logs of a single allocation and of the whole job
nomad alloc logs -f <alloc-id> server
nomad alloc logs -job webapp -tail -n 50

# canary promotion and rollback to an earlier version
nomad job promote webapp
nomad job history -p webapp
nomad job revert webapp 3

Worth knowing: nomad job validate is not offline validation—the command sends the job to the server, so without a reachable cluster address it will not work.

Who actually uses Nomad?

That question calls for a careful answer, because Nomad's public references are mostly old, and a company can change its stack without announcing it. Below are only deployments described in primary sources—each with its year of publication, because none of them should be read as the state of play today:

Cloudflare (2020)—maintenance services and restart management in every edge data centre, five Nomad servers per location; the choice was motivated among other things by the drivers for plain binaries.
Internet Archive (2021)—more than a hundred deployments moved from Kubernetes to Nomad with Consul.
Q2 (2020)—online banking: more than 7,000 jobs, more than 40,000 tasks, 1,500 virtual machines, mostly in their own data centre.
Lob (2022)—consolidation of several platforms onto Nomad; the team describes its earlier Kubernetes attempt as abandoned.
Behavox (2023)—microservice management; the most recent public account of a move to Nomad that we were able to find.

Fairness requires showing the traffic in the other direction, because it is just as well documented. SeatGeek described a migration from Nomad to Kubernetes in November 2024—when rebuilding its CI build machines, the average wait time fell from 16 to 2 seconds. Fly.io replaced Nomad with its own orchestrator in 2023, giving three reasons: bin-packing workloads to minimise hardware where the platform needed headroom; the assumption of federated regions instead of one global cluster; and the lack of synchronous scaling from zero on a named server.

It is also worth knowing the deployment context of the only public reference confirmed more recently than a year ago. CircleCI describes, in documentation from May 2026, the default architecture of its self-hosted CircleCI Server product: Nomad servers run there as a service inside the customer's Kubernetes cluster—and since version 4.8 the vendor allows them to be moved out onto separate virtual machines. That disqualifies neither tool; it shows that in larger organisations both are sometimes used side by side, for different jobs.

Where does Nomad genuinely beat Kubernetes?

The cost of adopting and running the tool itself. One binary in a server or client role, built-in consensus, no separate state database with its own release cycle. Cluster state still has to be protected with backups, but the same binary does it rather than a separate system—with the caveat that automating those backups is an Enterprise feature.
Non-containerised workloads without adding a second system. The same scheduler, the same permissions and the same deployments for a container, a process, a Java application and—with the maturity caveat—a virtual machine.
Multi-region is a configuration problem, not an architectural one. One API entry point and one token to manage many clusters, replication of policies and namespaces from the authoritative region. With the caveats from a few sections back: state does not replicate between regions, and the multiregion block is an Enterprise feature.
Templating is in the language itself, not in a layer on top of it. HCL2 has variables, expressions, functions and loops. YAML has none of them—it is not a language, only a data serialisation format—hence the whole superstructure: Helm, Kustomize, jsonnet. Helm templates YAML as text, so an indentation error only surfaces after rendering. Caveat: HCL2 is evaluated on the operator's CLI side and the server receives a ready-made structure—this is not a runtime secrets mechanism (the template block serves that purpose).
Fewer concepts before your first production deployment—a dozen or so, and all of them fit into one file and one CLI.
One place where you can see the deployment. That sounds trivial until you have to explain to somebody why a deployment has stalled.

What we will not write, however, although it circulates online: that Nomad is faster than Kubernetes. No independent test comparing these tools exists. The famous "two million containers" result comes from a vendor benchmark from 2020, in which alpine containers were started with a sleep command, with a 30 MB memory reservation, with no network configuration and with deployments disabled. It measures the scheduler's throughput, not a cluster's survivability under production traffic. Nor did we find any credible measurement of the Nomad agent's memory consumption in a primary source—all the circulating figures are unverifiable, so we do not quote them.

Where does Kubernetes genuinely beat Nomad?

An honest comparison has to make this section as strong as the previous one.

Licence and governance. Apache 2.0, the CNCF foundation, vendor neutrality. Nomad is under a licence that makes the code available but does not grant open-source freedoms—and the licensor is IBM.
Things you pay for in Nomad are free in the Kubernetes core. Behind the paid Nomad Enterprise edition sit, among others: audit event logging, resource quotas, policies (Sentinel), automated upgrades and backups, redundancy zones and multi-region deployments. This is the most frequently omitted cost in such a comparison.
Ecosystem. The "operator plus custom resource type" pattern lets you extend the cluster's data model and operate it with the same tools. Nomad has no equivalent. The Artifact Hub catalogue lists more than 21,500 packages of all kinds—not just Helm charts, but operators and plugins too—while Nomad Pack, the Helm equivalent, never reached version 1.0 (the latest is 0.4.2).
Security and multi-tenancy in the core. Network policies for microsegmentation, role-based access control for any resource type, admission control for objects. The counterpart to network policies on the Nomad side is Consul intentions—that is, a separate product under the same licence.
A mature stateful layer. StatefulSet and operators for databases, queues and caches in a high-availability configuration. On top of that: some CSI drivers written for Kubernetes will not work in Nomad, because they use calls specific to that platform.
Autoscaling in the core. Horizontal autoscaling is part of the control plane. The Nomad Autoscaler is a separate daemon and a separate binary, and its most advanced part—automatic application right-sizing—is Enterprise-only.
Managed services and the skills market. Managed Kubernetes is offered by all three hyperscalers, and the CNCF conformance programme covers more than 90 certified offerings; the full set of five CNCF Kubernetes certifications (the Kubestronaut title) is held by more than 3,500 people in over 100 countries. Managed Nomad is not available at the hyperscalers, and Nomad did not even appear in the Stack Overflow 2025 survey questionnaire—which does not mean "zero usage", but it says something about scale.

Is Nomad a safe choice for five years? The licence, the owner and the end of LTS

This section stands apart because it concerns something different from the rest: not what the tool can do, but how long you can base a plan on it.

The licence. In August 2023 HashiCorp moved from MPL 2.0 to the Business Source License 1.1. Nomad is on the list of covered products, and BUSL is not a licence recognised as open source by the OSI. The licence file on the current branch names International Business Machines Corporation as the licensor, sets the change date at four years from the publication of a given version, and gives MPL 2.0 as the target licence.

What does that mean in practice? What follows is a reading of the licence text, not legal advice—and the binding interpretation of the scope of the additional grant is set by the licensor. The reading suggests that hosting and using the covered software for an organisation's internal needs is not treated as a competing offering, and that the restriction targets offering Nomad to third parties for a fee in a way that competes with the vendor's paid edition—so scenarios of the "managed Nomad as a service" kind, or paid support sold around Nomad itself. Exactly where that line runs in your business model will be settled by a lawyer, not by an article.

One trap that is easy to walk into: you cannot "stay on the last MPL version" by picking the 1.6.x branch. The last release unambiguously under MPL 2.0 is 1.6.3 of 30 October 2023—from 1.6.4 onwards the licence files in the repository already point to BUSL.

No fork under a neutral foundation. Terraform got OpenTofu, Vault got OpenBao. Nomad has no equivalent. If the terms change, the alternative is not a fork but migration to a different orchestrator—and that is an entirely different calculation.

A single owner, post-acquisition. IBM's acquisition of HashiCorp closed on 27 February 2025. Among the changes: the licensor today is IBM, versioning has moved to a corporate model, and Enterprise licences are sold through the IBM channel. There is no statement of any kind about the future of Nomad's licence—neither about tightening it nor about a return to an open model. That is an absence of information and should be treated as such.

The support lifecycle—the hardest argument in multi-year planning. From version 2.0 Nomad abandoned semantic versioning. The latest release is 2.0.5 of 13 August 2026. And the crucial point: the 1.10.x branch is the last one carrying the long-term support label, and that support ends on 30 April 2027. Community Edition releases from 2.0.0 onwards have a two-year patch policy, and the longer windows—extended support and extended continuous support—are paid packages for Enterprise customers.

How to choose? A rule of thumb

Up to around ten nodes, one team, one application, predictable traffic, nobody employed full-time on the platform → Docker Swarm is nothing to be ashamed of. It is cheaper in every dimension, and a cluster nobody maintains will break sooner than Swarm manages to age.
From a dozen or so to roughly a thousand nodes, mixed workloads—containers, binaries, Java applications—and a small platform team → Nomad gives you the most capability here for the fewest layers to maintain: one process to upgrade instead of a chain of components. The condition: informed acceptance of the BUSL licence and of the fact that with an unusual integration you will more often hit "write it yourself" than a ready-made operator.
Above roughly a thousand nodes, many isolated teams or customers in one cluster, regulatory requirements, a need for an ecosystem and off-the-shelf operators, hiring plans → Kubernetes. With a full-time role for maintaining the platform, not a fraction of one.

And a question worth asking before any of those three answers: do your workloads need orchestration at all? An application that has been sitting quietly on a single virtual machine for years mainly gains, when moved into an orchestrator, a new set of things that can break. How responsibilities are divided between cloud service models is the subject of the article Cloud as a service: IaaS, PaaS and SaaS with examples, and where the budget leaks away in the cloud is covered in Public cloud at a reasonable price.

Which orchestrator can you run in the WebDisk cloud?

In our public cloud you have two routes, and both are open regardless of which orchestrator you choose.

A managed Kubernetes cluster (WebDisk K8s)—a service available to WebDisk Cloud users; you order the cluster from the panel, and the platform built on Apache CloudStack creates it for you—with public IPv4 and IPv6 addressing and node-count scaling. The details of the network configuration and the scope of automatic scaling are agreed at the time of the order. For teams that want full control, the route of running your own cluster on IaaS infrastructure remains: with the CloudStack provider for Terraform, or with Cluster API in full "infrastructure as code" mode.

Nomad, Swarm or anything else on your own machines. If, having read this article, you conclude that your team is closer to Nomad, nothing stands in the way: you rent virtual machines and networking in the WebDisk public cloud, and you install and maintain the orchestrator on your side—in the Community edition at no charge, settling any Enterprise licence directly with its vendor. We do not offer managed Nomad and we are not going to promise it; the managed service here is Kubernetes, and when moving away from Docker Swarm environments our team helps with advice and a migration plan.

Whatever you choose, the same dull list of a cluster owner's duties remains: upgrades, backups of state and application data, monitoring and somebody to answer the alert. How we arrange the security layers underneath all of that is described in the article How many layers does your file security have.

Frequently asked questions

Can Nomad replace Kubernetes in your organisation? It can—if what you mainly need is a workload scheduler, you have mixed workloads and a small platform team. It will not replace it where what counts is the operator ecosystem, mature support for stateful applications, network microsegmentation in the core, or the availability of a managed service from your cloud provider. The question is not "which tool is better" but "how much platform do you really need and who is going to maintain it".

What exactly ends on 30 April 2027? Support for the Nomad 1.10.x branch—the last one marked as long-term (LTS). After that date fixes, including security fixes, no longer reach that line; you have to move to a newer branch or buy extended support in the Enterprise edition. Newer Community Edition releases have a two-year patch policy, but none of them carries the LTS label any more.

Is Docker Swarm still being developed? Swarm mode built into the Docker engine—yes: the moby/swarmkit repository is alive, and the 2026 releases contain Swarm-related fixes. Docker has not announced an end-of-support date, but neither does it promise further development—it writes that development has slowed in favour of Kubernetes-based solutions. What is closed is Swarm "classic", a separate 2014 product, archived in 2021.

Does Nomad require Consul and Vault? No—native service discovery is enough to get started, although it gives you no DNS. With Consul, Nomad does substantially more (domain names, a service mesh, network intentions), and Nomad Variables are not a replacement for Vault: the master encryption key sits on the servers, and the mechanism is intended for small fragments of configuration.

Where do you start so that a Nomad cluster is not left open? With enabling access control lists—they are disabled by default and are initialised by nomad acl bootstrap. That is the first thing to do after standing up the servers, before exposing anything to the network. A production cluster itself is three or five servers per region.

Will Nomad run an application that exists in no container image? Yes—that is its distinguishing feature. The exec driver runs a plain binary in isolation, java runs a JAR archive with no image build, and exec2 isolates the process with native kernel mechanisms. The virt driver for full virtual machines exists, but the vendor marks it as not intended for production.

Summary

The choice between Swarm, Nomad and Kubernetes is at bottom the answer to one question: how much platform do you want to maintain. Swarm gives the least and costs the least; Kubernetes gives the most and demands the most, offering in return a neutral licence, an ecosystem and a skills market; Nomad sits in the middle—one file, one binary, non-containerised workloads too—at the price of a licence that is not open and a long-term branch ending in April 2027.

None of these answers is universally better; the only bad decision is one made without counting the cost of running it. Get in touch—we will help you compare the options on what they cost to run and plan a migration, and for Kubernetes clusters also review how they are being maintained.

HashiCorp Nomad vs Kubernetes vs Docker Swarm: which orchestrator to pick and what it really costs to run