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

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 enterprise 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. From the end of this month we move to 3.0.0 as an STS release, and the next LTS will be 3.3.0 in December. More on this to follow.

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-Run is already live: a governed, self-service way for non-developer "business builders" to take the apps they've built with AI tools and deploy them safely onto the enterprise's own Kubernetes, without ever touching infrastructure. It's the answer to the wave of AI-generated apps sitting in folders on people's laptops with nowhere safe to run.
• Portainer-IDP is next: a full internal developer portal for the engineering teams who want a proper platform, not just a deployment target.
• 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-Operations takes the platform engineer's world out of the general UI entirely, into a GitOps-enforced console purpose-built for cluster management and day-2 operations.
• Portainer-AiGrid rounds out the family, aligning Portainer to the fastest-moving part of the ecosystem: running AI workloads on Kubernetes.

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 in the Docker/Podman environment addition screens, we will be presenting with a streamlined way to deploy Portainer D2K, our synthetic Docker environment which is 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. In addition, all of the new products we are shipping moving forward (Portainer-Run/IDP, Portainer-Command, Portainer-AiGrid) are Kubernetes-only.

We recommend you consider the migration from Docker to D2K or Native Kubernetes, as the future roadmap of Docker continues to looks uncertain, and its support in the ecosystem continues to diminish. We have been vocal about our concerns as they became more visible this year, and you can read these on insights.portainer.io.

The good news is that we’re here to help you with that migration.

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 to Kubernetes manifests, committing them to a Git repo, 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.

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

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.

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

Get 3 nodes free More from the blog