As CEO of Portainer, I have spent a lot of time watching how the container ecosystem actually moves under our customers' feet (rather than how vendor marketing says it moves), and the shift is unmistakable. Kubernetes has become the go-to tech for the container world. On top of this, AI-built applications and agentic operations have entered hard and fast. To keep up with this movement, we are making some significant and exciting changes and additions. What's driving them is the same goal we've always had at Portainer: making container operations as simple as possible, whatever the platform is underneath.
Why are we cutting a new major version now?
None of the above is possible inside our current codebase. Over the last two years, the gap between Docker and Kubernetes has widened to the point where staying fully featured across Docker/Podman, Swarm, and Kubernetes in a single codebase is no longer viable. Every new capability in policy management, our operations API, and our internal auth model has had to be built three times over, against three substrates, and two of them are no longer where the ecosystem is investing. So Portainer 3.x is a Kubernetes-first codebase, and that's what makes the single-purpose consoles above possible.
What happens if you run Docker today?
If you run Docker today, nothing changes for you on 2.x. We will continue to ship security updates, bug fixes, and selective back-ports of 3.x features into the 2.x line, so a decision to stay put is a supported decision.
If you move to Portainer 3.x, you will see a few UI changes, namely a reorder of environments and a streamlined way to deploy Portainer D2K, our synthetic Docker environment powered by Kubernetes.
Of course, you can still add Docker/Swarm/Podman native environments, but these are now secondarily ordered inside the product. They remain there, they still work, and you can still operate them from the Portainer UI; what they will not receive are new capabilities as we enhance our policy engine, gitops engine, and observability layer, the parts of Portainer that handle permissions, automated deployments, and monitoring.
We recommend you consider the migration from Docker to D2K or Native Kubernetes when the time is right for your environment. When you’re ready to look at Kubernetes, I think you should take a closer look at KubeSolo paired with D2K. KubeSolo is a single-node Kubernetes distribution that now embeds D2K natively, on with a single flag at install. One KubeSolo install gives you a working single-node Kubernetes cluster, a synthetic Swarm cluster, and a synthetic Docker host. And all under 200 MB of RAM, the same footprint as running Docker or Podman directly.
For those running Portainer alongside PLCs, SCADA systems, or other OT infrastructure, none of this touches those systems directly. This changes the container management layer, not your production control systems. And if your site is air-gapped or runs with limited connectivity, how our GitOps-based workflows apply to that setup is worth a direct conversation with us to work through your specific setup.
Neil
A clarification
Some of the reaction to this post has hardened into claims that are simply not true, so let me provide you with certainty.
We are not abandoning Docker; some of our largest commercial customers run almost exclusively on Docker and Podman (one manages over 125,000 Docker devices in an edge fleet growing by around 7,000 a month), they pay us to keep it working, and it stays in Portainer for as long as Docker-CE remains a viable technology. Portainer-D2K, the synesthetic docker API translator for Kubernetes, is designed to give you options. With it you can reliably run Kubernetes on a single node, and manage it using the Docker CLI and tooling. Should you want this.
We did not pick Kubernetes for convenience and then dress it up as “Docker is bad”; the next generation of applications and AI agents need network policies, pod security standards and admission controllers to be safely sandboxed, and Docker and Swarm have no equivalent of those primitives, so we cannot build that protection on top of them however much we might like to.
Nothing that works today gets ripped out of 2.x or out of the Docker environments in 3.x, and if Docker support ever reaches end of life you will hear it from me well in advance with a migration path attached.
The 2.45 LTS line (both CE and BE) will continue to receive security fixes, bug fixes, and back-ports of every 3.x capability that has a corresponding Docker API to interface with; what I cannot promise is feature parity, because some new capabilities depend on Kubernetes primitives that Docker does not have.
Nor are we turning our back on the community; there are over 110,000 free Portainer Business licenses active today under “3 Nodes Free”, and 3.x will be free to the community on exactly the same terms. CE stays on the 2.x codebase because 3.x is built for commercial and industrial deployments (the policy model, the operations API and the single-purpose consoles all assume an enterprise user) and CE was never designed for that audience; CE will continue to receive patches and updates because it is a core component of Business Edition 2.45 LTS, so it is maintained by the same team, on the same schedule, for as long as that LTS is supported.
If you are still concerned after reading this, reach out; we would rather talk it through with you than have you decide based on what someone else assumed we meant. Neil