Portainer drops its Community Edition and steers its whole roadmap toward Kubernetes
On September 11, 2026, Portainer’s CEO announced that 3.0, now Kubernetes-first, will not ship as a Community Edition: CE stays frozen on the 2.x branch. Self-hosters on Docker can remain on 2.45 LTS, which keeps receiving security fixes, but should plan their path forward.
September 11, 2026. Neil Cresswell, CEO of Portainer, publishes a post that marks the end of an era: the upcoming 3.0 will be Kubernetes-first and will not ship as a Community Edition. September 18. The Self-Host Weekly newsletter relays the news to the audience that feels it most directly: self-hosters. September 20. 2.45 LTS remains the last release of the historic branch. Why it matters: Portainer is the most widely installed Docker management UI in homelabs, and its vendor just announced that the heart of that community will never see a new feature again.
What exactly disappears
The post is explicit about the fate of the Community Edition (CE). For ten years, CE has been Portainer’s free on-ramp for managing Docker and Swarm environments. 3.x will not carry it forward: “CE will continue on the 2.x codebase. It will not receive the 3.x changes.” The practical translation — CE is frozen on the 2.x branch, which will no longer receive new features, only security fixes, bug fixes, and selective backports from 3.x.
The announced offset is the “3 Nodes Free” program: the mainline Portainer 3.x stays free up to three nodes, on application. The vendor’s argument is that nobody loses access, but the change in nature is clear. A community edition is a product designed for a community; a free tier of an enterprise product is a commercial on-ramp. The two are not governed the same way, and the community understood it: the first reflex, on forums and in the weekly newsletter, was to reread the fine print of “free.”
The stated reason is technical and honest. Per Cresswell, the gap between Docker and Kubernetes has widened to the point where it is no longer viable to keep one codebase covering Docker, Podman, Swarm, and Kubernetes on equal footing. Every capability — the policy engine, the operations API, the auth model — had to be built three times, for three substrates. 3.x is therefore a Kubernetes-first codebase, and that choice is what makes the single-purpose consoles described in the post possible.
A deliberate turn toward Kubernetes
3.0 is not a routine upgrade; it is a reorganization of the product around single-purpose consoles, each aimed at one persona.
- Portainer-Run is already live: self-service deployment for non-developer “business builders” to push their AI-generated apps onto the enterprise’s Kubernetes, without touching infrastructure.
- Portainer-IDP will be an internal developer portal for engineering teams.
- Portainer-Command is an MCP gateway that keeps AI agents from changing the cluster directly, handing out read-only, expiring roles and forcing every change through GitOps.
- Portainer-Operations pulls cluster management out of the general UI, into a dedicated GitOps-first console.
- Portainer-AiGrid aligns the vendor with running AI workloads.
The common foundation is KubeSolo, a single-node Kubernetes cluster that is open source (MIT), aligned closer to the official Kubernetes release track, and meant to run in under 200 MB of RAM. And for those who do not want to give up Docker syntax, Portainer-D2K presents itself as a Docker-to-Kubernetes translator: a synthetic Docker environment that accepts docker and docker compose commands, including for CI/CD and monitoring tooling built exclusively against the Docker API.
The direction is coherent, but it acknowledges a fact self-hosters have known for years: homelab Docker is no longer a market for vendors to serve — it is a community to convert.
What happens to Docker users
The post takes care to reassure, and this is the most important part for a self-hoster. If you stay on 2.x, nothing changes today. Portainer commits to continuing to ship security fixes, bug fixes, and selective backports on the 2.x branch. Staying is a supported decision, not a forced abandonment.
The nuance lies elsewhere. 2.x enters maintenance: no new capabilities, no further evolution of the policy engine or observability layer. And if you move to 3.x, Docker, Swarm, and Podman remain addable as native environments, but they are reordered to second place in the UI, and they will receive no new capabilities as versions progress. All of the new products — Run, IDP, Command, AiGrid — are Kubernetes-only.
The vendor explicitly recommends considering a migration from Docker to D2K or native Kubernetes, and announces a migration tool that will turn Docker containers and stacks into Kubernetes manifests, push them into a Git repository, then deploy them via Portainer’s native GitOps. The commercial message is clear: Portainer’s future runs through Kubernetes, and Docker users are invited to follow — on their own schedule, but follow nonetheless.
The read for a self-hoster
The practical decision comes down to a question of trajectory, not urgency.
For a homelab that runs a handful of Docker containers and asks for nothing more, Portainer 2.45 LTS remains perfectly functional and will keep receiving security fixes. There is no urgency to migrate, and no data disappears. The only thing to absorb is that the 2.x branch is now at the end of its functional road: expect nothing new from it.
For someone who wants the single-purpose consoles, built-in GitOps, or AI agent orchestration, the answer is a move to Kubernetes — via KubeSolo for a lightweight single node, or via D2K to keep the Docker ergonomics on the surface. The cost is not the license (three free nodes); it is the learning curve. Kubernetes, even softened, remains a complex state machine, and Portainer’s promise is to abstract it, not to make it disappear.
The final point of caution is governance. Moving from a community edition to a free tier of a commercial product changes the nature of the relationship: the terms of “free” are now terms of service, not a license status. For a service that touches the production infrastructure of a homelab or a small team, reading those terms before switching is not excessive caution — it is the bare minimum.
Verdict
If you self-host Portainer CE on Docker and you are happy with it, do not migrate in haste: 2.45 LTS stays security-supported, and a switch to Kubernetes buys nothing for a homelab that does not need it. If you want the new features — native GitOps, single-purpose consoles, AI agent orchestration — plan a migration to KubeSolo or D2K on your own schedule, starting with a test environment and rereading the 3 Nodes Free terms. If you maintain Portainer for others, start planning now: 2.x is a branch at the end of its functional life, and any architecture decision made today on Docker will have to be justified tomorrow against a roadmap that no longer serves it.