Portainer 3 is Kubernetes-first, not Kubernetes-only
This post clarifies our earlier announcement, Portainer 3.0 is coming, and here's what it means for you. Where the two differ, this post reflects our intended position.
When we announced Portainer 3, many people read it as "Portainer is dropping Docker." That isn't what is happening, and we didn't say so clearly enough the first time.
The short version: Portainer 3 is Kubernetes-first, not Kubernetes-only. Docker and Podman stay in the product, and nothing you use today is being taken away from those environments. What has changed is where we build new things, and I want to explain why.
Portainer 3 starts with 3.0, an STS release that is available now, and the first Portainer 3 LTS release will follow. Everything below applies to Portainer 3 as a whole, not to one point release.
What is changing
We are not abandoning Docker
Some of our largest commercial customers run almost entirely on Docker and Podman. One of them manages more than 125,000 Docker devices in an edge fleet that grows by around 7,000 a month. They rely on Portainer to keep that working, and we will.
In Portainer 3, Docker Standalone, Docker Swarm and Podman environments are still in the product. You can add them, and you can manage them from the Portainer UI as you do today. We are not removing Docker or Podman features.
Kubernetes-first, not Kubernetes-only
What changes in Portainer 3 is where new features go. New work in our policy engine, GitOps engine and observability layer is designed and built for Kubernetes. So are our new single-purpose consoles: Portainer-Run, Portainer-IDP, Portainer-Command and Portainer-AiGrid.
Docker, Swarm and Podman environments will keep receiving bug fixes and security fixes. They won't receive new features.
The one thing that does go away: a separate CE build
The big change between 2.x and 3 is that Portainer 3 has no Community Edition. CE 2.45 is the last version of CE we will release, and it stops receiving fixes when Portainer 2.45 LTS reaches end of support. What that means for you depends on how you run Portainer today.
If you use Community Edition
Nothing stops working, and nothing is switched off. CE 2.45 keeps managing your Docker, Swarm, Podman and Kubernetes environments as it does now. It gets the same 2.45.x bug and security fixes as Business Edition 2.45 LTS, because the same team builds it from the same code. It won't get new features, though, and after August 2027 it won't get fixes either. Portainer has root-level access to the hosts it manages, so we'd advise against running it unpatched. Please plan to move before that date.
There are two ways to move to Portainer 3. If you manage three nodes or fewer, you can [request a free 3 Nodes Free license] and upgrade your existing installation, and your environments and settings carry over. If you manage more than three, you'll need a paid license. Our Starter tier covers up to 15 nodes, and you can buy it online.
If you use 3 Nodes Free
You already run Portainer Business, so you can upgrade to Portainer 3 at no cost, on the terms you have today. More than 110,000 3NF licenses are active, and the program isn't changing. Your Docker, Swarm and Podman environments come with you, and your Kubernetes environments get the new policy, GitOps and observability features. If you follow our advice and move a Docker host to KubeSolo, it still counts as one node, so the move won't push you over your limit.
If you have a paid Business license
Your subscription covers Portainer 3, and your license and node count don't change. You decide when to move. You can stay on 2.45 LTS, which we're supporting until August 2027. You can upgrade to 3.0 now if you want the new Kubernetes features. Or you can wait for the first Portainer 3 LTS.
Why we are doing this
The main reason is security. We don't believe a standard Docker setup is secure enough for the workloads people are running today, and we've published our reasoning in full in The Container Platform Threat Model.
Container escapes aren't new. runc, the runtime under Docker and most Kubernetes distributions, has had serious escape vulnerabilities repeatedly since 2019, most recently three disclosed in November 2025. Escapes stayed rare in practice because finding the flaw, writing the exploit and chaining it to an application bug took scarce skill.
AI has removed most of that barrier. An attacker with an unrestricted model can hand it an application's source code or dependency list, get back a working exploit, and have the same model chain that foothold into a runtime or kernel escape. So we now assume an escape will happen, and ask a different question of every platform: once an attacker is out of the container, what do they hold, and what stops them taking more?
On a standard Docker host, the answers are not good:
The daemon runs as root, and root inside a container is root on the host. An escape yields the host, every other container on it, the local image cache and the host's credentials. Docker's two native mitigations both cost something: rootless mode gives up features such as overlay networks (so it can't be used with Swarm), and userns-remap can be switched off by any individual request.
The engine has no built-in point where a policy can refuse a request. Anything that reaches the Docker socket runs, whether it comes from the CLI, a CI runner, a compose file or an AI agent holding someone's credentials.
That second point matters for Portainer directly. Our Docker security settings for privileged mode, bind mounts, host PID and similar options can hide those options from non-administrators in our UI. They can't block a request that never goes through Portainer. We used to describe those settings as blocking, and we renamed them to hiding because that is what they actually do.
Kubernetes is built differently. Every request passes through the API server, which authenticates, authorizes and admits it before anything runs, regardless of which tool sent it. Controls such as Pod Security Admission, user namespaces and NetworkPolicy are enforced by the platform itself. To be clear, most of those controls are not switched on by default. But Kubernetes gives you a place to enforce them, and that lets us automate security in a way Docker doesn't allow.
Podman sits between the two. Run rootless, it limits what an escape yields far better than rootful Docker does. But Portainer manages Podman through its Docker-compatible API, which carries the same requests and has the same hide-rather-than-block limitation, so we can't enforce policy there either.
There is also a practical reason. Building every capability in policy management, our operations API and our auth model three times over, against Docker, Swarm and Kubernetes, was no longer viable. Most of the ecosystem's investment is going into Kubernetes, and that's where we can do the most for you.
What this means for you
You can upgrade to Portainer 3 without losing anything
If you manage Docker, Swarm or Podman with Portainer, you can move to Portainer 3 and keep the features you use today. You will see some UI changes, mainly a reordering of environments and a streamlined option to deploy Portainer-D2K when you add a new environment, but your existing Docker and Podman environments keep working.
The only thing that could change this is security. If a vulnerability affects a Docker or Podman feature and no fix is available for it, we may need to disable or remove that feature to protect you. We expect this to be uncommon, and if it happens we will say so clearly in the security advisory and release notes, along with any workaround.
If you are staying on 2.x for now, Portainer 2.45 LTS is the last 2.x release, apart from patch releases (2.45.x). We are extending its support so you have time to evaluate Portainer 3 properly. We are sending the details to customers separately.
Start planning your move to Kubernetes
Because of everything above, I can't in good conscience recommend staying on Docker for the long term. We recommend starting to plan your move to Kubernetes sooner rather than later. That decision is yours, and we will support you either way.
We will help you move
We know Kubernetes can feel daunting, and we want to take as much of that worry away as we can. We are writing migration guides and educational content, and if you are a Portainer Business customer running Docker or Podman, expect to hear from us so we can walk through your options with you individually. If you are not a commercial customer, we are still happy to talk.
For single-node deployments, we recommend KubeSolo, our lightweight Kubernetes distribution, which uses under 200 MB of RAM. For everything else, we recommend Talos Linux Kubernetes or any Kubernetes distribution of your choice.
Keep the Docker experience with Portainer-D2K
If your people prefer Docker, or your tools depend on it, Portainer-D2K lets you keep that experience on Kubernetes.
Portainer-D2K is a translation layer. It presents a Docker environment, either a single Docker host or a Swarm cluster, and translates each Docker API call into Kubernetes operations in one namespace. The Docker CLI, docker compose and the Docker API all keep working, so CI/CD pipelines and monitoring tools built for Docker don't need rewriting.
Because the requests now land on Kubernetes, the cluster enforces policy on them. Portainer-D2K refuses host networking, host PID and host-path bind mounts outright, and privileged requests are decided by the namespace's Pod Security level. That level is set by your cluster administrator or by Portainer, and D2K can't change it. If you leave the cluster default at privileged, a privileged request will still be admitted, so set the level to match the protection you want.
Portainer-D2K is free and available now, and it is built into KubeSolo, where you enable it with a single flag at install.
If you are still concerned
Please reach out. We'd much rather talk it through with you than have you make a decision based on what someone else assumed we meant.
Neil
Want us to help with your Docker to Kubernetes migration?
Fill out the form at the below link and our team will be in touch.