Portainer, a popular web-based platform for managing containerized environments such as Docker, Kubernetes, Podman, and Docker Swarm, is preparing its next major release.
With Portainer 3.0, the main focus will shift to Kubernetes, while Docker, Swarm, and Podman will become secondary. There is, however, a small twist for users – whether it’s a good or bad one depends on how you look at it.
The company says Portainer 2.45 LTS will be the final release in the 2.x series, with Portainer 3.0 expected to arrive next as an STS release, followed later by a new LTS version. But more importantly, Portainer 3.x will use what the company describes as a Kubernetes-first codebase.
According to Portainer, the gap between Docker and Kubernetes has grown to the point where maintaining the same capabilities across Docker, Podman, Swarm, and Kubernetes in a single codebase is no longer practical.
Features like policy management, operations APIs, authentication, GitOps, and observability now rely more on what Kubernetes offers. But that doesn’t mean Docker support is going away.
Users can still connect and manage Docker, Swarm, and Podman environments in Portainer 3.x, but these environments will not get every new feature added to the platform.
Portainer says Docker, Swarm, and Podman will have a secondary place in the interface. New features for the policy engine, GitOps, and observability will mainly focus on Kubernetes.
The company is also creating new products with this Kubernetes-first approach, such as Portainer-Run, Portainer-IDP, Portainer-Command, Portainer-Operations, and Portainer-AiGrid, designed for Kubernetes instead of Docker.
For current Docker users, Portainer suggests using either native Kubernetes or its Portainer-D2K project.
Portainer-D2K acts as a compatibility layer, making Kubernetes look like a Docker environment. This lets users keep using familiar tools like the Docker CLI and Docker Compose, even though workloads run on Kubernetes.
It also exposes a Docker-compatible API, meaning existing automation, CI/CD systems, and other Docker-focused tooling can continue working without requiring an immediate migration to Kubernetes-native tooling.
Moreover, Portainer is also working on a migration add-on to help users move their Docker containers and stacks to Kubernetes. The tool will convert Docker workloads into Kubernetes manifests, commit those manifests to a Git repository, and deploy them using Portainer’s GitOps functionality.
Another major change concerns Portainer Community Edition. Portainer CE, the free community version, will stay on the 2.x codebase, and there will not be a separate Portainer CE 3.x release.
Instead, users can get Portainer 3.x through the company’s existing “3 Nodes Free” Business Edition program. So, the free Portainer option is not going away, but Community Edition as a separate product will end with the 2.x generation.
Portainer 2.45 CE will keep getting security updates, bug fixes, and backports as long as the 2.45 LTS series is supported.
However, Portainer makes clear that users should not expect full feature parity with 3.x because some upcoming capabilities depend directly on Kubernetes functionality that Docker does not provide.
Following criticism of the announcement, Portainer CEO Neil Cresswell also clarified that the company is not abandoning Docker. Portainer will still support native Docker and Podman environments, and it won’t remove existing features from Portainer 2.x or 3.x.
Still, the overall direction is clear. Portainer, known for making Docker management easy with its web interface, is now focusing future development on Kubernetes.
This, however, opens the door for other tools such as Komodo, which has quickly gained traction and, to some extent, has already displaced Portainer as the default first choice for many users, a position Portainer held until fairly recently.
For additional details, see the official announcement.
