· via dev.to (home feed)
Portainer 3.0 drops Community Edition, pushing Docker self-hosters toward alternatives
Portainer 3.0 ships Kubernetes-first with no Community Edition build, leaving 2.45 CE users on security fixes only and prompting a search for Docker-first management tools.

What changed
According to a write-up on dev.to, Portainer CEO Neil Cresswell announced in a blog post on 11 September 2026 that version 2.45 LTS will be the final release in the 2.x line. Portainer 3.0, which arrives as a short-term-support release with a 3.x LTS line to follow, is built Kubernetes-first and ships without a separate Community Edition build. Existing CE installations stay on the 2.x branch and will not receive 3.x features. Free access going forward runs through Portainer's existing 3 Nodes Free program — effectively a Business licence tied to an account — rather than a community-maintained build.
The dev.to post reports that a maintenance release, 2.45.1 LTS, landed on 17 September 2026 with security fixes and no new features. Docker, Swarm and Podman environments keep working under 3.x, but the interface treats them as lower priority, and the policy engine, GitOps engine and observability layer will gain new capabilities only on the Kubernetes side. New additions to the product family — Portainer-Run, Portainer-IDP, the Portainer-Command MCP gateway, Portainer-Operations and Portainer-AiGrid — all target Kubernetes exclusively. The author points to coverage from Linuxiac and heise online for readers wanting a second read.
Why Portainer chose Kubernetes
Cresswell's stated reasoning, as relayed in the post, is that keeping a single codebase fully featured across Docker, Podman, Swarm and Kubernetes had stopped being realistic: policy management, the operations API and the internal authentication model each had to be implemented once per substrate. There is also an AI dimension. In Portainer's view, Docker and Swarm lack equivalents of Kubernetes network policies, pod security standards and admission controllers — the primitives you would want in place to contain autonomous agents.
Reaction was sharp enough that Cresswell followed up, saying the company is "not abandoning Docker" and that nothing working today will be removed from 2.x or from Docker environments in 3.x. If Docker support ever reaches end of life, he said, users would hear about it well in advance, along with a migration path.
Options for self-hosters
The post lays out three realistic paths for people running Docker at home or on client machines:
- Stay on Portainer 2.45 CE. Security patches and back-ports continue while the LTS line is supported, but there are no new features, and no fixed end-of-life date has been announced.
- Move to the 3.x free tier. This preserves access to the Kubernetes-first policy engine, GitOps and observability under the 3 Nodes Free program, at the cost of Docker becoming a second-class citizen in the interface.
- Switch to a Docker-first alternative. The tools named are Dockge, Komodo, Arcane, Coolify and Dokploy — with the trade-off of giving up Portainer's Kubernetes support if it is ever needed.
The author's own picks: Dockge, the MIT-licensed Compose stack manager from the creator of Uptime Kuma, for a single box — it edits compose files directly and starts quickly even on a Raspberry Pi. Komodo, licensed under GPL-3.0, for managing multiple machines with GitOps; compose files from Dockge carry over unchanged. Arcane suits anyone wanting a Go-based interface, while Coolify and Dokploy cover git-push deployments with automatic SSL.
Why it matters
Community Edition has long been the default container-management interface for homelabs and small Docker hosts. The shift means the free option is now a vendor-controlled licence rather than an open build, with all new development concentrated on Kubernetes. Nothing breaks immediately — 2.45.1 is a routine security update — but anyone on CE now faces a choice between a frozen feature set, an interface where Docker is de-emphasised, or migrating to a younger tool. It also signals where vendors expect container workloads to land: the security primitives Portainer cites as its justification are Kubernetes primitives, and products being built for autonomous agents appear to be following the same path.
- #portainer
- #docker
- #kubernetes
- #containers
- #self-hosting