Portainer’s Community Edition has been open source for a decade now, and that run has now hit a wall. Portainer 3.0, the upcoming ground-up rebuild of the platform around Kubernetes, will not be the base for CE.
This was announced by the company’s CEO, Neil Cresswell, who says that CE will continue being based on Portainer 2.45 LTS, the last release in the 2.x line. While everything after it, like the new consoles, the new architecture, etc., won’t be ported to CE.
Instead, CE will get security fixes, bug fixes, and backports of 3.x features, but only where a matching Docker API exists to interface with. Feature parity isn’t guaranteed since some of what’s landing in 3.x depends on Kubernetes primitives Docker doesn’t have.
Why the change?
Neil feels that this is a maintenance problem rather than a strategy pivot. Every time the team wanted to add a policy or API capability, it had to build that feature three separate times, once each for Kubernetes, Swarm, and the Docker and Podman side.
Portainer 3.0 abandons that model entirely. Five separate consoles take its place now, each one built around a specific job rather than one interface handling everything.
He goes on to say that CE simply doesn’t fit into this new approach and that Portainer 3.x’s policy model, operations API, and enterprise-focused consoles assume an enterprise user from the get-go, and “releasing that as CE would misrepresent what it is and who it is for.”
What this means for you
If you’re already running Docker, nothing changes today. 2.x keeps working as it has and keeps getting security patches; staying put is a fully supported choice.
Move to 3.x though, and Docker, Swarm, and Podman environments still work as native connections. For anyone who’d rather keep using Docker-style tooling while running on Kubernetes underneath, Portainer-D2K is the provided compatibility layer that lets Docker Compose and similar tooling deploy and manage applications on a Kubernetes cluster.
Whatever Portainer builds next for observability, GitOps, or its policy tooling goes to Kubernetes environments first, and native Docker setups sit lower in the interface without getting any of it.
If you want the new capabilities without moving to Kubernetes, there isn’t really a way to get them for free and stay open source. The only no-cost route onto 3.x runs through 3 Nodes Free, Portainer’s existing node-capped license for the closed-source Business Edition, not a CE build.
Alternatives if you want to switch
If staying stuck on 2.x forever isn’t appealing, here’s what’s actually in development right now that you could consider:
- Komodo, a Rust-based build-and-deploy platform designed to manage workloads across multiple servers. It has no artificial server-count limit and is particularly interesting if you’re comfortable with a more deployment/automation-oriented approach.
- Arcane, a Go/SvelteKit Docker management platform with a modern UI. It’s BSD-3-Clause licensed and provides container, Compose, image, volume, network, remote-host and Swarm management, among other features.
Neither is a drop-in replacement for every Portainer workflow, particularly if you rely heavily on Portainer’s broader Kubernetes functionality. But for a homelab or small Docker/Swarm environment where you primarily want a capable self-hosted UI without a paid feature tier, both are credible alternatives to investigate.
