Portainer 3.0 is coming, and here's what it means for you

Not an Industrial & IoT customer? Read the general announcement here.

As CEO of Portainer, I have spent a lot of time watching how the container ecosystem actually moves under our customers' feet (rather than how vendor marketing says it moves), and the shift is unmistakable. Kubernetes has become the go-to tech for the container world. On top of this, AI-built applications and agentic operations have entered hard and fast. To keep up with this movement, we are making some significant and exciting changes and additions. What's driving them is the same goal we've always had at Portainer: making container operations as simple as possible, whatever the platform is underneath.

Change 1: We are cutting a new major version, 3.0

Portainer 2.45 LTS, which we shipped recently, is the last release in the 2.x line. We will soon move to 3.0.0 as an initial STS release, with the next LTS release coming soon after that. More on this to follow.

None of the above is possible inside our current codebase. Over the last two years, the gap between Docker and Kubernetes has widened to the point where staying fully featured across Docker/Podman, Swarm, and Kubernetes in a single codebase is no longer viable. Every new capability in policy management, our operations API, and our internal auth model has had to be built three times over, against three substrates, and two of them are no longer where the ecosystem is investing. So Portainer 3.x is a Kubernetes-first codebase, and that's what makes the single-purpose consoles above possible.

Change 2: We are building new single-purpose consoles

Instead of one general-purpose UI trying to be everything to everyone, we're shipping a family of single-purpose consoles, each built for one person doing one job well, and each designed for the world that's actually in front of us now: Kubernetes, AI-built applications, and agentic operations.

• Portainer-Operations is the one most relevant to your world. It takes the platform engineer's work out of the general UI entirely, into a GitOps-enforced console purpose-built for cluster management and day-2 operations.

• Portainer-Command is our MCP gateway for safe, secure agentic AI operations of Portainer itself. It keeps AI agents from making direct changes to Kubernetes by vending secure, expiring, read only roles. It forces every change through GitOps, and into your existing approvals chain. Agents can operate infrastructure without changing it directly, and if someting goes wrong you can easily rollback to the last working state.

Portainer-Run, a governed, self-service way for non-developer "business builders" to take the apps they've built with AI tools and deploy them safely is already live and alongside it we’ll be shipping Portainer-IDP and Portainer-AiGrid for the AI and enterprise side of the business. More on those at portainer.ai if you’re curious.

Underpinning all of it is KubeSolo, which we've moved closer to the official Kubernetes release track. It now embeds Portainer-D2K natively (more on this shortly), enabled with a single flag at install, meaning one KubeSolo deployment gives you a fully functional single-node Kubernetes cluster, a synthetic single-node Swarm cluster, and a synthetic Docker host, all from the same install, and all still under 200MB of RAM after moving the container runtime from CRI-O to crun. KubeSolo remains open source under MIT, with a commercially supported version available from Portainer, and it will underpin every deployment of the Portainer management server going forward.

Why are we cutting a new major version now?

None of the above is possible inside our current codebase. Over the last two years, the gap between Docker and Kubernetes has widened to the point where staying fully featured across Docker/Podman, Swarm, and Kubernetes in a single codebase is no longer viable. Every new capability in policy management, our operations API, and our internal auth model has had to be built three times over, against three substrates, and two of them are no longer where the ecosystem is investing. So Portainer 3.x is a Kubernetes-first codebase, and that's what makes the single-purpose consoles above possible.

What happens if you run Docker today?

If you run Docker today, nothing changes for you on 2.x. We will continue to ship security updates, bug fixes, and selective back-ports of 3.x features into the 2.x line, so a decision to stay put is a supported decision.

If you move to Portainer 3.x, you will see a few UI changes, namely a reorder of environments and a streamlined way to deploy Portainer D2K, our synthetic Docker environment powered by Kubernetes.

Of course, you can still add Docker/Swarm/Podman native environments, but these are now secondarily ordered inside the product. They remain there, they still work, and you can still operate them from the Portainer UI; what they will not receive are new capabilities as we enhance our policy engine, gitops engine, and observability layer, the parts of Portainer that handle permissions, automated deployments, and monitoring.

We recommend you consider the migration from Docker to D2K or Native Kubernetes when the time is right for your environment. When you’re ready to look at Kubernetes, I think you should take a closer look at KubeSolo paired with D2K. KubeSolo is a single-node Kubernetes distribution that now embeds D2K natively, on with a single flag at install. One KubeSolo install gives you a working single-node Kubernetes cluster, a synthetic Swarm cluster, and a synthetic Docker host. And all under 200 MB of RAM, the same footprint as running Docker or Podman directly.

For those running Portainer alongside PLCs, SCADA systems, or other OT infrastructure, none of this touches those systems directly. This changes the container management layer, not your production control systems. And if your site is air-gapped or runs with limited connectivity, how our GitOps-based workflows apply to that setup is worth a direct conversation with us to work through your specific setup.

Moving your workloads to Kubernetes

In an ideal world, you’d just deploy your applications on a Kubernetes cluster and be done. When you’ve got net-new applications, this is straightforward, especially through Portainer. But with existing Dockerized applications, this becomes more complicated.

To make this easier, we are soon releasing a migration tool (as a Portainer Add-on) that will help you move natively from Docker to Kubernetes, transforming your Docker containers/stacks into the configuration files Kubernetes needs (manifests), storing them in a Git repository (a version-controlled file store your team may already use), and then deploying them on Kubernetes using Portainer’s native GitOps. This is a “slipstreamed” migration to native Kubernetes.

We’re also able to help you directly. We’re reaching out to our commercial Portainer Business customers alongside this announcement to discuss how we can help them make the move. If you’re not a current commercial Portainer Business customer we’re happy to chat too - our goal is to help you modernize by moving to Kubernetes and ensure that the move is as smooth as it can be.

My devs prefer Docker, and don’t want Kubernetes!

We have a fix for that: Portainer-D2K.

Portainer-D2K is a Docker translator for Kubernetes; it presents itself as a synthetic Docker environment (either a single node, or a swarm cluster) and it lets your people deploy and manage applications on a Kubernetes cluster using Docker CLI commands, including docker compose. It also presents a Docker-compatible API so that tooling such as CI/CD and monitoring stacks built exclusively against Docker keep working without a rewrite.

Portainer-D2K is free, runs as a Kubernetes deployment on a cluster, and is available now.

What happens to Portainer CE?

CE has been the community edition for the last ten years. It will continue on the 2.x codebase. It will not receive the 3.x changes. Portainer 3.x will remain free for the community under our 3 Nodes Free program, so nobody in the community loses access; what changes is that we are not cutting a separate CE build of it. 3.x is tailored specifically for an enterprise audience (the policy model, the operations API, the single-purpose consoles all assume that shape of user), and releasing that as CE would misrepresent what it is and who it is for.

The roadmap for Portainer

As mentioned above, if you are a Portainer Business commercial customer running Docker or Podman today, expect a note from us, or if you’d like us to get in touch with you complete this form. We will walk you through your options individually rather than leaving you to work it out from a blog post. Our recommendation is KubeSolo for single-node deployments, or Talos Linux Kubernetes (or any Kubernetes of your choice) for everything else, with Portainer-D2K as a translation layer if your people prefer (or tools require) the Docker UX.

If you’re a current Portainer customer, what happens next?

The Portainer 3.0 initiative represents a significant amount of evolution in the product direction. If you would like to learn more about what we're planning going forward, we've prepared a document that goes into detail about the ideas that underpin the move, what it means for those on Docker, and what to expect in future releases. You can access the Portainer Product Strategy at this link.

We are really excited by the future of Portainer 3.x, and especially the single-purpose consoles that will be introduced. These will dramatically simplify the operation of your application estate, across a wide variety of your internal users. And with Kubernetes continuing to innovate at break-neck speed, especially in the realm of running AI workloads, we will be able to invest significantly more engineering time aligning to that new future.

Neil