The Docker API Ceiling: Why Portainer 3.0's New Capabilities Target Kubernetes

The Portainer 3.0 announcement has stirred up a whole heap of emotions, particularly from the Docker loyalists, who have a Docker environment that is running well, delivering to their needs, and is being suitably managed today by Portainer. They are rightfully questioning why it appears that we are in-effect, turning our back on Docker and focusing our future product innovation efforts on Kubernetes.

Let me give you some background.

For Swarm users, if you go and check out the last three years of releases on the moby/swarmkit project, you will see they have all been bug fixes and security updates. Not a single new feature was added. Mirantis, who are now the primary Swarm contributors, made a support commitment (for their Mirantis Container Runtime / MKE customers) for Swarm through 2030, and the roadmap they have delivered has largely been about keeping the existing feature set stable and secure through the support horizon. Swarm is in maintenance mode, and no one is framing it as anything else.

For Docker engine users the story is different; the engine is genuinely getting innovation. The question is what type of innovation. The build side has picked up substantial new capability in BuildKit (SBOM and SLSA attestations, build secrets, frontend improvements, multi-platform build support). The runtime side has seen containerd image store go GA, the nftables backend replace iptables, an IPv6 rewrite, rootless mode maturation, and embedded containerd land experimentally in 29.7. Those runtime changes are about how the engine is packaged and how it moves packets, not new primitives for what the engine can safely execute. The workload-level primitives an enterprise needs, especially in the AI era (GPU scheduling and sharing, workload sandboxing, multi-tenant isolation, fine-grained authorization) are not on that list, and they are not on the roadmap.

Docker Engine has one trust level; API access equals root on the host, and Docker exposes no primitives for scoping that down. A management plane like Portainer, that sits above it, can gate what Docker exposes to the user (via the UI) but it cannot introduce authorization gradients on the underlying engine itself. Gain access to the engine, you have complete control. That leaves the operator with two legitimate positions; rely on the obfuscation and know that its not a code-level protection, or hide it and users get full access anyway. Portainer can obfuscate Docker's exposed capabilities, but cannot reliably secure them, because Docker does not give us the API primitives to do so. The Docker engine remains very much focused on the developer workstation deployment model / use case, and the buildkit and container runtime improvements prove that. It has not matured as an enterprise runtime to host critical apps inside a datacenter (or even at the edge).

Podman, from Red Hat, took a divergent path from the same original starting point; daemonless rather than a persistent root daemon, rootless containers as the default rather than an opt-in mode, pod semantics for grouping workloads, native systemd integration, and a purpose-built networking stack that does not require root. Its clear that Podman has focused on the enterprise-runtime rather than the developer workstation use case. Interestingly, if you choose to operate Podman in Docker-API compatibility mode, you lose a lot of these capabilities, so realistically, a full embrace of Podman and their libpod API is what is needed.

The constraints in the Docker API scope is what has caused us to also switch our focus for new features. We need to be able to deliver a highly secure managed container runtime, across fleets of environments, and we are unable to deliver on this promise with Docker. Whilst the features we have in the product today for Docker are wide-ranging, secure, and have served us and our customers well for 5+ years, we grow increasingly concerned with the future exposure. No one in the IT field can realistically state that the security risk in 2026 hasn’t materially changed. We have powerful AI models able to find even the slightest gap in network/infrastructure/application security, and to exploit with ease. We need to ensure that container runtime environments are highly secure, to protect against these new and ever-increasing threats. Heck, you just need to look at the software supply-chain compromises (eg npm), and you can see that weak internal security can no longer be tolerated. This is exactly why we made the hard decision to follow the technology leader, Kubernetes, as that ecosystem is adding the requisite capabilities to both the orchestration layer, and the underlying runtime, and this allows us to deliver on our promises.

Portainer 3.0 will keep supporting the Docker and Swarm feature set we have today, will not regress it, and will keep tracking Docker's own security fixes as they land. New capability investment (AI workloads, GPU scheduling, workload sandboxing) will be for Kubernetes. To help our Docker customers to bridge the gap, we made KubeSolo and D2K available as 100% free, OSS software, allowing a transition to Kubernetes security, without a material increase in operational complexity or resource overhead.

So, are we turning our back on Docker? No, but we are simply being realistic where the energy from the ecosystem is, and accepting that in order to provide an enterprise-class container platform, with security controls that can be trusted, we need to center our focus on Kubernetes.

Get 3 nodes free More from the blog