Docker Swarm was never officially discontinued, but its growth stalled after Mirantis bought the company in 2019.
Docker themselves “admitted” to this, saying the tool’s “development has slowed in favor of Kubernetes-based solutions.”
This line, along with terminology confusion, has led a lot of people to believe Docker Swarm is dead. The truth is, Classic Swarm (an older, standalone tool, separate from the Docker Engine) has been archived and is no longer actively developed. Docker Swarm is still alive, despite the lack of investment driving a community consensus that Swarm is deprecated in spirit and Kubernetes should be used instead.
This distinction matters because plenty of people are still running Swarm in production, and for a lot of them, it’s working just fine.
One Reddit user notes: “As a solo IT guy in a small org, swarm meets all my needs. I have noticed a few things that would become a problem if we wanted to scale, but that’s a problem for the future.”
So who exactly is using Docker Swarm?
Mirantis (the company that took over Docker’s enterprise business back in 2019), claims over 100 of its customers run Swarm in production.
MetLife, Royal Bank of Canada, S&P Global and other enterprises run 10,000 nodes, roughly 1,000 clusters or 100,000+ containers on Docker Swarm. So Docker Swarm isn’t exactly a “small teams only” tool. In fact, data from 6sense puts the largest single segment of Swarm users at companies with 10,000+ employees. Small teams (100-249 people) are close behind, but the biggest chunk is enterprise.
Mind you, these numbers come from a marketing vendor so take the findings with a grain of salt and more as directional data. Either way, teams that are in the middle (100-300 employees) are likely to use Swarm the least and opt for an option like Kubernetes.
Where do Swarm users go from here?
Kubernetes tends to be the default answer here (btw, we wrote an article for tech pros who search for Kubernetes alternatives as well) , and for most teams, it’s probably the right one.
It solves problems Swarm structurally can’t. Auto-scaling that reacts to real load, not just replica counts you set by hand. A much deeper storage model (CSI) built for the failure modes of modern infrastructure, rather than the older Docker volume drivers Swarm still leans on. A security model with real role-based access control, instead of Swarm’s simpler mutual-TLS-and-secrets setup. And an ecosystem (monitoring, CI/CD, service mesh, security scanning) that’s almost entirely being built for Kubernetes at this point, not Swarm.
That said, “just migrate to Kubernetes” seems to undersell what’s actually involved, and not just operationally. I wrote about Kubernetes cost management a few years back, and the truth is that Kubernetes’ flexibility is exactly what makes it easy to overspend on. Autoscaling, one of Kubernetes’ best cost-saving tools, is also one of its easiest ways to quietly waste money if pods aren’t given accurate resource requests and limits to begin with.
Moreover, idle resources such as clusters nobody remembered to wipe down after a test run have a way of piling up invisibly until someone actually goes looking for them. It’s a reason to budget for a second learning curve most migration guides don’t cover: once I run this, how do I actually prevent it from quietly costing us money.
When is it time to switch over?
A general indicator it’s time to leave Swarm behind: your team keeps writing one-off scripts just to avoid downtime during deployments, you’re running real databases or queues that need stronger guarantees your data won’t get lost, or the cluster has simply gotten big enough that nobody can debug it just by looking at it anymore. A few sources put the tipping point at around 5 to 10 engineers or roughly twenty separate services, though that’s more of a rough guideline than a hard rule.
Migrating from Docker Swarm to Kubernetes is comparatively easy because Swarm already uses Docker images and Compose syntax, while going the other direction is harder since Kubernetes apps often lean on Kubernetes-specific primitives (CRDs, operators, service mesh) with no Swarm equivalent.
On the more practical side of switching over: your containers themselves probably won’t need to change much, but a fair amount else will. The way you store passwords and app settings needs to be rebuilt using Kubernetes’ own system, along with its permission rules. There is a tool, Kompose, that can convert your existing setup into a rough starting point for Kubernetes, but it doesn’t handle everything cleanly, so expect to do some manual cleanup either way.
Nomad and K3s as viable Docker Swarm alternatives
If full Kubernetes still feels like more than you need, K3s is worth a look. It’s still real Kubernetes, fully compatible with the same tools and setup, just stripped down to be lighter and simpler to run.
It’s become a common landing spot for teams leaving Swarm who want Kubernetes without needing to hire a dedicated team just to keep it running.
There’s also Nomad, a tool from HashiCorp, worth a brief mention if your situation is a bit unusual. Unlike Swarm or Kubernetes, it can manage more than just containers. It can also run plain programs, Java apps, and virtual machines from the same place.
It tends to make the most sense for teams already using other HashiCorp tools, or for teams that were never going to put everything into containers in the first place. One thing worth flagging: HashiCorp was bought by IBM in 2024, and changes to Nomad’s licensing terms have made some people less confident about where the tool is headed, even though that mostly only matters if you’re building a commercial product on top of it.
None of this means everyone needs to leave. If your setup fits what we covered earlier (small team, stable service count, no urgent problems from the recent update) there’s no real obligation to chase the industry default just because it’s the default.
Kubernetes solves problems you might not have yet, and comes with its own costs, both in effort and in actual cloud spend, that are worth weighing honestly before you commit. But if you are outgrowing Swarm, or you’ve already run into real friction, Kubernetes (likely by way of k3s if the full version feels like overkill) is where most of that road leads.
