Portainer, the free Docker and Kubernetes management tool this site has covered before, is about to get a version bump that carries more weight than the number suggests. In a blog post published September 11, 2026, Portainer CEO Neil Cresswell laid out three changes at once: a new major release on a rebuilt, Kubernetes-first codebase, a family of new single-purpose management consoles, and a different role for the free Community Edition (CE) going forward.
Here’s what’s actually changing, what isn’t, and what the community pushback was about.
A new major version, built Kubernetes-first
Portainer 2.45 LTS, which landed in late August 2026, is the last release in the 2.x line. Next comes 3.0.0, shipping as an initial Short-Term Support (STS) build on the new codebase, with a full Long-Term Support (LTS) release for the 3.x branch to follow later.
Cresswell’s explanation for the rebuild is fairly blunt: keeping full feature parity across Docker/Podman, Swarm, and Kubernetes inside one codebase stopped being realistic. Every new capability in policy management, the operations API, and the internal authentication model had to be built three times over, against three different substrates, and two of those substrates aren’t where most of the ecosystem’s engineering effort is going anymore. Portainer 3.x is therefore Kubernetes-first by design, which is also what makes a new lineup of single-purpose consoles possible:
- Portainer-Run, already live, lets non-developers deploy AI-built apps to Kubernetes without touching infrastructure
- Portainer-IDP, an internal developer portal, coming next
- Portainer-Command, an MCP gateway that hands AI agents expiring, read-only roles and routes every real change through GitOps
- Portainer-Operations, a GitOps console built for cluster day-2 operations
- Portainer-AiGrid, for running AI workloads on Kubernetes
Several of these lean on KubeSolo, Portainer’s existing open-source, MIT-licensed single-node Kubernetes distribution. It now bundles the new Portainer-D2K translation layer natively, so one KubeSolo install gives you a working single-node Kubernetes cluster, a synthetic Swarm cluster, and a synthetic Docker host, all under 200MB of RAM after a switch from CRI-O to crun.
If you run Portainer on Docker today, nothing changes
For self-hosters, the question that actually matters is whether an existing Docker install needs any action. It doesn’t. Portainer says it will keep shipping security updates, bug fixes, and selective back-ports of 3.x features into the 2.x line. Staying on 2.x is framed as a supported, long-term choice rather than a waiting room, with no forced migration and no cutoff date attached.
What actually happens to Portainer Community Edition
This is the part worth reading twice. Portainer Community Edition, the free edition behind most home-lab Docker setups, stays on the 2.x codebase and will not receive the 3.x changes. There’s no separate CE build of 3.0 planned.
That doesn’t make 3.x paid-only, though. Portainer says 3.x will stay free to the community through its existing “3 Nodes Free” program, the same program that already has more than 110,000 free Portainer Business licenses active. The company’s own reasoning is that 3.x’s policy model, operations API, and single-purpose consoles are all built around an enterprise deployment shape, so releasing it under the CE label, in Portainer’s words, “would misrepresent what it is and who it is for.”
In short: 3.x on Kubernetes is free for up to three nodes. Docker keeps you on the 2.x line, CE label intact.
The pushback, and Portainer’s clarification
The announcement got enough pushback that Portainer added a follow-up section to the same post, headed “A clarification.” The gist of it: Portainer says it isn’t abandoning Docker, and points to commercial customers running large Docker fleets as proof. One of them manages over 125,000 Docker devices at the edge, a fleet that’s apparently growing by around 7,000 devices a month, and pays Portainer to keep that working.
The 2.45 LTS line, both CE and Business Edition, will keep getting security fixes, bug fixes, and back-ports of any 3.x capability that has a matching Docker API to hook into. What Portainer won’t promise is full feature parity, since some 3.x capabilities lean on Kubernetes-native primitives (network policies, pod security standards, admission controllers) that Docker and Swarm simply don’t have an equivalent for.
A free on-ramp, if you ever want one
If you’re curious about Kubernetes but not ready to give up a Docker-based workflow, Portainer-D2K is worth a look. It’s free, open source, and available now on GitHub. It presents a synthetic Docker environment (either a single node or a Swarm-style cluster) that’s actually backed by a real Kubernetes cluster, so your existing docker and docker compose commands, along with Docker-compatible CI/CD and monitoring tools, keep working without a rewrite. Portainer also says a dedicated migration add-on is coming, meant to convert existing Docker containers and stacks into Kubernetes manifests through GitOps.
The practical takeaway
None of this demands action from a home lab or small business running Portainer on Docker right now. The 2.x line, CE included, keeps getting security and bug fixes, and Portainer has committed to advance notice and a migration path if Docker support is ever actually wound down. The real shift here is strategic, not immediate: new products and new capabilities get built Kubernetes-first from here on, and Docker/Swarm support on the 2.x line becomes a maintenance track instead of a growth track. That’s a governance change worth knowing about, not a reason to touch anything today.