The enterprise vibe coding problem, and what we built to solve it

Portainer-Run, now GA... more info on https://portainer.ai

AI coding tools are producing real, working software; functional internal applications that business teams are deploying somewhere right now, using whatever hosting they can reach. If your organization hasn’t yet had a conversation about where those apps are running and who is responsible for them, you are about to have it. Portainer-Run is our answer to that question, and it reaches general availability today, July 16.

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.