Planning a Move from Docker Swarm to Kubernetes? Read This Before You Migrate.

Docker Swarm has been declared dead more times than anyone can count.

Yet thousands of production environments continue to run on Swarm every day. Why? Because for many teams, Swarm still delivers exactly what they need: simple deployment, low operational overhead, Docker-native workflows, and infrastructure that developers can actually understand.

When organizations start evaluating Kubernetes, the conversation often begins with a list of "missing" Swarm features:

• Role-Based Access Control (RBAC) – Restricting daemon/API access by user or team.
• Multi-user management – Secure isolation for multiple developers or staging stacks.
• Secure shell access – The ability to exec into containers without full Docker host root permissions.
• Application packaging and distribution – A standardized way to bundle and parameterize complex stacks (like Helm).
• Enterprise governance – Audit logs, policy control, and compliance guardrails.
• Platform engineering capabilities – Offering developer self-service options without cluster admin access.

Historically, these were valid reasons to migrate. Today, that assumption deserves another look.

Enter SwarmCLI Business Edition

SwarmCLI was built around a simple idea: Keep Docker Swarm simple while adding the capabilities teams typically migrate to Kubernetes for.

Instead of replacing Swarm, we extend it. Rather than abandoning a stable, lightweight, and well-understood deployment workflow for the massive operational footprint of Kubernetes, SwarmCLI equips your existing Swarm cluster with enterprise-grade capabilities.

RBAC and Secure Access

One of the most common reasons teams leave Swarm is the lack of native, fine-grained access control. By default, access to the Docker Swarm socket is all-or-nothing: once a developer has access, they can manipulate any service, inspect any secret, or delete any volume.

SwarmCLI Business Edition introduces an RBAC Proxy. This proxy intercepts Docker API requests and allows organizations to control who can access what, enabling secure multi-user environments without exposing the Docker daemon socket directly.

[!NOTE] For a detailed guide on architecture and configuration, check out the SwarmCLI RBAC Proxy on GitHub.

Direct Shell Access

Platform engineers and operators often need to debug services by gaining terminal access to running containers. In standard Docker Swarm, this requires SSH access to the host machine and root access to the Docker daemon.

SwarmCLI provides direct, audited shell access capabilities. Users can execute commands or launch interactive shells inside containers via SwarmCLI without requiring unrestricted host-level Docker daemon permissions. This brings a Kubernetes-like kubectl exec operational experience while preserving Swarm's signature simplicity.

SwarmCharts: Helm-Like Application Management

Application distribution and package management is another area where Kubernetes has traditionally held a significant advantage through Helm. Managing complex, multi-service applications on native Swarm usually involves massive, copy-pasted Compose files with hardcoded variables.

With the introduction of SwarmCharts, that gap is closed. SwarmCharts are heavily inspired by Helm charts and provide:

• Reusable application templates – Standardized structures for services, configs, and networks.
• Parameterized deployments – Inject variables dynamically via values.yaml and CLI overrides.
• Version-controlled releases – Keep track of release revisions for auditability.
• Rollback capabilities – Instantly roll back to a previous revision if an upgrade fails.
• Standardized installation & sharing – Distribute applications easily across different clusters and teams.

Teams can now package and deploy applications on Swarm using a workflow that feels familiar to Helm users—without adopting the full, heavy Kubernetes stack.

SwarmCharts CLI Reference

Run the help command to see the available commands for managing repository and release states:

$ swarmcli charts --help
Usage: swarmcli charts <command> [options]

Repository:
  repo add <name> <url>      Add a chart repository and download its index
  repo list                  List configured repositories
  repo update [name]         Refresh repository indexes (all, or one)
  repo remove <name>         Remove a repository

Discovery:
  search [keyword]           Search charts across repositories
  show chart  <repo/chart>   Show chart metadata
  show values <repo/chart>   Show default values.yaml
  show schema <repo/chart>   Show values.schema.json

Releases:
  template <release> <chart>  Render manifest to stdout (no deploy)
  install  <release> <chart>  Install a chart as a release
  upgrade  <release> <chart>  Upgrade a release to a new revision
  uninstall <release>         Remove a release (keeps volumes)
  rollback <release> <rev>    Re-deploy the contents of a past revision
  history <release>           Show a release's revision history
  get values|manifest <rel>   Show stored values or rendered manifest
  diff upgrade <rel> <chart>  Preview manifest changes before upgrading
  list                        List releases
  status <release>            Show release status and services

Common options:
  -f, --values <file>   Values file (repeatable)
      --set k=v         Override a value (repeatable)
      --version <ver>   Chart version (default: latest)
      --dry-run         Render and validate without deploying
      --wait            Wait for services to converge
      --timeout <dur>   Wait timeout, e.g. 10m (default 5m)
      --history-max <n> Max release revisions to retain
      --install         upgrade: install the release if absent
      --reuse-values    upgrade/diff: layer overrides on previous values
      --revision <n>    get: select a specific revision
      --purge-volumes   uninstall: also remove the release's volumes

[!TIP] You can host your own chart repository or explore the community packages on the SwarmCLI GitHub Repository.

The Real Cost of Kubernetes (The Complexity Tax)

Kubernetes is an impressive, highly modular platform. It provides enormous flexibility and a vast ecosystem. But that flexibility is not free. It comes with a significant operational surcharge:

• Increased operational complexity – Managing control planes, API servers, etcd clusters, certificates, and DNS overlays.
• More moving parts to manage – Coordinating CNI networks, CSI storage provisioners, Ingress controllers, and service meshes.
• Additional training requirements – Forcing developers to learn complex YAML specs, custom resources (CRDs), and debugging techniques.
• Higher infrastructure overhead – Dedicating multiple nodes just for the control plane before running a single user workload.
• Steeper troubleshooting processes – Sifting through layers of abstraction (Kubelet logs, Pod logs, container runtimes, network policies) when something fails.
• Dedicated platform engineering effort – Assigning full-time engineers solely to maintain the orchestrator itself.

Many organizations migrate to Kubernetes only to discover that they are spending more time maintaining the platform than they are delivering business value.

Instead of asking "Can Kubernetes do more than Swarm?" (the answer is obviously yes), the better question is: "Do we actually need Kubernetes for our use case?"

Feature Comparison Matrix

The Agentic Era Changes Everything

As AI agents become increasingly common in software development and operations, infrastructure requirements are shifting. AI agents need platforms that can:

1. Deploy workloads quickly without complex reconciliation loops.
2. Scale operationally without requiring large human platform teams to write custom operators.
3. Support secure multi-user environments to prevent prompt injection or code execution from compromising the host.
4. Provide secure access controls so agents can only interact with their designated resources.
5. Package and distribute applications consistently so agents can deploy pre-packaged stacks easily.
6. Allow agents to interact safely with infrastructure through clear, lightweight APIs.

Many assume Kubernetes is the default answer. However, the agentic era may actually favor simpler, faster, and more deterministic platforms. Docker Swarm, enhanced with SwarmCLI, offers a compelling alternative:

• Docker-native – Works out of the box with standard tools developers already know.
• Lightweight – Run clusters on small mini-PCs, virtual machines, or edge nodes without resource exhaustion.
• Easy to operate – Zero-overhead infrastructure that is straightforward to debug and automate.
• Enterprise-ready access controls – Secure, fine-grained control via the RBAC Proxy.
• Direct, audited shell access – Safe terminal environments for human operators and AI agents.
• Helm-inspired application packaging – Dynamic templating and releases via SwarmCharts.

Before You Migrate

If your primary reasons for moving to Kubernetes are:

• RBAC and policy control
• Multi-user management and tenant isolation
• Secure shell access for debugging
• Version-controlled application packaging
• Operational governance and auditing

...you may no longer need to migrate at all.

Before investing months of engineering time and thousands of dollars in cloud infrastructure for a Kubernetes migration, take a look at what modern Docker Swarm tooling can provide. You might discover that the platform you already know is capable of much more than you thought.

Swarm isn't trying to become Kubernetes. It's trying to eliminate the reasons people felt they had to leave it.

Ready to level up your Swarm cluster?

• Explore the SwarmCLI GitHub Repository to get started with the CLI and SwarmCharts.
• Check out the SwarmCLI Business Edition features to learn about the RBAC Proxy and enterprise-ready security configurations.