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.

The answer may be NO, and it’s likely you have no idea this is the case (until it happens). A running container has no live relationship with the registry it came from, because the layers are already unpacked on the node and the kubelet never rechecks anything for a container it isn’t being asked to create. Delete the image upstream and nothing about that pod changes. It carries on serving traffic on layers it fetched once, months ago, that nobody has verified since.

An imagePullPolicy of IfNotPresent hides this further, since it resolves against the node’s local store and never troubles a registry at all. That holds until the pod lands on a node which has never seen the image, and that happens on every node image upgrade, every autoscaler event and every spot reclamation. Staying put helps less than you’d think, because kubelet garbage collection clears images once the filesystem gets tight and the ones you haven’t touched in a while go first.

Bitnami is the live example everyone is currently dealing with. A chunk of the free catalog went to a legacy archive, the images came off the AWS public gallery in June, and clusters that had inherited Redis, Postgres and a pile of exporters from Helm chart defaults started failing one node replacement at a time. Any registry that goes away does exactly the same damage. You get an identical outage from a retention policy that reaps anything untouched for 90 days, a cleanup script that decides untagged manifests are garbage, or an expired card on a cloud account nobody remembers owning.

The registry you run yourself is worse, because it holds the only copy. Everything currently running stays up, so the first hour feels survivable, and then somebody opens the recovery runbook and finds that step one is to pull an image from the registry that is down. Registries also habitually run on the very cluster they serve. Go and read your restore procedure, then check whether it depends on the thing you would be restoring.

The reference that catches you is never your own application image. It is the init container, the metrics exporter, the sidecar added during an incident three years ago, or the default value in a Helm chart nobody has opened since installing it.

The strongest operational recommendation I can possibly make is simple... trigger a regular redeploy of your running applications, schedule a regular cluster power-cycle, and confirm everything comes back... dont assume, EVER. Do this before its too late, and you get your own Bitnami issue.

For those of you now facing the issue of apps failing to start due to the reliance on the now non-existent Bitnami images, good luck, and I hope you have copies of the images.

Well, recently one of my staff here at Portainer asked me if I would help them to understand Kubernetes a little better, as they were feeling overwhelmed with the deep-dive tech training content that everyone gets pointed to, and I was happy to oblige.

Anyway, what resulted has now become KubeSchool, and I decided to make it public. You can read the lessons on https://kubeschool.portainer.io

Note, this is NOT designed to be a deep dive, full technical breadth training, for that we already have the CNCF courses. This is designed to get someone new to Kubernetes up to speed, so they can partake in team discussions, and follow technical conversations.

If you are new to this space, its well worth the time investment to give it a read.

Neil

What is actually happening

Gartner’s April 2026 Market Guide for Enterprise Vibe Coding Platforms puts scale on what is already in motion: by 2029, vibe coding platforms will assist in creating 40% of internal tools at large enterprises, up from under 10% in 2025, and by 2027, at least 30% of application security exposures will result from vibe coding practices. Those two statistics describe the same phenomenon from opposite sides... a massive volume of AI-generated internal software is coming, and a significant share of it will introduce exploitable defects. The tools for building fast are already widely deployed. The infrastructure for landing those builds safely inside a regulated organization is not.

We have been watching this from an unusual vantage point. Portainer Business is deployed across Fortune 2000 enterprises, government agencies, and critical infrastructure operations globally. When their business teams started arriving with AI-generated applications and asking IT to host them, every available answer failed for the same reason: without substantial software rewrites, none of them respected the governance architecture the organization had already built.

Why the existing answers don’t work

Cloud platforms like Northflank or Render require data to leave the corporate network onto infrastructure the enterprise doesn’t control, and for any regulated industry that conversation ends before the security review opens. Vendor-hosted runtimes (Salesforce Agentforce Vibes, AWS App Studio, or Northflank Enterprise) generate and run applications inside their own ecosystem, trading shadow IT risk for proprietary lock-in and runtime that sits on the vendor’s infrastructure rather than the organization’s own governed clusters. Low-code builders like Retool solve a different problem entirely; they aren’t a deployment layer for AI-generated source files. And the platform engineering ticket remains the most honest answer to the deployment question, which is also the one that creates the bottleneck everyone is trying to route around.

Gartner’s guidance on this is direct: enterprises should favor platforms that execute generated applications in isolated or containerized runtime environments to limit blast radius when generated code contains exploitable defects. That’s an argument for running AI-built apps on Kubernetes, the infrastructure most large enterprises already operate... not for yet another cloud hosting vendor. The recommendation points at an architecture that already exists inside most large organizations. What has been missing is the layer that lets non-technical builders reach it without dismantling the governance model in the process.

What we built

Portainer-Run started as a skunkworks project, built to validate whether the governance gap was real before we committed to a full product build. What we found accelerated graduation considerably: the enterprises running Portainer Business were already fielding this exact request from their business teams, the available options were failing for the structural reasons described above, and the architecture to solve it was sitting inside our own platform. What followed was a faster-than-planned path from internal experiment to generally available product.

Portainer-Run is a governed self-service deployment layer between business builders and the enterprise Kubernetes infrastructure they should already be deploying onto. The core deployment path (Vibe Deploy) is designed specifically for the artifact AI tools produce: source files, not containers, not Dockerfiles, not Kubernetes manifests. A business builder takes the output from Claude, Cursor, or any other tool, uploads it to Portainer-Run, and gets a production deployment on the organization’s own Kubernetes. Run detects the runtime from the uploaded files (Node.js, Python, PHP, Ruby, or static), generates a standard Kubernetes deployment manifest, commits everything to a sanctioned Git repository the organization controls, and reconciles running state through Portainer Business. The platform team does not need to be in the loop for every deployment.

Two architecture decisions define what the governance model actually looks like. The first is the credential model: builders authenticate using a personal access token scoped to their identity in Portainer Business, and the environments and namespaces they can reach reflect exactly the RBAC their account holds. Cluster API credentials never leave the server, and a business builder deploying an AI-generated application never receives or handles Kubernetes credentials at any point in the process. Direct cluster access handed to non-operators is unauditable, unrecoverable if misused, and invisible to the CISO. The second is Git as source of truth: every deployment commits source files and the generated manifest to a sanctioned repository before anything runs in the cluster. Portainer Business polls that repository and reconciles running state against it, giving the organization a complete auditable record of everything deployed, when, and by whom.

What Portainer Business provides

Portainer-Run is the self-service surface. Portainer Business is the control plane underneath, and that distinction matters for the CISO conversation. Portainer Business brings RBAC scoped to environment and namespace, GitOps reconciliation, full activity audit logging, and fleet-wide visibility across every cluster the organization operates. When a business builder deploys through Portainer-Run, that deployment lands in Portainer Business attributed to the deploying identity, governed by the RBAC policy the platform team set, and reconciled through the same GitOps model the organization applies to its production workloads. The governance model is inherited from a control plane that regulated organizations have been operating for years, not retrofitted onto a hosting service. For existing Portainer Business customers, Portainer-Run is included at no additional cost. For organizations not yet running Portainer Business, it’s available through a Portainer Business license purchase.

Where Portainer-Run fits in the market

Gartner’s Market Guide covers platforms that generate apps from natural language (Lovable, Bolt.new, v0, AWS App Studio). Portainer-Run doesn’t generate apps, and it isn’t competing with those platforms... it’s the governed deployment target they’re missing. The category we occupy is the governed landing pad for AI-built apps on enterprise Kubernetes. The market has ways to build with AI and ways to host on someone else’s cloud. What it doesn’t have is a clear answer for how a large, regulated organization lands those apps on its own infrastructure under its own governance, without a platform engineering engagement every time.

Shadow IT from AI coding tools isn’t a future threat model; it’s a description of what’s happening in most large organizations right now. The organizations that establish deployment governance before the volume arrives avoid the remediation cost that comes when it arrives unmanaged. Full product details, documentation, and getting started guides are at portainer.ai, and if you want to talk through how it maps to your current environment our team is available for a briefing.

A lot of people are mocking it as inferior software development… and they’re missing the point entirely.

It was never about the quality of the code. It’s about the value it delivers.

Think about what happens when an enterprise gives a thousand general staff the ability to vibe code an app. Each person, who deeply understands a specific business problem, explains that pain directly to an AI, gets it coded, and iterates in real time. No product manager translating it into a user story, no dev team picking it up six sprints later, no QA bottleneck. Direct from the person experiencing the pain, to a working solution.

That is crowd-sourcing development from the people who understand the business problems the most… and that’s something we’ve never really been able to do before.

Traditional development runs one (maybe several at best!) pipeline. Problems queue behind each other, waiting their turn through a PM, a sprint, a QA cycle, a deployment gate. Solving a thousand problems that way doesn’t take four months… it takes four months, a thousand times over. Vibe coding flips that entirely. A thousand staff each running their own pipeline, simultaneously, each one solving the problem they understand better than anyone else in the company.

The enterprises that not only embrace vibe coding but actively encourage and support it, those are the ones that win. But there’s one thing that can stop this cold. To unlock this value, you need to give those business folk a way to get their app into production without friction. A traditional IDP won’t cut it, and neither will a support ticket to a DevOps engineer who needs to inspect the code and wire it into a CI/CD pipeline. You need something closer to a Heroku experience, running inside your own infrastructure. Exported code, straight to prod, no middlemen, no platform awareness required. Without that last piece, you’ve handed the enterprise a superpower and then quietly disabled it.

This is exactly why Portainer-Run was created.. with the employee vibe-coding apps as a first class citizen..

Github.com/portainer/portainer-run

So they hired specialists, expensive engineers brought in to make the architecture decision that leadership was not confident making itself. Experts arrive with their own incentives, and of course, a team hired to build a platform needs the platform to be worth building, so they make that case convincingly. The recommendation is almost always a bespoke, cloud-native-pure stack built from first principles, because that is the kind of work that justifies the kind of team that just got hired. Leadership was already inclined toward caution, and all of this reads as validation. Alongside the incentive runs a harder constraint: experts can only engineer from what they have already seen. A large-scale distributed Kubernetes rollout surfaces requirements, edge cases, and failure modes that no prior project fully prepares you for, and if you do not know what you do not know you cannot design for it in advance. The bespoke platform takes the shape of the architects’ prior experience, not the specific and future operational reality of the organization they just joined. Nobody in the hiring process asked how long their last platform took to build, what it cost when fully staffed, or how many people it currently takes to keep running. Those are the numbers that would have predicted the outcome, and they never appear on a CV.

What resulted was four engineers spending half a year, building just one production cluster, and migrating just a single application. Worse, every hard problem; fleet management, cluster upgrades, network policies, certificate management, identity, access control, still untouched. The platform they built by hand is less capable than what a modern operator control plane provides on day one.

They call it progress, and the steering committee gets a status update confirming the project is tracking and learning’s are being captured, but progress is often not progress at all. The cost to get to this six month milestone is net-new: leadership hired this team from outside, with full recruitment, salary, and ramp; several hundred thousand dollars to land a single app on a single cluster. Those same people, handed a working control plane on day one, would have spent those six months migrating applications rather than building foundations that carry no business value of their own.

The working control plane already exists, and it does not require outside specialists or building from scratch to adopt. The team already there, the people who have kept their estate stable for years, already have the instincts the job needs: change control, operational risk, recovery. We meet your people where they are, give them a working foundation on day one, and let the next six months go into migrating applications rather than laying plumbing.

The decision to slow down was made out of fear and validated by experts whose interests lay in building. What it has produced is a half-built platform, a hired team with every incentive to keep building, and a business still waiting for the modernization it funded.

The best AI-assisted coding tools already understand this, which is why they push hosting onto their own SaaS or PaaS. It’s the only way to keep the experience seamless end to end. And it works, right up until the app needs to talk to something inside your network. An internal database. An on-prem API. A system that lives behind the firewall and isn’t going anywhere. At that point the platform collapses, and the only path forward is a ticket to the platform team.

That platform team is already barely coping with day to day. We’ve had this conversation directly with large enterprise customers: the influx of AI-generated deployment requests, coming from people who have never touched infrastructure in their lives, is a real and growing problem with no clean answer. Buying an IDP that takes a year to configure before anyone can use it is not the answer. We know, because we’ve watched enterprises try that, and a year later the license is ticking and nothing is in production.

That’s the gap we built Portainer Run for.

Portainer Run is a self-service container operations portal that sits on top of your existing Portainer deployment. You deploy it as a single container, point it at your Portainer instance, and your developers and app owners have a simplified operational interface governed entirely by Portainer’s existing RBAC and policy controls. The platform team’s role shifts from processing every deployment ticket to setting the rules once.

The interface is deliberately narrow in scope. It doesn’t replace Portainer. It surfaces one workflow (deploy, run, and operate a containerized workload) in the simplest interface we could build for it, for people who have no idea what a Pod is and shouldn’t need to.

The dashboard gives you a live health summary across all connected environments at a glance: total services, running, degraded, and unavailable, broken down per environment. On reconnect, the last known state is shown immediately while live data loads in the background, so the first thing you see is never a loading spinner.

The services view is the primary operational HUD. Every running (scoped to the user) workload is listed with a traffic-light status indicator: green for running, pulsing amber for starting up or partially available, pulsing red for not running. Status reasons come from pod state and are surfaced in plain English below the indicator: “App keeps crashing (4 restarts)”, “Can’t download the image”, “No node has enough resources.” No kubectl required, no digging through events. The right information, in the right language, for the person who just wants to know if their app is working.

Clicking into a service opens a six-tab detail panel covering overview, containers, metrics (CPU and memory sparklines via metrics-server), logs, revision history, and a live edit view. The edit tab patches instance count, container images, environment variables, and exposed ports in a single save operation.

Deploy is a Cloud Run-style form that covers single and multi-container workloads, persistent storage, environment variables, Kubernetes Secrets references, resource limits including GPU, and service exposure. No YAML, no kubectl. The same open standard underpinning Google Cloud Run, surfaced as a form a business developer can actually use. GPU support auto-detects the resource type available on the target environment’s nodes (NVIDIA, AMD, Intel, Habana) and sets the correct resource key automatically, which matters as GPU workloads stop being exclusively the province of ML engineers.

The Catalogue is a curated library of pre-configured application stacks. A two-step wizard selects the target environment and namespace, shows a confirmation summary, and fires the full deployment sequence in two clicks. Templates are fetched from a configurable URL (default uses one Portainer hosts, but you can use one you create and host) and cached server-side, the format is Knative Service manifest, and nothing is locked to a proprietary schema. The citizen developer who just wants to get something running finds what they need here.

Secrets gives namespace-scoped access to Kubernetes Secrets without exposing the underlying cluster. Create with multiple key/value pairs (values are write-only and never displayed after saving), delete with confirmation, and see which apps reference each secret at a glance. Secrets created outside Portainer Run are fully referenceable, because that’s a normal operational requirement.

The Assistant is where the AI actually earns its place in this interface. It’s a persistent chat panel available on every page, context-aware of whatever you’re looking at (current page, open service, environment). When a business developer asks “why isn’t my app connecting to the database,” the Assistant proactively fetches logs, pod conditions, and Kubernetes events before generating a response. It doesn’t ask you to check them yourself. It covers failure modes where no logs exist yet (scheduling failures, image pull errors, resource constraints) because it reads from events rather than relying on application output. It can translate a Docker Compose file into a Portainer Run deployment, describe a workload in natural language to pre-populate the deploy form, and detect scale requests to open the Edit tab pre-filled. It never executes irreversible operations directly... those route to the existing UI.

The Assistant supports both Anthropic and OpenAI, server-side. The API key never reaches the browser, and the operator decides which provider is in use.

Cluster Readiness (admin only) checks each connected environment for ingress controller availability, LoadBalancer provisioning, storage class configuration, node health, and GPU node availability, and reports each result in plain English. Admins can disable environments from this view; disabled environments are hidden from all dropdowns and views for non-admin users and blocked from receiving new deployments for everyone. That’s the platform team’s control surface: decide which clusters are ready, and the guardrails apply everywhere automatically.

Portainer Run is not trying to serve the engineer who has full cluster access, a powerful AI agent, and deep API reach. The right answer for that persona is a Portainer MCP server, something that gives an agent access to the full Portainer API surface to do powerful, context-rich work within policy-controlled boundaries. That’s a product we’re building, and it’s a separate track. Dropping an agent with full cluster mutation rights into the hands of someone who vibe-coded their first app last Tuesday is a different problem with a different risk profile.

Portainer Run and a Portainer MCP server aren’t in conflict. They serve different points on the same spectrum. Citizen developer who needs a safe, simple path to get their AI-built app running inside the corporate environment, without overwhelming the platform team... that’s Portainer Run. Power user or agent that needs full API access, full context, and policy-controlled freedom to do complex infrastructure work... that’s the MCP server.

Portainer’s value in both cases is the same: we are the secure, policy-enforced gateway between the people and agents doing work and the infrastructure they’re working on. The interface on top of that gateway looks different depending on who’s using it. That’s the point.

Portainer Run is available now in the Skunkworks section of the Portainer website. Deploy instructions and the full template catalogue format are in the README on GitHub (github.com/portainer/portainer-run)

The tools deliver on the pitch. A business analyst, a product manager, an operations lead with no engineering background... anyone can prompt their way to a “working” application in an afternoon. Internal tool, customer portal, data dashboard, automation workflow. It works, it looks good, it solves the immediate problem, and then it gets deployed, shared, and quietly becomes part of how the business operates. And then another one gets built. And another. By different teams, for overlapping purposes, with zero visibility across the organization.

An AWS manager recently documented exactly this, building a tool to detect AI-created applications inside a single AWS business unit. He found hundreds. Teams didn’t know about each other’s apps. Multiple tools were doing the same thing for different groups. None of them were being maintained. All of them were sitting there, quietly accumulating risk.

That’s the reality of vibe-coded enterprise software at scale, and it’s not an edge case anymore. Vibe-coding massively scales the long-standing problem of shadow IT, empowering non-technical developers to rapidly create and deploy applications completely outside the purview of IT and security teams, creating a vast, unmanaged, and invisible attack surface running live in the enterprise. Security teams are being asked to defend a growing portfolio of production applications they don’t know exist, built by people who don’t understand what’s running under the hood, using AI models that introduce security flaws into nearly half of all generated code despite appearing production-ready, with no significant improvement across newer or larger models. And lets not even talk about OSS license exposure, using seemingly “free” libraries that may come with strict conditions.

Now add MCP servers to that picture. Employees are deploying Model Context Protocol servers on their laptops, connecting them (using their personal credentials) to sensitive internal systems, and plugging those connections into SaaS-based vibe-coding platforms running in someone else’s cloud. The data flowing through that chain is crossing trust boundaries that nobody mapped, nobody approved, and nobody is monitoring. In February 2026, Wiz researchers discovered a breach in which a vibe-coded platform exposed 1.5 million API keys and 35,000 user emails because it was built without basic security protocols, allowing anyone to hijack AI agents and access sensitive third-party services. That was a public platform. The same architecture is being replicated inside enterprises every day, pointed at systems of record, sometimes exposed on the open internet, with access levels that were granted casually and have never been reviewed.

Research across Fortune 50 enterprises found that AI-assisted developers produce commits at three to four times the rate of their peers but introduce security findings at ten times the rate, creating a security debt that accumulates faster than organizations can remediate it. The person who prompted the app into existence is not thinking about any of this. They solved their problem on a Thursday afternoon. The security debt, the maintenance obligation, the compliance exposure, and the unpatched dependencies are yours... indefinitely, for the life of every application that got deployed and then quietly forgotten.

If the creator leaves the company, there is no clear process for handing over responsibility. Without established ownership, zombie apps pile up through natural employee churn. Enterprises already struggle to maintain software built by dedicated teams with full institutional context. The vibe-coded app has none of that... no documentation, no security review, no understanding of what’s actually running, and an owner who never thought of themselves as owning anything in the first place.

Every application, regardless of how it was built, accumulates obligations from the moment it goes live. Security vulnerabilities need patching, dependencies go out of date, authentication mechanisms need reviewing, compliance requirements evolve, and integrations break when upstream APIs change. None of this cares whether the author wrote the code or prompted it into existence over a long weekend. Prompting an application into existence is the start of an obligation, not the end of one. Treating it as a finished deliverable is how enterprises end up with a sprawling inventory of unowned, unpatched, undocumented software that nobody remembers creating and nobody wants to touch.

So what’s the answer? Banning vibe-coding doesn’t work... shadow IT has never responded to blanket prohibition, and a tool this useful and this accessible isn’t going away. The answer is governance, but not the kind that creates a six-week IT approval process that everyone routes around. The kind that makes the responsible path also the easy path.

The starting point is visibility. You cannot govern what you cannot see, and right now most enterprises have no inventory of what’s actually running. The AWS story is the proof point... hundreds of apps, one business unit, nobody knew. Before any policy conversation, that gap needs closing.

The second piece is ownership as a condition of deployment, not an afterthought. If you built it and you want it running inside the enterprise, you register it, you classify the data it touches, and you put your name against it as the ongoing responsible party. Not a bureaucratic exercise... a thirty-second declaration that creates accountability where none currently exists.

The third piece is where most enterprises hit the wall. The vibe-coder solved their problem in an afternoon using a SaaS platform because the alternative... self-hosting, containers, Kubernetes, infrastructure... is way beyond what they signed up for. So the app ends up on someone’s cloud subscription, outside the perimeter, because that was the only path that didn’t require an engineering degree. Closing that gap means giving non-technical builders a deployment target that is genuinely simple, self-hosted, and enterprise-grade... without expecting them to understand what’s running underneath it.

Here at Portainer, we specialize in making hard things easier… that our core thesis with Portainer as a management layer for Docker and Kubernetes… but even Portainer is too complex for the vibe-coded developer that prefers SaaS/Pass. This is why we created Portainer-Run (github.com/portainer/portainer-run). A Google Cloud Run-style deployment experience, backed by the Portainer API, self-hosted inside your own infrastructure. The vibe-coder gets a simple interface to deploy their AI built, containerized app. IT gets visibility, access control, and a managed environment they actually govern. The app stays inside the perimeter. Nobody needs to learn Kubernetes. And critically, the alternative to SaaS doesn’t require a six-month infrastructure project to stand up.

The vibe-coding wave is not going to slow down. The question for every enterprise is whether the apps your teams are building land somewhere you control, or somewhere you don’t. Right now, for most organizations, the answer is the latter... and the clock on that is already running.

This is not a complaint about the tools. AI is genuinely useful for research, for stress-testing ideas, for turning a rough brief into a structured draft. The problem is specifically what happens after the draft exists. Someone prompts an AI for twenty minutes and produces a fifteen-page strategy paper. They share it “for review and comment.” The twenty minutes they spent has just become four hours of reading time distributed across every person they CC’d. The work didn’t disappear... it transferred, invisibly, from the author to the audience.

This is not an isolated observation. The media is full of it right now. A New Zealand tenant recently used AI to build a $40,000 tenancy tribunal claim that ran to 215 pages, two hearings, and months of process... the tribunal awarded her $80. HBR and Stanford researchers have named the broader workplace pattern “workslop,” estimating the cost to large organizations at over $9 million a year in lost productivity, with 53% of recipients reporting annoyance and roughly half viewing the sender as less capable and reliable as a result. UC Berkeley found that AI doesn’t reduce work at all... it intensifies it, with employees working faster, across a broader scope, for longer hours, without anyone asking them to.

The to-do list problem is a specific version of the same thing. AI makes it trivially easy to generate exhaustive task lists... forty, sixty, a hundred items, fully detailed, logically structured, professionally formatted. Handing that list to a team feels like serious planning, except the hard work in planning is not listing tasks. It’s working out what a real team with a real workload can actually deliver, making the trade-offs, and standing behind the prioritization. AI can produce the list in thirty seconds. It cannot do that thinking. And when leaders skip that thinking, they’ve handed their teams an execution problem disguised as a plan.

The technical paper problem is worse. Non-technical people can now generate extensive whitepapers, architecture documents, and technical reference material in minutes, and then hand them to engineering with “I created this, please review and correct as needed.” That framing makes it sound like a small ask. It isn’t. Every single technical claim in an AI-generated document has to be validated by someone with the actual expertise to know whether it’s accurate, because AI hallucinations in technical content are still common even with the best models available. The author’s credibility cost is zero... the validation cost falls entirely on the people who know enough to catch the errors. That’s not a productivity gain for the organization. It’s a productivity transfer with a smile on it.

Brevity used to be a signal. A tightly written email, a one-page proposal, a three-sentence ask... these communicated something beyond the content itself. They told you the author had done the work to understand what actually mattered. Distillation was a skill, and it was respected because it was hard. AI has automated the appearance of that skill without delivering the substance of it, and the result is organizations drowning in content that looks comprehensive but carries no real intellectual accountability.

If you produce a document, you own it. Not just the output, but the research behind it, the reasoning, the trade-offs, the implications. When your team asks questions, you need to be able to answer them live. If you can’t, the document should not have been sent. Five hundred words is enough for almost any internal proposal. If you need more than that to make your case, the case probably isn’t ready yet... and no amount of AI-generated padding will change that.

The same dynamic plays out in engineering teams, where non-technical staff are now prompting their way to working applications and handing them to engineering as finished deliverables. The app works on Tuesday afternoon. The security vulnerabilities, dependency updates, and maintenance obligations that come with it last for the life of the business... but that's another discussion, and one I'll cover separately.

#rantover

Not because the product failed. Not because the relationship broke down. Because the organizational decisions they were making meant Portainer could no longer do (beyond maybe the first year) what it is designed to do for them.

This post is about that pattern, and why we think being direct about it matters.

What Portainer is actually for

Portainer is not primarily a feature story. Customers do not buy it because it has a specific capability that nothing else has. They buy it because it makes getting up and running with container and Kubernetes operations genuinely straightforward, because ongoing operations stay manageable without constant specialist intervention, and because the organization does not need to hire and retain a highly experienced platform engineering team just to keep the lights on.

That value proposition only works in one direction. It works when an organization has decided, consciously or by default, that it does not want to build and carry that complexity internally. The moment that decision reverses, the value proposition reverses with it.

A technical evaluation in that context is a waste of everyone’s time. You are not evaluating whether Portainer can do what you need. You are evaluating it against a set of organizational assumptions that no longer apply.

The hiring signal

We have learned to watch for one signal in particular: the specialist hire.

An organization comes to us, the conversations go well, there is genuine alignment on the problem and the approach. Then they hire one or two Kubernetes specialists, and the entire frame shifts. The new team members, understandably, want to build. That is what specialists do. Their value to the organization is demonstrated through the platform they construct, not through the platform they procure. The incentive structure pushes toward assembly.

We do not blame them for it. Knowledge says “I can build this.” That is often true. Experience says “we have seen what happens when you do”... and that is a different kind of true.

What typically happens next

The build goes well at first. The team is energized, the architecture is clean, the early results are promising. Twelve to eighteen months later, the picture looks different.

The platform needs patching. Upstream CNCF dependencies have moved. The two engineers who designed it are now the only people who fully understand it, and they are spending an increasing proportion of their time keeping it running rather than improving it. Internal customers are raising tickets. Security updates are getting deferred because there is always something more urgent. The team that was hired to accelerate the organization’s Kubernetes capability is now, in practice, a support function for a bespoke platform that nobody else can operate.

We have seen resignations follow. We have seen shadow IT re-emerge because internal customers lost confidence in the platform team’s bandwidth. We have seen organizations that started this journey with two strong engineers end up with two exhausted ones.

Our managed services team has picked up a number of enterprises at exactly this point. Not at the start, when the build decision felt right, but 18 to 24 months in, when the CIO went looking for a fix. The fix, in each case, was to outsource operations to people who do this for a living. And part of that outsource was ripping out the assembled jigsaw of tools the internal team had built, replacing it with a platform we can run optimally and predictably. The cost of that transition, in time, disruption, and goodwill, is rarely something those organizations had modeled when the original build decision was made.

None of this is inevitable. Some teams build well and sustain it. But it requires ongoing investment that organizations routinely underestimate at the point of the decision.

When we recommend not proceeding

If an organization has already committed to building its own platform, we will say so directly: Portainer is probably not the right call right now. Not because we do not believe in the product, but because the value it delivers will not land in that environment. Portainer reduces the need for specialist platform engineering. If you have just hired specialist platform engineers and their mandate is to build, that value does not compute.

The organizations Portainer is built for have made a different decision. They want Kubernetes operational capability without the overhead of constructing and maintaining the scaffolding themselves. They want their engineering teams focused on the systems and applications that matter to the business, not on keeping a bespoke control plane alive. They want to get started without a six-month architecture project, and they want ongoing operations to stay sane as the environment grows.

If that is the decision the organization has made, Portainer will deliver. If the decision has gone the other way, we would rather say so than waste months on an evaluation that was never going to land.

The door

We are not precious about this. Organizations change direction. The build-it team hits the wall, priorities shift, leadership asks hard questions about platform overhead, and the conversation becomes relevant again. When that happens, we are easy to find.

We would rather be honest now and useful later than the other way around.

My kids did not grow up that way.

They are Gen Z, nineteen and twenty two. Their first computing device was a Chromebook… and then very quickly, a phone or tablet. Chrome OS was unremarkable to them because it was just the web, which is where everything lived anyway. When they gamed, it was on a PlayStation or Xbox, not a PC. Windows never got those leisure hours. So when they encounter it now, it does not feel like home. It feels strange, foreign, like I feel when someone hands me a device I did not grow up with and expects me to just get on with it.

In between us sits the millennial generation, and they are the most interesting part of this story. They learned on Windows, but came of age just as smartphones and web apps arrived. They adapted. Comfortable on both, native to neither. As they moved into roles with IT influence and purchasing decisions, they did not evangelize Windows the way my generation did. They were fine with whatever worked. That indifference quietly eroded the familiarity loop that had kept Windows self-reinforcing for decades, and set the table for the generation that followed to reject it more completely.

Gen Z is in the workforce now. What they want is a tablet running a tablet OS (or a PC running an OS that feels tablet-like), connected to web-based tools, behaving the way their phone does. They do not want Office 365… they are already highly proficient in Google Docs and Sheets, and see no reason to change. A file system feels like an unnecessary abstraction. Their baseline expectation of “good” is a mobile experience, and Windows does not meet that bar.

So was Windows dominance always generational? Not technical, not even economic… generational?

The network effect that gave Windows its grip was not really about the software. It was about who learned it first, then taught it to the next person, who got hired somewhere that already ran it, who then bought it at home because it matched what they used at work. A familiarity loop. For two or three decades, that loop was self-reinforcing, because the people doing the hiring, the IT purchasing, and the school curriculum decisions all came from the same Windows-native cohort.

That loop is breaking.

The cohort in the workforce now did not come through it. And Microsoft had one real shot at intercepting this transition… mobile. Windows Phone was the bridge that could have planted the flag in the next generation’s formative years. It failed, and not just commercially. It failed to capture a single classroom, a single pocket, a single habitual moment for the generation that was going to matter most.

Familiarity is the deepest competitive moat in consumer technology. Microsoft built that moat over decades. They just forgot to fill it for the next generation… and mobile was the moment they needed to.

And I do not think this is just about Windows.

I spent my formative IT years building computers from parts, hand-installing everything, learning what every POST beep meant. When virtualization arrived in the early 2000s, we jumped on it. We honed entire careers around VMs as the primary deployment mechanism… and built IT landscapes of genuine complexity on top of them. The tooling, the practices, the operational discipline required to manage that at scale took decades to develop and refine.

The millennial IT generation inherited what we built. They supported it, understood it, but also looked for ways to improve on it. They jumped onto containerization early and brought a fresh perspective with them.

The Gen Z IT person is container native. They know no prior world. To them, the idea of hand-installing an application is as foreign as a file system and a command prompt is to my kids. They work at a higher level of abstraction, and they are very good at it.

Each generation stands on what the previous one built, and then moves forward from there. That is how progress works.

So are VMs and installable software generational, just like Windows? Is the future of IT purely containers, web, and serverless? My gut says yes. And if history is any guide, the generation after Gen Z will not even remember there was a debate.

d2k makes both sides happy at the same time.

The model is straightforward. A platform engineer builds and operates a Kubernetes cluster the way they would anyway: with proper resource limits, network policies, and production-grade reliability. They slice that cluster into namespaces and deploy a tiny d2k pod into each one. Each developer gets pointed at their namespace’s d2k endpoint and, from their perspective, they have a Docker host. They connect with the Docker CLI, with Portainer, or with any Docker SDK client. They run containers, view logs, exec into shells, watch events, and check stats. None of that requires them to know what a Deployment is.

The developer’s “Docker host” is a synthetic construct sitting on top of Kubernetes infrastructure that far exceeds what any laptop can provide. For teams with remote developers, particularly those working from locations where hardware constraints make local development challenging, this pattern is compelling. All compute happens centrally. The developer connects to their namespace endpoint and works as if the environment is local. The platform team retains full control and visibility over what’s actually running.

d2k translates the Docker API surface into Kubernetes operations scoped to a single namespace. docker run -p 80:8080 creates a Deployment and a LoadBalancer Service. docker volume create creates a PersistentVolumeClaim. docker logs --follow streams from the pod log API. docker exec -it mycontainer /bin/bash opens a shell in the pod via SPDY. docker stats pulls real metrics from the cluster’s metrics-server. docker events replays Kubernetes event history and streams live resource changes.

That said, d2k is different from KubeDock, which is the closest comparable project. KubeDock also exposes a Docker API backed by Kubernetes, but its design target is CI pipelines and testcontainers: short-lived ephemeral containers in a Tekton or similar pipeline context. It uses Pods directly (not Deployments), implements port-forwarding for local access, and handles volumes by copying content in via init containers. It is optimised for fast container turnover in automated test runs. d2k targets interactive developer use: longer-lived workloads, Portainer UI integration, WebSocket console access, real stats, and event streaming. The two tools solve adjacent problems for different audiences.

d2k is a Portainer Skunkworks project, MIT licensed, with multi-arch images (amd64 and arm64) published on every commit. The code is at github.com/portainer/d2k.

You can see a demo of d2k in use here:

The same pattern runs in reverse. We also see organisations that have invested heavily in platform engineering, SRE practices, and sophisticated tooling... to run two or three non-critical applications that do not justify any of it. The ROI is negative, not because the technology is wrong, but because the required maturity level was never honestly defined.

Both are maturity problems, not technology problems.

We have been working through this manually with customers for a while, using a slide deck and a consultant to guide the conversation. It worked. It did not scale. So we rebuilt it as a self-service web tool and published it this week.

The assessment covers four dimensions: the technical skills your team actually has, how your IT structure supports containerization in practice, whether your application portfolio is ready for containers, and the tooling and platform infrastructure you have deployed. Strength in one area does not compensate for a gap in another.

It ends with a question most container initiatives never formally answer: what level of maturity does your business actually need? If your containers run non-critical internal tooling, you do not need an SRE team and a multi-cluster GitOps platform. If revenue-critical services depend on your container platform, you cannot afford to operate at an opportunistic maturity level.

The indicators of a gap are almost always present before the outages and the cost blowouts. Engineers spending more time fixing unexpected issues than running the system. Fear to perform required platform upgrades. Monitoring costs spiraling. These are not bad luck. They are predictable consequences of a specific maturity gap.

No account required, results are immediate, and a printable report is available at the end. Run it, and share it with whoever owns the container platform decision in your organisation.

https://maturityassessment.portainer.io

In most enterprise IT systems, the honest answer is no. A restart window measured in seconds is acceptable. Retries handle transient errors. Users refresh dashboards. Systems self-heal. Kubernetes was built precisely for this kind of environment.

On a manufacturing line, that same interruption can scrap product, damage tooling, or trigger safety interlocks. The tolerance model is different. In some environments, the goal is not rapid recovery. It is uninterrupted continuity.

That distinction changes how we think about Kubernetes at the industrial edge.

What Kubernetes Actually Provides

Kubernetes is a distributed control system built around reconciliation. You declare desired state. The control plane continuously works to ensure that running state converges toward that declaration.

• If a container crashes, it is restarted.

• If a node fails, workloads are rescheduled.

• If a replica disappears, it is recreated.

This behavior is made possible through consensus. The control plane maintains authority via quorum, typically backed by etcd. A majority must survive for the cluster to remain authoritative. This prevents split brain and ensures consistency across the distributed system.

Within those design assumptions, Kubernetes is exceptionally robust.

But it assumes that restart is acceptable and that shared authority is tolerable. Industrial systems do not always share those assumptions.

Replicas, Service Discovery, and Shared Fate

A technically literate reader will reasonably ask whether the problem is already solved by scaling replicas. If three instances of an application are running, and one fails, the remaining two continue serving traffic. From a workload perspective, that provides redundancy. For many enterprise IT services, that model is both effective and sufficient.

The limitation, however, does not sit at the process layer. It sits at the authority and infrastructure layer.

Those replicas exist inside a shared control domain. They depend on the same etcd quorum, the same API server, the same scheduler, and the same cluster networking fabric. Even at the service discovery layer, they rely on shared components such as CoreDNS and dynamic internal routing. In a stable data center environment, these abstractions simplify operations and provide powerful flexibility. They are part of what makes Kubernetes attractive.

At the industrial edge, the environmental assumptions change. Cabinets may sit on different power circuits. Network links may traverse industrial switches subject to segmentation or interference. Hardware may operate in temperature and vibration ranges rarely encountered in cloud environments. Under these conditions, shared infrastructure subsystems represent correlated failure domains.

If the control plane becomes unavailable, the authority to reconcile state is affected for all replicas simultaneously. If etcd experiences issues, the entire cluster’s ability to maintain consistency is impaired. If cluster-wide DNS or networking degrades, service-to-service communication across all replicas is impacted at once. None of this implies fragility in Kubernetes itself. It reflects the reality that replicas inside a single cluster remain coupled through shared authority and shared infrastructure layers.

In enterprise IT, this coupling is generally acceptable because the cluster is treated as a reliable abstraction boundary. In industrial systems, where eliminating correlated failure is often a primary design objective, concentrating authority and service discovery into a single distributed cluster may be viewed as an unnecessary aggregation of risk. The architectural conversation therefore shifts from how many replicas are running to where the boundary of authority and failure containment should actually be drawn.

The A+B+C Redundancy Model

Industrial and aerospace engineering provide a useful contrast. Commercial aircraft do not depend on a distributed cluster maintaining quorum in order to remain airborne. Instead, they implement triple modular redundancy. Three independent control systems operate simultaneously, each capable of full function. Their outputs are compared through arbitration logic, and divergence is resolved through voting mechanisms. The defining characteristic of this model is independence rather than internal scaling.

This philosophy is increasingly applied to industrial edge computing.

Rather than constructing a single multi-node Kubernetes cluster and scaling replicas within it, the system is designed as three discrete operating units, commonly described as A, B, and C. Each unit is fully capable of running the complete application stack required by the plant. Each unit has its own compute boundary, its own networking boundary, and its own authority domain.

Availability is achieved through architectural redundancy across independent systems rather than through rescheduling within a shared cluster.

In practical terms, this can be implemented in two common ways.

One approach uses three standalone Docker (or Podman) hosts. Each host runs the identical containerized application stack, but there is no shared cluster quorum, no cross-node scheduler, and no shared control-plane state. The three hosts are treated as a logical deployment group, ensuring that the same application version is deployed consistently to Units A, B, and C. An external load balancer or supervisory controller sits in front of these hosts, performing continuous health checks and directing inbound traffic from the plant to whichever units are healthy. If Unit A fails completely due to hardware, power, or software fault, traffic is withdrawn from it automatically while Units B and C continue operating without interruption.

A second approach uses three single-node Kubernetes clusters rather than plain Docker hosts. Each unit runs its own independent Kubernetes instance, providing declarative deployment, pod lifecycle management, namespaces, and RBAC locally. Crucially, there is no shared etcd across units and no cross-node quorum to maintain. Each cluster is sovereign. The same manifests are applied independently to each cluster, typically via automation tooling that treats A, B, and C as coordinated but separate deployment targets.

Inbound access from the plant is again mediated by an external arbitration layer, typically a load balancer with active health checks. This component continuously evaluates the health of each operating unit and routes traffic accordingly. As long as at least one unit remains healthy, the application remains available to the plant. Failures are isolated to individual authority domains rather than propagating through a shared cluster fabric.

The distinction is subtle but significant. Replica scaling within a cluster provides redundancy at the process layer. Independent operating units provide redundancy at the authority layer. In environments where correlated infrastructure failure and shared control-plane dependencies are the primary concern, isolating authority domains can reduce systemic risk in ways that additional replicas inside a single distributed cluster cannot.

At the industrial edge, the design question is not simply how many pods to scale. It is where the boundary of shared authority should sit, and whether that boundary aligns with the physical and operational realities of the plant floor.

From Redundancy to Fleet Management

Designing the system as three independent operating units solves the correlated failure problem, but it introduces a new one. Once you move from a single cluster to discrete authority domains, you now have a fleet to manage.

Deploying the same application consistently to Units A, B, and C is straightforward for one work cell. The complexity emerges when that pattern is repeated across dozens or hundreds of cells, plants, or remote sites. You need a way to ensure that versions remain aligned, configuration drift is controlled, and updates can be rolled out predictably, without reintroducing a shared runtime dependency.

This is where fleet management becomes critical.

Using Portainer’s Edge compute capabilities, each standalone Docker host or single-node Kubernetes cluster can be registered as an independently managed endpoint. These endpoints can be organized into logical deployment groups that reflect the A+B+C redundancy sets. Application definitions can then be targeted to these groups, ensuring consistent deployment across each discrete unit while preserving their operational independence.

The important distinction is that management is centralized at the control level, not at the data or runtime level. Each operating unit remains sovereign. If connectivity to the management plane is lost, workloads continue running locally. Redundancy is preserved because execution authority does not depend on a shared cluster quorum.

In large industrial estates, this separation between runtime independence and centralized governance allows the A+B+C model to scale without reintroducing the very shared failure domains it was designed to eliminate.