We on-boarded onto Sagetap last week, a matchmaking platform between vendors and end-user customers (they call them sages). The first week has been extraordinary.. so much new opportunity, which would have cost us 100x via conference sponsorship, advertising, and traditional demand gen approaches.

Here’s how it works....

Vendors list their products on the Sagetap platform, which has thousands of verified senior tech leaders, each of whom has disclosed their purchase making authority, sign-off budget, company size, industry, and role in the business (all very useful for a vendor.. it saves trying to BANT up front). The leaders research solutions for initiatives they are undertaking (there is a really nice search function that matches solutions to their criteria). The IT leader can then reach out to the vendors they feel are a good match, anonymously, express interest, chat in-platform, and when ready request a (strictly time boxed) platform-facilitated Zoom meeting.

Ok, so a listing platform is not that smart on its own.. what makes it smart is everything that happens around the meeting.

For most interactions, the vendor pays for the privilege, so we are incentivized to ask fit questions up front, before taking the call (what are they trying to achieve, what are their requirements, constraints etc). The Zoom meeting (like all prior engagement) is anonymous, and the IT leader only reveals who they are after the call ends, if it was worthwhile enough to want a follow on. Vendors are banned from attempting to uncover the persons identity too.

Just like Uber, both sides score the interaction. The IT leaders score every vendor after the call, and vendors who accumulate low scores get removed from the platform. Other users of the platform see the feedback score as part of their research, so a badly behaving (low score, but not low enough to be booted off) vendor likely gets discounted before the first message is even sent. We can see how other vendors rated each IT leader too, so we know whether they are a good candidate for a meeting.

Think about what that does for a senior IT leader. They get their product research done without an inbox full of vendor funnel management (and annoying BANT questioning, or being immediately forced onto a sales call). They only enter a vendors sales funnel once they are confident it is worth doing, after the Zoom meeting completes. It is basically a self-managing speed dating platform for IT buyers.. and I mean that as a compliment!!

For us, every conversation now starts with someone who went looking for our type of solution (for a problem they have today), told us what they are trying to solve, and decided the call was worth their time. Compare that with a conference lead scan. Yes this costs us money, but its money well spent.

This is gold. We are going all in.

If you are an IT leader in my network, I encourage you to take a look.

Think of it as hiring the most talented consultant on the planet and sitting them at a desk on day one. They have a ton of experience, but zero knowledge about your business. They do not know why you discounted that deal last quarter, which product line quietly loses money, what your customers complain about on the phone, or how your fulfillment process really runs (as opposed to how the process document says it runs).

So where does that knowledge live? It sits in your people’s heads, their email, your SharePoint, Teams/Slack discussions, your file servers, your process documentation, your sales & marketing plans and your old proposals. Much of it is unstructured, scattered across systems that were never designed to talk to each other, and some of it was never written down at all.

The obvious shortcut is to use LLM connectors, via MCP, and we are all told that if you pay them enough, your data remains private to you. Maybe so, but two problems remain. You must still disclose to your customers that their information is being processed by a third party, and data that sits with a provider can still be obtained by law enforcement through legal process served on that provider. I am not a lawyer, and the exact exposure will depend on your jurisdiction and your contracts, so have yours reviewed; either way, the material you would be entrusting with the LLM provider is pricing, customer detail, strategy and intellectual property, which is the most concentrated version of your crown jewels you could assemble in one place.

This is why running a local RAG (retrieval augmented generation) engine is critical. The mechanism is simple enough to explain; the model does not need to be trained on your data, because at the moment someone asks a question the engine retrieves the handful of passages most relevant to it and places them in front of a local LLM, which then answers from your material and can point back to the source documents it used. Getting there means ingesting everything, chunking it into pieces small enough to retrieve precisely, and making it searchable.

Permissions deserve their own sentence, because retrieval must respect the access controls you already have; otherwise you have built a very efficient way for the intern to find the board paper. This is probably the most overlooked concept in the race to AI enable everything!!

On top of the retrieval layer sits the LLM / conversation router, which is the piece your people actually touch. They hit one endpoint, and the router decides where the question is best answered; a question about your pricing, your customers or your internal process goes to a local LLM with local retrieval, whilst a general question about a public programming language or a published standard can go to a cloud LLM provider, if your policy allows, with nothing from the crown jewels attached. The decision is driven by data classification and policy, not by the user remembering which tool is safe for which question (and I would not bet on any of us remembering, right!!).

I also know what the pressure looks like from the other side of the desk. The board and the CEO wants an AI story, and somewhere a senior executive is saying “we have this under control, we have licensed the enterprise tier of a leading provider, and the contract says our data is private”. The CIO and CISO are the people who then have to be comfortable that this is actually true, and nobody wants to be the one who signed off on the crown jewels leaving the building. A local RAG engine and a router give them an answer they can defend, and give your people an assistant that knows your business.

Now the sales pitch :) Our own answer to the ingestion problem is Portainer-AiGrid, a self-hosted appliance that ingests and retrieves your document corpus, using the idle GPUs on your workstations to do the heavy lifting. No need for you to spend $$ with a cloud RAG provider, or to try and deploy an army of MCP servers to directly connect cloud LLMs to your internal data. Internal data stays internal at all times, where it should be.

I recently spent some time going through what CIOs and CISOs are saying publicly about vibe-coded apps (the ones business folk build themselves with Claude, ChatGPT, Lovable and the like), and the most common answer was no. Not “not yet”, not “let’s work out how”.. just no.

And honestly, I get it. If I were sitting in the CISO chair, looking at an app someone in finance built over a weekend, connected to the ERP and running on a vendor’s cloud, I would be saying no too (loudly!!).

The problem is, blocking something never works.. it never has, and it never will. When you say no, the business builder doesn’t stop building, they just stop telling you. The app moves to a personal account, on someone else’s cloud, and out of sight of every control you have spent years putting in place.. which is the exact opposite of what the no was meant to achieve.

So I pulled together the ten objections that came up most often:

1. Apps with sensitive data get published to the open internet, often with no authentication.

2. Hardcoded secrets end up in code and in public GitHub repos.

3. IT can’t see these apps, and they aren’t in any inventory.

4. They skip governance, architecture review, security review and change management.

5. Business builders don’t understand application-level authentication, access control or data classification.

6. AI-generated code is insecure by default.

7. Nobody supports or maintains them, and the builder may have left.

8. They create sprawl and a new wave of technical debt.

9. They can’t meet SOX, SOC 2 or regulatory audit obligations.

10. The vibe-coding platforms themselves are a third-party risk.

Every one of these is a real concern.. none of them are unreasonable. But read the list again and you’ll notice that almost all of them are about where these apps run, and who controls that, rather than about business people building things in the first place.

I’ve written up an answer to each one over on the Portainer blog: Ten reasons CIOs and CISOs block vibe-coded apps, answered

KubeVirt is powered by KVM, the same hypervisor that carries a large share of the public cloud, and delivers near native raw performance (much like VMware). However where many people initially mess up is “forgetting” that with VMware, we engineered a storage subsystem specifically optimized for running VM disks (and they built a file system specifically optimized for this too), and unless you do the same for KubeVirt, you should expect a pretty significant IO performance loss, regardless of the VM operating system.

Memory management, however, is materially different between the two.

ESXi treats a VM’s memory as a promise; it schedules on the assumption that guests will leave some of their allocation unused, and it reclaims under pressure through ballooning, compression, and finally host swap. The balloon driver does most of the work; the hypervisor asks the guest to give memory back, and the guest, which knows which of its pages are cold, trims its own cache and pages to its own pagefile. That mechanism is what has allowed vSphere clusters to overcommit RAM 2:1 (or more) for decades.

Kubernetes schedules based on requests. A VM lands on a node based on the memory its virt-launcher pod requests, and if that request equals the guest’s configured memory, density is 1:1 (in practice slightly worse, because virt-launcher requests a little extra on top of guest memory to cover QEMU overhead). OpenShift Virtualization (the most commonly used KubeVirt platform out there) implements overcommit by setting the request below the guest size (the documented default when enabled is 150 percent). Free page reporting (kubevirt’s “ballooning”) runs in the reverse direction to ESXi ballooning; the guest volunteers pages it has freed and the host reclaims them. The safety net under real pressure is swap, managed by the wasp-agent component, which enables swap for the VMs. Red Hat’s guidance is a fast dedicated swap device per node, but swap even on an NVMe is materially slower than RAM.

Windows Server interacts poorly (from a resource efficiency standpoint) with the KubeVirt model.

Free page reporting is a Linux guest feature; the shipped Windows virtio-balloon driver does not implement it, so a Windows guest reports nothing back to the host, full stop. Windows also holds unused memory as standby cache and trims it only under pressure, so even a future Windows implementation would have little to offer. The common workloads compound it; SQL Server grows its buffer pool to max server memory and holds it, Exchange behaves the same way, and file servers cache to the ceiling. Under ESXi the balloon forced all three to release, and those workloads tolerated it in practice; under KubeVirt there is no host-driven reclaim, so those VMs stay fully committed for their lifetime regardless of actual load.

The planning consequence is that Windows Servers hosted on KubeVirt must be backed with in-host RAM sized at close to 1:1 to VM requirements. That exposes right-sizing debt, because most Windows estates carry years of 8GB and 16GB allocations that vSphere overcommit absorbed for free; on a request-based scheduler every gigabyte of that padding becomes a scheduled gigabyte that has to be purchased (and at todays CRAZY prices!!!).

Windows Server licensing then multiplies the density loss. Datacenter is licensed per physical core on every host eligible to run a Windows VM, so whatever percentage of additional nodes the density model produces applies three times: to hardware, to the OpenShift subscription, and to Windows Server core licensing.

Linux VMs sit at the other end of almost every one of these considerations. A Linux guest releases page cache readily, so free page reporting delivers real reclaim; the typical workloads (web tiers, middleware, application servers) are quiet outside business hours and release memory by design; the virtio drivers are in the mainline kernel, so nothing needs rolling out; and there is no per-core operating system licensing on the host. A Linux-heavy estate can approach vSphere density on OpenShift Virtualization with right-sizing and tuning; a Windows Server estate should plan to pay for what it allocates.

So looping back to the very start of this article… what is our advice when asked about KubeVirt vs VMware? Simple, if you predominately run Linux, then KubeVirt is a pretty good way to achieve server virtualization with a Kubernetes “feel”. If you run Windows, maybe think again.

Neil

Subscribe now

The pressure on those manufacturers to deliver more efficiency has not softened; if anything, it has hardened. Running 24x7, reducing wastage, reducing reject rate, keeping equipment running longer between failures, forward-predicting the failure that would take a line down for a shift; none of that is achievable in any real way with paper-based OEE and a SCADA view of the world.

So the shortcut has taken hold, and rather than commit to a multi-year, capital-heavy Industry 4.0 rollout across the plant, manufacturers are feeding whatever they have (SCADA telemetry, technical drawings, PLC programming code, historical reject data) into an AI and asking it to find patterns in the snow; the pitch is that AI will surface the improvements that were always there in the noise, at a fraction of the incremental expense of a full Industry 4.0 rollout.

The AI almost always finds real improvements, and some of them are significant. The problem starts when someone actually has to act on them.

I am a petrol head at heart, and if someone offered me an AI generated ECU tune for my already fast car, promising another 20% out of the engine; do I take the promised gain and accept the risk, or do I stick with the known?

That is the same conversation an ops manager is having with themselves in front of the AI dashboard; the line has been running for years at a predictable output, the manager knows exactly what it delivers, what it consumes, and what fails first. Now an AI has now shown up with a set of PLC parameter changes that promise another 20% of efficiency for what looks like free. But is it really free? What second-order effect does changing that parameter have on the station three positions downstream that the AI has never seen fail, and how confident is the manager that the AI modelled that dependency at all?

Layered on top of those questions are the general-press horror stories the manager has read (the chatbot that invented a court case, the assistant that told someone to eat rocks, the model that hallucinated a medical dosage) and thirty years of over-promised industrial software that has earned every operator the right to be skeptical of anything claiming to know their line better than they do; sticking with the known specification is the rational instinct, and the AI findings sit on the desk unactioned.

So you end up in quite the conundrum. You wanted a miracle, in that you wanted a way to get to Industry 4.0 grade efficiency without paying the Industry 4.0 grade capital bill, and AI found you one. It looked at the data you already had, it found the nuggets, and it handed them back to you with recommendations. And then you let the findings die in a ditch, because the version of you that commissioned the AI project is not the version of you that has to sign the change order on a live production line.

The way out is not “trust the AI more,” but to build the verification loop the AI’s output needs. Take a finding, cross-check the mechanism it described with the engineer who has run that line for a decade; if the engineer agrees the story is plausible, run the change in a controlled window (a shift, a batch, a non-critical product) with the old parameters ready to restore; measure the delta against the AI’s prediction, and either roll the change wider or throw the finding out. That is the loop every credible finding survives and every hallucination dies inside of; you do not need to trust the AI on faith, you need to build the environment in which the AI has to prove itself.

The emotional reality is that industrial teams are being asked to hold two things in their head at once; the pressure to deliver efficiency they cannot deliver on the current setup, and the fear of a technology that has burned enough people in the general press to make caution feel like the safe answer, when caution is often the most expensive answer on offer. Doing nothing with a finding that would move the line from 70% to 80% is not a neutral choice; it is a choice to keep leaving that output on the floor, quarter after quarter, while your competitors run the verification loop and take it. The miracle is real, it just needs a validation layer, and no one is going to build that for you.

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.

Subscribe now

The people wholly embracing the Agentic AIOps wave are the platform team, the DevOps folks on triage, and the developers supporting their own apps, and these also so happen to be the people whose assigned access has the widest blast radius on the platform. The agents therefore are effectively highly permissioned by default, which is a security position of implicitly trusted. This flies in the face of normal “permission of least privilege” operational models.

Like it not, this is the current reality of Agentic AIOps against a container platform, and given the meteoric rise in popularity of agentic harnesses, its very much something running inside every Kubernetes equipped enterprise today.

GitOps was a “must” until it wasnt…

The Kubernetes community already made it very clear that GitOps and Kubernetes go hand in hand, and that directly manipulating a cluster is a fools-errand. Go to any conference, listen to any talk, read any blog that mentions Kubernetes and the common thread is that no “serious” Kubernetes team in the world would let a junior engineer type kubectl apply against production, because it would fail the code review, fail the change management process, and fail the intuition of every senior engineer on the team. Argo, Flux, and the CNCF GitOps Working Group exist because we, collectively, believed direct-apply was wrong, and that every change should be reviewable in Git, reproducible from what is in the repo, and rollback-able through git revert.

Then the AI turned up, and MCP servers for the plethora of CNCF discrete tools made their appearance. These were all loaded into an engineers AI agent with glee. What then happens is that the AI agent runs countless kubectl commands directly against the cluster; it does not open a pull request, it does not wait for a peer reviewer, and it does whatever it decided to do in the moment it decided to do it, at machine speed. What you have there is not ClickOps, because ClickOps at least has a human doing the clicking; it is ClickOps performed by a probability distribution, and the same team that would not accept a manual kubectl apply from a junior engineer is now accepting it from a language model with three seconds of context. Did we all quietly decide the discipline stopped applying the moment the operator was not a person, or did we just not notice we had made the exception?

AI has a nasty habit of never providing the same output for the same input, and that means trying to trace a change becomes infinitely more problematic; reproducibility matters. Arguably more important is the ability to roll a change back via a git-revert. Why? Well try asking AI to join the incident call to explain their thinking behind a change made 5 changes ago!!

The market has made peace with the exception

You would think, given how visible this problem is, that at least one product on the market would have built its answer around the discipline the community already believes in; almost none have. The horizontal MCP gateways (Kong, Solo’s agentgateway, Microsoft, IBM Context Forge, and the growing list Gartner is now predicting every API gateway vendor will ship) will allowlist tools and audit calls, and will happily let the write tools through, because the gateway does not know what a Kubernetes cluster is. The just-in-time credential vendors (Teleport, hoop.dev, StrongDM) will shorten how long the token is valid, and the AI still runs kubectl apply against production with it. The Kubernetes-native agent runtime (kagent, the closest CNCF-adjacent answer) will pause on a “requireApproval” tool call and ask a human to click approve, and the moment the human clicks, the change goes direct to the cluster. The kill switch and control tower vendors (Straiker, Zenity, Palo Alto’s Secure AI Agents) will shut the agent down after it has already applied the change. The reference implementations that actually take GitOps seriously (kubemend, gitops-drift-agent, Cast AI’s agentic runbooks) are single-purpose autonomous agents rather than a governance layer for the general case. Every one of these products is legitimate in its own frame; none enforces GitOps as the mandatory path for AI-originated changes, and most treat that as a feature rather than a gap.

What a real answer would have to look like is not mysterious. Every primitive it needs already exists. Kubernetes has read only RBAC roles, we already have humans peer reviewing manifests in GitHub, and we have GitOps reconciliation to deliver changes to environments. The only problem is forcing AI to use these primitives properly rather than going around and making direct changes to prod.

All agentic operations must go via a Kubernetes aware gateway, so that it can intercept “change” at the source rather than let them through. The gateway has to issue short-lived read-only credentials with a rationale the model itself supplies. It has to intercept every write intent and open a pull request against the enterprises GitOps repository, with no exception path. It has to apply approved changes through GitOps reconciliation, so the rollback is git revert. And it has to have an authoritative kill switch that revokes the credentials it issued, rather than an after-the-fact network approximation. None of that is novel individually; the missing product is the one that composes all of it, opinionatedly, and refuses direct-apply as a path at all.

Every CISO I talk to is being asked to say yes to putting AI into operations; they know the productivity story is real, and they also know that when the change goes wrong they will be the person in the room who allowed it in. Every platform lead is being asked the same question from the other side; they built the GitOps discipline, they defended it through three cycles of ClickOps advocacy, and they are watching their own team’s AI tooling bypass it. The honest answer to both is the same one the community reached the first time around; the discipline was right for humans, and it is more right for AI, and any product positioning itself as “AI governance for Kubernetes” without enforcing GitOps as the only change path is asking you to abandon the change control you already had.

A product like this does not exist yet because the product needs opinionated integration between three worlds that are usually owned by three different vendors. The agent-facing surface, the Kubernetes management surface, and the GitOps runtime have historically been three separate roadmaps, and a product that enforces AI-originated changes as PRs that a human merges and a reconciler applies has to own all three at once. No vendor with only one of the three can build it, and the vendors with two are not the same vendors…. until now.

That shape of product is what we are building at Portainer, and it will be called Portainer-Command. Keep an eye out for it; we will have more to say at KubeCon in Salt Lake City this year, and if any of the pattern above is familiar to you, that is where you will find us.

When did “does everything” become the definition of “good”?

That is not “good”. That is a bill for stuff you will likely never use!

The picture above is the market as it actually sits today. Two well-populated ends, and an empty middle.

On the left, CNCF DIY. Your internal teams (or a highly paid consultant) stitch twenty or thirty discrete OSS tools together, and call it a platform. Zero license costs, enormous people/support cost, no fun when something breaks or needs upgrading.

On the right, a pre-bundled version of the exact same thing. Red Hat, Nutanix, VMware, AWS, and most of the rest of the market. They take those same twenty or thirty CNCF tools, wire them together, put a fancy UI over the top, staple a support contract on the front, and sell it as a platform. You are buying a support contract wrapped around somebody else’s assembly job, and paying to run every tool in the bundle whether you use it or not.

Same complexity. Different invoice.

Why oh why is there nothing in the middle. No goldilocks product. No “just enough of what you need, and nothing else”. Which is a shame, because that is what most teams actually need.

If only the analysts rewarded “Fit” and not “Features” as their gauge of “good”, then maybe, just maybe, the market would stop over-investing in technology that sits idle 99% of the time.

Here at Portainer, we are a bit rogue… we don’t follow the norm, and we love to do things differently. We PURPOSELY built the product to sit in that unaddressed middle. One genuine tool with a lot of inbuilt capability, not a dozen OSS projects dressed up as our own. Lean, focused, and priced appropriately for what you actually use.

If our “crazy” approach is one that appeals to you, come have a chat with us. We dare to be different.

Neil

The problem is, they are not actually asking for what they think they are.

What they want, when you push on the request, is to manage RedHat OpenShift, Rancher, VMware VCF, Mirantis Container Cloud, some EKS, some AKS, and usually a couple of other distros that landed as a proof of concept that never got turned off. What they think they need to buy is a Kubernetes multi-cluster/fleet manager, because all of these platforms claim to be a Kubernetes compliant distro (and they are, sort of…).

What they do not yet realize is that a fleet manager cannot help them, because the environments they have inherited are not just bare Kubernetes clusters; they are platforms, and the Kubernetes distro underneath is only one component of what the vendor sold, alongside its own operator, its own management console, its own identity model, its own storage integration, its own registry, and its own opinion about how upgrades happen.

You cannot just reach around all of that and manage the Kubernetes directly. Well, you can, but the moment you do, the vendor’s own management layer is completely blind to whatever you changed.

What the platform team actually needs is something quite different from a fleet manager. They need a management console federation tool; something that can provide a seamless synchronization of in-cluster user accounts, RBAC permissions, end to end visibility of application deployments, of cluster state/health/capacity, alerting and monitoring, centrally trigger and monitor Kubernetes cluster upgrades (including the requisite management console updates for the distro). This is required so that OpenShift OKE stays managed by OpenShift Platform, Rancher RKE/k3s stays managed by Rancher, VKS stays managed by VCF, EKS stays managed by AWS, etc.

Today, nothing like that exists. Every vendor in the market is either a fleet manager for a specific distro (Rancher for RKE, ACM for OpenShift, and so on), or a cross-distro Kubernetes manager that treats the underlying platforms as if they were just vanilla Kubernetes and quietly bypasses the vendor’s own control plane. There is no product that federates the management consoles themselves.

I need to be honest here because Portainer sits in the second camp for this specific problem. Portainer can absolutely manage multiple Kubernetes environments, including OKE, RKE, VKS, and the various cloud provider distros, and it does that well for teams whose primary constraint is a consistent operator experience across clusters. But if you already own OpenShift, and you already own Rancher, and you already own VCF, and each of those has a fully adopted management layer, then pointing Portainer directly at the underlying Kubernetes environment means fully handing over operational management to the Portainer layer, and ceasing use of the vendors own platform tooling.

The confusion at the root of all this is between discrete distros and discrete management tools. Most platform leads I speak with are treating them as the same problem; they think that if they can rationalize the distros, or at least manage them uniformly, the management tool problem will follow. It will not. The distro is the runtime; the management tool is the operational control plane; and it is entirely possible to have five distros with one management tool, or one distro with five management tools, and each combination has different consequences for governance, audit, upgrade paths, and how much institutional knowledge sits with which team.

Keeping every vendor’s native console alive alongside a federating layer above them is a defensible choice, and I understand why teams reach for it; it protects the investment and it keeps the compliance posture intact. But sometimes the smarter move is simplicity over complexity, and the cleanest way forward is to pick a single management tool, and then scale each of the underlying platforms down to nothing more than its specific distro. Let OpenShift be OKE, not the full OpenShift platform experience; let Rancher be RKE, not the Rancher management surface on top; let VCF be the VKS distro, not the whole VCF operator layer. Then one management tool sits above all of them, consistently, and the native consoles that used to be the source of truth are no longer trying to be.

That is a much bigger conversation than “buy a fleet manager”, and it is the conversation platform teams inheriting these estates need to be having with their executive sponsors before they sign anything.

If you are in that position now, and you want to talk it through with someone who has seen how these federations play out in practice (and where the traps sit that only surface at the second upgrade cycle), my team at Portainer are happy to help, no obligation, all that is needed is a call.

At the same time, we have been publicly honest for a while now about the direction Docker is heading. I wrote earlier this year about the difficulty Docker CE faces as a sustainable free product (“Can Docker CE survive in a sea of...”) and about the fallout from the v29 release and what it signals about the project’s operational discipline (“Docker v29 and the fall-out”); both are on insights.portainer.io, and they are what initially triggered my research into an “offramp”.

The trajectory is beginning to concern us, and we think it should start to concern you too, with enough seriousness that you look into planning a docker “exit” now, vs doing so in a panic later.

Why an “off-ramp” though?. With Kubernetes, there are more moving parts, more failure modes, more configuration surface, and a much larger operational vocabulary that your team is expected to speak fluently. Dropping in Kubernetes as a replacement for Docker is not a 5 minute task, nor is it operationally neutral. If a Kubernetes vendor tells you otherwise, they are trying to sell you something. Spinning up a Kubernetes environment overnight has been doable for years; getting you onto Kubernetes without your operational load doubling and your team’s Docker muscle memory becoming useless overnight is the harder problem, and that is the one we set out to solve.

The first piece pf the puzzle we built was KubeSolo (kubesolo.io), which is a single-binary Kubernetes distribution that we deliberately fit inside the memory and CPU footprint of Docker or Podman. You install it, and you get a real Kubernetes API on a single node, with no separately-managed internal components, a CLI TUI for the operational surface, and near-zero ongoing operational overhead for the Kubernetes layer itself; the operational shape looks a lot more like Docker than like a “real” Kubernetes cluster. KubeSolo solved the “I have a Docker host and I want a Kubernetes host of the same weight class” problem, but it did not, on its own, solve the harder one, which is that your applications are defined in docker-compose files, your CI pipelines shell out to the Docker CLI, and every operational reflex your team has is Docker-shaped.

For that, we built d2k (github.com/portainer/d2k), which presents a Docker-compatible API endpoint on top of a Kubernetes backend. The Docker CLI works against it, Docker Compose works against it, and the workloads land as native Kubernetes resources on the cluster underneath, without asking anybody on your team to learn a Kubernetes primitive on day one. We then tested d2k inside Portainer and validated that our existing Docker to Docker migration feature moves running applications from a real Docker environment to a d2k-backed synthetic Docker environment on Kubernetes, in place, without a rewrite.

What that gives you, put simply, is a way to take a Docker deployed application estate off Docker and land it on Kubernetes with the operational surface still looking Docker-shaped on day one, and with the real Kubernetes waiting underneath for when your team is ready to work with it directly.

Even with the offramp in place, Kubernetes has meaningfully larger operational overhead than Docker, and no distribution ships that overhead away; a well-chosen distribution pushes most of it onto somebody else, so your team does not carry it. The difference between a manageable Kubernetes and an unmanageable one is almost entirely a question of who is on-call for the pieces of the stack that fail.

For single-node deployments, and for the branch office, edge site, and small production node cases, KubeSolo is the right answer for the reasons already covered; the operational load of the Kubernetes layer is close enough to Docker’s that your existing team can absorb it, and the front-end is the real Kubernetes front-end, so the skills your team builds transfer directly to any larger cluster you land on later.

For clusters, our recommended approach is Sidero’s Talos Linux with their Kubernetes bootstrapper, backed by a Sidero support agreement that Portainer OEMs. The Sidero support agreement means Sidero take responsibility for triaging and remedying the Kubernetes operational failures that will inevitably occur on any real cluster; functionally, you get KaaS on hardware you own and operate, without handing your workloads to a hyperscaler. That is a materially different proposition to hand-rolling a cluster and hoping your team can support it.

If your workloads can live in public cloud and your CFO is comfortable with the run-rate, managed Kubernetes from your hyperscaler of choice is of course the easiest operational of all; that is full outsourcing of the platform, and it is a bargain where it fits. Where it does not fit, for sovereignty, data gravity, cost at scale, or an existing on-premises footprint you are not going to abandon, Talos with Sidero support is as close as you can get without handing over the keys.

Does this mean Kubernetes equals Docker, operationally? No, not at all. It is, however, the closest you can get to a Docker-shaped operational experience without fully outsourcing the operation of your platform, and it comes with a real migration path (KubeSolo, d2k, and Portainer’s Stack migration) that lets your team keep using the Docker tooling they know, while the runtime underneath quietly becomes Kubernetes. We built this specifically because we know what it feels like to be sitting on a Docker estate today, watching the ground shift, and being told by every vendor in the market that the answer is Kubernetes without any of them offering you a path that starts from where you actually are. That path is what we have built for you, and it is there for the day the trajectory of Docker convinces you it is time to take it.

Managing Docker is like organizing a holiday by yourself. You are responsible to book the flights, the accommodation, you sort the transport at each end, and you build the activity schedule; every decision is yours, every booking is a command you issue, and every confirmation comes back to you individually. If a flight gets disrupted or canceled, you find out because your phone buzzes; if the hotel loses your reservation, you notice at check-in; if the rental car company is closed when you land, you improvise. Nothing is watching over the trip on your behalf, so any delta between what you intended and what is actually happening is yours to spot and yours to fix. It works, and for a single trip it works fine; the reason most people still book their own weekends away is that the overhead of a travel agent is not worth it for one flight and two nights.

Managing Kubernetes is like organizing the same holiday, but through a travel agent. You send an email describing the trip you want (dates, destinations, budget, preferences), the agent replies to confirm they have received it, and then they go and make it happen. If a flight gets disrupted halfway through the trip, you do not find out from an airline app at 2am; the agent rebooks you, sends a short note explaining the new itinerary, and the trip continues. You are not managing the process; you described “good”, and someone else is on the hook for keeping reality aligned with that description. The agent costs more than doing it yourself, and for a weekend away it is overkill; for a three-week multi-country trip with twelve moving pieces, it is the only sane way to travel.

The mechanics map onto the analogy closely. With Docker you talk to the Docker socket or the Docker API, and every command is executed at the moment of receipt; if the command succeeds you get a container, if it fails you get an error, and either way the conversation ends there. Nothing is watching the container after the fact. If it crashes, it stays crashed until you notice and run another command; if the host reboots, your workloads come back only if you (knew to) set the restart policy correctly; if you meant to run three replicas and one dies, you now have two, and the number will stay at two until a human intervenes. This is fine for a developer laptop, a build agent, or a single-purpose host; it is not fine for anything you would rather not be woken up about.

With Kubernetes you describe your desired state to the API server (using kubectl, Helm, or a GitOps controller), and the API server responds with a 200 OK, which means “request received, will be actioned”. A control loop then compares desired state to observed state on a continuous cycle, and where the two do not match, it takes whatever action is needed to bring them back into alignment. If a pod dies, the controller starts a new one; if a node goes offline, the workloads reschedule elsewhere; if you asked for three replicas and observe two, a third appears without anyone typing anything. The system is not “self-healing” in any magical sense (that phrase is oversold in the marketing); it is a loop that keeps checking whether reality matches the spec, and correcting reality when it does not.

At ten containers you can be your own control loop; at a thousand containers across dozens of hosts, you cannot, and neither can anyone on your team (regardless of super-human they may appear). You need to describe “good” once, in a form the system can compare against, and let the system do the reconciliation work continuously. That is what declarative buys you, and it is why the Kubernetes operational model wins as fleets get larger; the imperative model does not scale because the human in the loop does not scale.

Neil

This, and more, is described on kubeschool.portainer.io, in language that is easy to understand.. its not a tech deep-dive, its designed to help you understand the mechanics. If you started your Container adventure learning CLI commands, maybe its good to learn the foundations. If you are just getting started, I strongly recommend getting started with the foundational knowledge.

(and YES, I used AI to create me the comic strips, I’m not that good at graphic design!!)

My team and I completed dozens of migration projects, and all of them had rock solid business cases, promised savings that self-justified the migration, and further promised flexibility and redundancy that an IT exec could only dream of. What was really interesting though is the follow up with the clients 9, 12, 18 months after the migration. All of them struggled to achieve the cost savings, and most of them hadnt really capitalized on the flexibility that being “in the cloud” gave them. Further, conversations with the CFO were becoming heated, as they looked at driving opex reductions to improve the business bottom line. As we all now know, you cant just stop paying for the cloud once you are in it (but you can sweat on-prem hardware!!).

Anyway, I was reminded of all of this last night, in a conversation with a colleague about the current wave of enterprise pushback against AI. This looks eerily familiar to the cloud pushback of 2017, and we already know, roughly, what has to happen next.

Cloud had reached the point where every CIO had to have a story, a migration plan, and every enterprise architect suddenly had a mandate to “get us to the cloud”. Everyone followed the same strategy, “lift and shift”, pick up (figuratively, obviously) the on-prem data center estate, drop it into AWS or Azure, and declare victory. There were even tools to help facilitate the V2C (Virtual to Cloud) migration, conveniently provided by the cloud vendors… of course 😉. The problem was, when you are procuring hardware for you on-prem environment, you are buying sufficient capacity for 3-5 years in the future, and for those running Virtualization, likely they were over-committing their physical server 2 or 3 times in VM allocation. Well, when you pick up those oversized servers, and you move the VMs at 100% allocation, what you end up paying for in the cloud is astronomical. Astronomical^2 when you really think about it.

What followed was the actual work of cloud adoption; the right-sizing, the refactoring, the decommissioning of workloads that never should have moved in the first place, the redesign of applications to use cloud-native services rather than pretend the cloud was a rented data center, and the gradual construction of cost governance so that engineers could not spin up whatever they liked whenever they liked without someone noticing. That work is the reason that today, no serious CIO disputes that cloud is a genuinely good deal for the business. Cloud got good because the industry learned how to operate it, and not before.

AI is right now sitting exactly where cloud was in that first ugly phase. Every board has a mandate, every executive has a story, every enterprise has piled in, and the default move is a version of lift and shift; take the biggest, most expensive frontier model, wire it into every use case that looks like it might benefit from an agent, hand out access to every function that asked for it, and declare progress. It felt good to have AI chat bots everywhere, execs claimed “headcount savings into the millions” and even more interesting, made audacious claims that “our customers are happier with all these bots”. The problem is, now the bill is starting to hammer the living daylights out of business. Month over month the bills keep coming, and increasing. In many cases, the AI spend now surpasses the original cost of headcount it replaced. Rightfully so, the CFO is asking pointed questions about which of these use cases are actually earning their keep, and the same executives who championed the move are quietly discovering that the vendor promises about productivity gains are considerably harder to substantiate than expected.

The pile-in was not stupid; if you were the business exec who did it you are probably reading this defensively, and the pile-in was rational. You had to learn, your organization had to experiment, your people had to build intuition about where the technology helps and where it does not, and the only way to do that is by using it, generously, on real work. The mistake was not moving fast; the mistake was moving fast without governance, without cost controls, and without an operating model, and that mistake is the same one the industry made with cloud, and it is fixable in exactly the same way.

If you are battling with AI costs right now, I encourage you to think about these three points:

1. Do you know, per workload, which of your AI use cases are producing measurable business value, and which are burning tokens for no return you can point to?

2. Do you have a governance layer that decides which model is appropriate for which task, so that a customer-support classifier is not being routed through the same frontier model as a complex reasoning workflow?

3. Do you have a mechanism, agreed in advance, for shutting down AI workloads that do not earn their keep, without it becoming a political fight inside the business?

An answer of “I don’t know”, is totally fine, that helps you pinpoint the work to be done; and it is the same work cloud went through 10 years ago.

The playbook is not special, it’s a simple “rinse and repeat”. Right-size the model to the task (a frontier model being asked to summarize a PDF is the AI equivalent of running a t2.micro workload on an m5.24xlarge). Refactor the workflows that are working so they consume less, and decommission the ones that are not working before they build a constituency inside the business who will defend them. Put a governance layer over the top so that model selection, prompt patterns, and cost per workflow are visible to the people who own the P&L, not just to the engineers running the experiments. And accept that the next act of the AI story inside your business is discipline, not volume.

Every enterprise that went through the cloud cycle did the hard work, most of them after a very direct conversation with the CFO about a very specific line item, and the question sitting in front of you now is whether you do it on your terms, before the conversation is forced, or whether you wait until the conversation is forced and you do it under pressure with a smaller mandate. AI is great for business; AI without a plan, without governance, and without cost controls, is a recipe for disaster.

There is a specific kind of pressure sitting on CIOs and CTOs right now, because it is the reason a lot of this work is not happening yet; every board has been told AI is transformative, every peer at every conference is talking about their AI initiative, and turning around and saying “we need to be more disciplined about how we are running this” feels dangerously close to admitting you got the initial call wrong. You did not get it wrong, you did what the market expected, and you learned what you needed to learn. The next call is discipline, and the executives who make it now, on their own initiative, will be the ones who own the AI story inside their business in eighteen months.

Neil

What actually happens in almost every one of these “Kubernetes failed us” stories is not a failure of the technology; it is a failure of scope, or a failure of design, or (often) both. The design failure looks like this: engineers, likely very new to Kubernetes, made ill-informed decisions early on (wrong network stack, wrong storage class for the workloads, incorrectly sized CIDR subnets, undersized nodes, no DR strategy, and no upgrade testing) and before you know it, failures hit. Of course, the failures are because of Kubernetes, right? Wrong. Kubernetes didn’t fail, the design of the platform failed.

More commonly, “adopting Kubernetes” quietly morphs into a full CNCF-inspired transformation program on day one; GitOps goes in immediately, a service mesh gets layered in because someone at KubeCon said you must have mTLS, a full observability pipeline replaces the perfectly adequate monitoring already in place, policy engines get bolted on because they might be needed later, and a developer portal gets scoped because self-service was the goal. Then secrets management, cost management, image scanning, and admission control all arrive together, and all of this classified as “deploying Kubernetes”. This is a complicated stack by any means, and a stack that only a large and mature platform engineering team can support, you know, like the ones that run Kubernetes at a scale where 10,000 PODs is considered small. Projects that bundle in too much change up front fail all the time, regardless of whatever technology sits underneath them. This isn’t the first time around this cycle too… it happened in the early days of Virtualization, and it quickly course corrected. That course correction is starting to happen with Kubernetes now too.

When a project like that falls over, someone has to carry the failure, and in most organizations blaming a specific team’s decisions is politically much harder than blaming “the technology”. So the technology takes the fall, the retrospective gets written up as “Kubernetes is not suitable for our environment”, and the finding becomes organizational canon; two years later, no one can remember exactly what happened, but everyone knows “we tried Kubernetes and it did not work for us”. The company holds itself back from every workload Kubernetes is actually well-suited to, and pays for it in a slower application delivery cycle, worse resource utilization, and a widening capability gap against competitors who ran the same technology but scoped the project sensibly.

If you are in a company that shelved Kubernetes for these reasons, or you are the engineer or leader who lived through the failure, three questions come to mind…

1. Was the original project actually about running your apps on Kubernetes, or did it morph into a program to adopt half the CNCF landscape at the same time?

2. Did you deploy Kubernetes as a small, focused first workload, learn it, and then you added complexity as your skills improved, or did you commit to a full-stack “day one” that had you struggling to learn a dozen tools simultaneously?

3. Are you still avoiding the technology today because it genuinely failed, or because reopening the conversation would mean reopening the question of who owned the original scope decision?

If the honest answer to any of those is uncomfortable, that is the signal that a second look at Kubernetes is warranted (not necessarily a second attempt, but at least a second look, with clearer eyes and a much smaller scope).

None of this is written to make anyone feel bad about a project that did not land the way they hoped. Kubernetes projects fail for the same reason most transformation projects fail; the scope was too wide, the timeline was too optimistic, the tooling was too new, and the team was learning half a dozen things at once. That is a hard thing to admit at the time, and it is a much harder thing to reopen later, especially when the organizational memory has hardened around “the technology did not work”. But holding onto that story costs the company the entire category of workloads Kubernetes actually runs well. It costs years of delivery velocity that could have been captured, and eventually it costs competitive position, because the peer down the road who scoped their project sensibly is now shipping features that cannot be matched.

Neil

If your first Kubernetes attempt failed, and you want to look at it again without repeating the scope trap, this is exactly what my team at Portainer built the product to do. Run Kubernetes as an integrated platform, without the CNCF sprawl, with the day-one complexity kept small enough that the project actually succeeds first and grows into the rest later, only when it needs to. No obligation, all it takes is a call, and we are happy to walk through what a sensibly-scoped first deployment actually looks like.

What now fills a CIO’s day is all things AI. How their organization is approaching its use, how they defend their network against AI-assisted threats, and how they enable the business to rapidly embrace the efficiency gains AI is promising. The infrastructure platform they may have cared about two or three years ago is no longer a topic they spend any thinking time on, because they have naturally assumed that the platform has matured, that it is now capable of hosting mission-critical applications, and that it will be capable of receiving the AI workloads about to arrive (the self-hosted LLMs, the RAG pipelines, the AI-security products, the vibe-coded internal apps, and the developer sandboxes for teams experimenting with model-assisted work).. a lot, yes!. That is an expectation, one their broader AI plans are built on top of, and they have little to no tolerance for the answer “we are still building it”.

Whoever owns the Kubernetes platform is about to get a rather rude wake up call… and like it or not, its coming. You are now the person the AI ambitions of the business are resting upon, and if you are not ready, you will be the scapegoat when things go bad.

I don’t want to hand you a checklist, and say “go check these things”, as thats no fun… instead, let me ask you these questions. Go look in the mirror when you answer them, and see if you can answer them with a straight face. A lie you tell yourself is just making a problem for yourself 😉

1. Can you deploy these AI apps quicker, cheaper, and more secure than if the business were to source them from a SaaS/PaaS provider?

2. When running these mission critical apps, can the platform underneath be kept current, patched, and secure (against the rapidly accelerating onslaught of AI-assisted CVEs), at the same time as delivering the high SLA the business is now expecting?

3. With the demand for Kubernetes skilled engineers at an all time high (and salaries matching demand - see this one), if your team churned tomorrow, can you keep running the platform without interruption?

If the honest answer to any of the three is “I don’t know” or worse “no”, that is the signal to dive deeper, quickly.

Most Kubernetes platforms have grown organically. The CNCF ecosystem cannot be described as “static” and the speed of innovation is crazy. The number of tools most companies run vs what they were running 3 years ago is likely 3-4x, and when you compound in the fact that the number of clusters deployed has also likely increased 3-4x, thats a pretty decent change. If you are not familiar with the boiling frog metaphore, give it a read, and then replace frog with “Kubernetes” and “boiling” with “growing” and you have a pretty spot-on representation for most Kubernetes platforms today.

It’s always good to revisit platform decisions after a certain amount of time (or growth)… like an oil change “7000 miles, or 1 year, whichever comes first”… and ask yourself “..If i was rebuilding this today, would I make the same decisions?”.

There is a certain degree of engineering pride that comes with hand-assembling a bespoke platform, but sometimes the smarter move is simplicity over complexity. Once the SLA expectations climb, most people would prefer an easier platform with fewer moving parts. When you merge that with now having to upgrade/patch applications at a never-before-seen pace (thanks AI-powered hackers!), you really do want to second guess every single tool/component in your stack.

And yes, with venture capital now funding AI companies at valuations last seen in the dotcom boom, these same companies are able to pay $400k + for Kubernetes engineers, can you keep yours? How much institutional knowledge is tied up in your people? How “standard” is your platform, and should you lose your experts, can whomever is left support the platform?? Don’t discount the staff churn potential, everyone, and I mean everyone, loses their loyalty when faced with large $$ being waved in front of them.

None of this is designed to scare you, it’s designed to make you think. To consider the possibility, and to preempt the likely. After all, it’s your responsibility to ensure the platform is operational, supportable, and secure, regardless of the hurdles you come across. There are so many ways to achieve an outcome, don’t assume that the way you chose 3 years ago is the right way today. Oh and never forget the number 1 rule in life “feed your family, not your ego”, when answering the questions posed in this blog.

Anyway, every single CIO will be rejoicing at the very thought of AI solving world peace, hunger, and business efficiency, and will be more than happy to tell their CEO “we have this under control, I have tasked my engineering team to deploy this plethora of AI tooling, and it will be available this week”.. and yes, “this week” is likely, as no CIO wants to be seen to be snoozing on the AI boom.

If you want help to look under the covers, and dig deep into your platform composition, my team at Portainer are happy to help, no obligation, all that’s needed is a call.

The only real defense of this is to a) either continuously run scans yourself, and fix any/all issues you find, or b) accept the CVE’s and patch them as they come in (which btw, is thick and fast). Either way, its now a massive burden to manage, and it also means you need to ship software updates significantly more frequently than you ever have before. What’s worse, is that some of the vulnerabilities the LLM uncovers may actually be detrimental to your core functionality, and so what do you do then? deprecate the feature? re-engineer it? ignore the CVE? Tricky tricky.

Docker-CE, the open source container runtime that popularized containerization sits somewhat in a half-way house now. Its not used by any commercial entity, and is supported almost exclusively by Docker and Mirantis. Neither of them actually use it natively themselves (instead they use the upstream project and their own closed source variant). Unlike Kubernetes, with tens of thousands of contributors, Docker has almost no one. Worse, the ecosystem has pretty much abandoned it, with all 3rd party software vendors exclusively supporting Kubernetes as a platform and API. And thats all cool, the money follows demand, but there are still countless hundreds of thousands of environments running Docker today. All of them are reliant on Docker-CE being supported, safe, secure, and receiving frequent patches. As of today, Docker IS still getting patched, sure, but for how much longer will those patches NOT introduce breaking changes, and for how long can they keep up with the massive influx of AI-generated bug / security reports?

If I had to place a bet, my bet would fall on Docker throwing up their hands, and the CE product itself stopping being a compiled release, and instead simply being source code that you need to take responsibility for (and secure). There is no intrinsic commercial benefit for Docker to continue to support this product that is not tied in any way to their revenue.

What does that mean for you, as a Docker user?

Well, if you run Docker in your environment (managed by Portainer, or not), you need to seriously accelerate your migration to Kubernetes. Doing nothing and deferring the problem is not a solution you should consider. The overwhelming number of contributors to Kubernetes means it will remain one of the fastest iterating pieces of infrastructure software of our time. If you want a secure environment, then this is your only option. There are even distros like Portainer’s kubesolo.io that give you the benefit of Kubernetes in the resource footprint of Docker, so there really is no excuse.

Now I understand that from an operational complexity standpoint Kubernetes > Docker, and i get it.. its true... However, there are ways and means to minimize this. For one, the “all-in-one” single binary distro’s like k3s or kubesolo, make the installation and maintenance a breeze. But secondly, when you couple Kubernetes with a product like d2k (github.com/portainer/d2k) from Portainer, it even lets you manage Kubernetes using Docker native tooling... and using the Docker CLI (but without inheriting any of the security risk)... Kinda best of both worlds. Of course, eventually you will become conversant with Kubernetes, and tools like d2k phase out, and thats OK.. that is the intended outcome.

So, if you run Docker today, please reconsider your “do nothing” approach, and start to build out a plan to move to Kubernetes... but don’t “boil the ocean” and attempt a massive infrastructure transformation, as that just elongates the project with “wants” vs “needs”... what you need is to get onto a stable and secure base platform, and for that its a far simpler project.

Neil

It’s actually not that easy to get a “wide-berth” view of user perspectives, as users normally congregate into sub-groups based on their use case. The more vocal of all groups are the home self-hosters, so its that group I normally get the most exposure to. From that group, one common theme keeps coming back.. it’s that Portainer is “bloated”.. it’s “overkill”.. it’s way too much software for a box running a handful of containers

And you know what? For a lot of the people saying it, they’re right. Just not for the reason they think.

Everyone lumps “home use” together, as if running containers at home is one thing. It isn’t. There are two completely different people in that world, and Portainer was only ever built for one of them.

One is the homelabber. A technologist (just like myself, and most of the Portainer engineering team), running hardware and software at home to learn.. to build the skills they’ll use at work. For that person the whole point is that the tool looks and behaves like the real thing they’ll meet in production.. Centralized User Authentication, RBAC, GitOps, fleet operations, policy enforcement, all of it. That’s not bloat to them. That’s the reason they installed it.

The other is the home server crowd. Home Assistant, Pi-hole, the *arr stack, a bit of streaming. They don’t want to learn an enterprise platform. They want their stuff to just work, with the least friction possible.

And for that person? Portainer is overkill. Genuinely. All that depth has nothing to do on a single host with three containers.. so it just sits there feeling heavy.

So here’s what I tell them, and I mean it.. go use something lighter. Dockge, Dockpeek, Arcane.. they’re built for exactly this, they’ll feel lighter because they are lighter, and they’ll do everything a single-host home server actually needs (but also, nothing an enterprise needs!).

Saying that costs us nothing. The container problem a media server has, and the container problem a 200-node enterprise fleet has, are not the same problem.. and no single tool nails both without wrecking one of them.

Which is also why we say no to a certain type of feature requests.. the ones (usually on GitHub) asking us to strip Portainer down into that simple single-host tool. Every one of them asks us to optimize for the person we didn’t build for, at the expense of the person we did. Push that far enough and you break the product for the enterprises running real fleets on it.. the ones who need those guardrails because on a fleet one mistake propagates across the whole estate.

So no.. Portainer isn’t for everyone at home. It was never meant to be.

If you’re a homelabber who wants to learn on the real thing, CE is free and BE is free for three nodes.. go nuts.

And if you just want your Plex and your Pi-hole to behave, grab one of the lighter dashboards, with my blessing… it will likely save you from a headache, as K.I.S.S applies everywhere.

Good question.

I was stalking in the CIO and CISO subreddits, and seeing this same question asked over and over, and the most common answer was “you cannot, so just ban their use”.. the second most common answer was “they are terrible quality apps, so just force the business to use your development team to build proper apps”.. and I thought these were really interesting answers.

Why?

Well, blocking/banning something never works.. it never has, and it never will. People are people, and when we want something, we find a way, and will work around whatever hurdles are put in our way. Also, banning the use of vibe coded apps is the fastest way to employee frustration. If there are employees in your enterprise that are frustrated enough by a common daily problem they face, that they will willingly go out and try to build a fix for that, you should be delighted, and actively encourage that. And if you don’t, their frustration will likely result in them fixing problems for another enterprise.

Second, forcing every business problem via a development team is something we have been doing forever, and you know what that results in? “Please write a business case for this, so we can justify the investment in people to go build the app”.. problem is this is the classic “chicken or the egg” game.. how can the business person justify the investment if they dont know whats required to solve the problem? They cannot, so they dont even bother. Isnt it better to let them solve the problem themselves, understand the gains that the solved problem has realized, and then write a business case explaining what they created, the benefits to the business, and why they would now like it handed over to engineering? That is exactly what Vibe-Coded apps allows the business to do...

So what is the right* answer ?

It seems obvious really, and brings back full circle to the question being asked. Give the business users a secure, governed way to deploy (internally) the apps they vibe code, on a platform IT controls and can observe. Now let me be crystal clear here, as the word “controls” does not mean gated; it means IT gives the users a place that the vibe-coded app can run, where you can see it, scope what it is allowed to reach, and who can reach it. It gives you the ability to scan the app (and its code) for vulnerabilities, to inspect its network traffic (to make sure no nefarious activities are occurring), but generally, do all of this in the background, without getting in the way of the business user. ie deliver this in a 100% self-service platform for your business users.

Also, its worth being pretty upfront that there is no expectation that vibe-coded apps are “forever” apps. These really should be treated as POC’s, and that after a period of time, they are either proven awesome (and therefore can justify being productionized), or rubbish (and therefore deleted). I dont think anyone, anywhere believes that vibe-coded apps are full production ready.

Should you block vibe-coded apps, or not? I argue no, and assuming you go with my argument, you then need a way to allow business users to self-serve the deployment of their vibe-coded apps, and that really really should be on a system you own and govern.

Now the sales pitch :) This is why I created Portainer-Run (portainer.ai)... so if you are one of the CIO’s faced with this exact question, give Portainer.ai a read, you may be surprised what you can do.

An actual quote from a hardware reseller we work with included the following clause.. “Quotes have gone from lasting a month, to only being good for a day. The price you see attached may change, due to competing with what datacenters are willing to pay. For example, the servers we purchased last year for $9000 are now $45000.” and this is the sad reality we are currently operating in.

For anyone self-hosting, this ends the era where the answer to any capacity problem was to buy more iron. Lead times of six months and near double pricing mean RAM and NVMe are now genuinely scarce budgeted resources, and efficiency has a real dollar value attached to it for the first time in years. That changes the calculus in two directions that our industry has spent a long time avoiding.

The first is requests and limits. Almost everyone running Kubernetes finds them tedious, and most estates run with them unset or wildly over-provisioned because compute used to be cheap enough that nobody paid the price of the waste. That waste is now expensive. Setting sensible requests and limits, and actually right-sizing workloads against real consumption, reclaims capacity you have already paid a premium to own. The tooling to do this well has existed for years. What was missing was a commercial reason to bother, and the hardware market has just supplied one.

The second is the "weight" of the Kubernetes distribution and the tooling stack sitting on top of your nodes. A large share of every cluster is spent not on running applications but on running the platform itself, the bloated Kubernetes distribution (RH, I'm looking at you!!), the observability sprawl, the half-used operators, the in-cluster tooling that seemed free when RAM was cheap. It is not free any more. Stripping the estate back to a lean Kubernetes distribution and a very lightweight management tooling framework that frees scarce CPU, RAM and storage to do the one thing you bought the hardware for, which is running your apps.

The teams that come through this well will be the ones that treat their existing fleet as something to run tightly rather than something to keep expanding. Scarcity has a way of making good engineering discipline look like strategy.