Powered by Portainer Business
People across your organization are describing a business problem to an AI tool and getting back a working app; the only real question left is whether those apps run somewhere you govern, or somewhere you find out about during an audit. Portainer-Run gives them a secured, isolated place to run on infrastructure you own, with no hook back to the AI provider.
The problem
The number of people in your organization who can produce working software has gone vertical; a finance lead, an operations manager, or an analyst describes a business problem to Claude, ChatGPT, or Copilot and gets back a real application that solves it, and this is not a fringe habit you can wait out. It is the 2026 form of the Visual Basic and VBA solutions that quietly ran the business inside spreadsheets and documents for two decades; the people doing it are your most engaged staff, the ones who care enough about a problem to go and solve it themselves.
The questions on your side of the table are not whether this is happening; they are how you get in front of it. How do you discover the apps that already exist and are already running, whether company data is leaving right now through an app hosted on a provider's cloud, whether you can block this at all, and how you let it happen safely inside your own environment rather than driving it further out of view.
Blocking does not work, and it never has; a policy that says no moves the activity onto infrastructure you cannot see, so the only control that holds is to give these apps a sanctioned, secured place to run. That is a decision to enable the people already solving real problems rather than to fear them, and it is the decision Portainer-Run exists to make possible.
How you say yes
Someone in the business brings the app their AI tool produced, as a folder or a project. They never see a cluster, a kubeconfig, or a line of Kubernetes; the self-service surface is theirs, and the control underneath stays yours.
Portainer-Run places the app in an isolated sandbox on your own Kubernetes, enforced by namespaces, network policy, pod security, and an authenticating ingress, with its source and manifest committed to a Git repository you sanction and scan.
Every app is visible in one place under the identity that deployed it, versioned in Git, and reversible in one click; nothing reaches a cluster except through this path, so the inventory is complete by construction.
Whichever way an app arrives, through the Run interface or through the MCP endpoint your people's AI tools can call, it runs the same governed pipeline underneath; there is no side door, and no path to a cluster that skips your controls.
One-page overview
From an AI-generated app to a secure, running workload on infrastructure you already own. This one-page overview walks the shift, the roadblock, and how Run closes the gap, ready to share with a colleague or drop into a deck.
Download infographic (PNG) ↓Market landscape
The field has two well-populated ends and an empty middle. At one end are platforms that build a vibe-coded app and host it on their own cloud, where your data goes with it and the app stays theirs to keep; at the other end are internal developer platforms built for professional engineers who already know Kubernetes and Git. Nothing sat between them, which is a way to take the vibe-coded apps your people already build and run them on infrastructure you own, with no hook back to the provider. That is the gap Portainer-Run fills, and being first to fill it is the point.
Under the covers
When one of your people deploys, this is what happens underneath. Portainer-Run generates the Kubernetes deployment manifest, commits it and the source files to your sanctioned Git repo, then triggers a GitOps deployment in Portainer Business. Your scanning runs on the repo. Portainer Business, the operator control plane, reconciles that deployment from Git into the cluster and namespace you designate, with access bound by your Portainer RBAC. Your Kubernetes runs wherever it lives. Updates take the same path: a change to a running app is committed back to Git and reconciled from there, so the live state always matches the repo and any deployment is fully repeatable.
The isolation your security team asks about is a property of this path rather than an add-on to it; each app lands in a namespace bounded by network policy, pod security, and an authenticating ingress, so it runs with near-zero reach on the network beyond what you explicitly grant, on a BYO cluster exactly as on a dedicated appliance.
Builders deploy their AI-built apps with zero need to know anything about Docker, Kubernetes, or even that their app runs in a container. Portainer-Run handles all the complexity under the covers.
Reconciles the GitOps deployment Run triggers and applies it to your cluster. Access is governed by RBAC.
Cloud, on-prem, edge, air-gapped. Deployments scoped to the clusters and namespaces you designate.
Control, set once
Regulated · distributed · air-gapped environments
Portainer Business, the operator control plane already trusted across Fortune 2000 enterprises, government agencies, and regulated industries, runs underneath. Portainer-Run commits each artifact to your sanctioned Git repo, which becomes the system of record, and your existing scanning and policy controls apply there before anything runs. Your people connect through Portainer under their own identity, never a kubeconfig or direct cluster access, and everything they can do is bound by your Portainer RBAC role.
Portainer Business reconciles each deployment from Git, so you can roll back to a previous version in one click and every change is captured. Deployments are scoped by environment and namespace, so who can deploy where stays under your control. The cluster API stays off the network perimeter, and your platform team sets the rules once rather than clearing tickets one at a time. This holds on a Kubernetes cluster you already run; standing Run up on a dedicated appliance adds isolation on top of it, but the governance and the sandbox come from the architecture, not from where it is installed.
The offramp
Some of your people have already stood something up on Lovable, Bolt, or Replit, because for a while that was the only route open to them; those apps run on someone else's cloud today, and many of them are reaching back toward your data to do their job. That is the exposure you are trying to close, and pulling the apps back inside closes it at the source.
Portainer-Run gives you that offramp. Take the source your people already have and run it inside, on infrastructure you own, under the same governance as anything else, with no rebuild for a self-contained app. Where an app leans on a provider-hosted backend the relocation is partial rather than total, and the briefing covers exactly what that involves for your case, so the offramp is honest about where it ends.
The lifecycle
Most vibe-coded apps are an idea worked out in code and then set aside once the point is made; a minority get used every day, earn their place, and become something the business quietly depends on, and those deserve a real path forward rather than staying frozen as generated source with no owner.
Portainer-Run is where every app lands and runs under governance from the first day. When one earns a proper engineering owner, it graduates to your development team through Portainer-IDP, where they can see and adjust every technical decision Run made and productionize the app in a true DevOps manner. Run is the governed front door; IDP is where a proven app grows up, and we will walk you through that path directly.
We will walk you through a live deployment on a governed Kubernetes environment and show you exactly what it takes to stand it up in yours.
Security and control
Introducing vibe-coded apps into the enterprise raises fair questions. Run is designed to answer them up front, so your security team signs off rather than blocks the work. Every control below is written into the manifest committed to your own Git repo, so each claim is verifiable against what actually lands in your cluster.
Can we actually block vibe-coded apps?
Not in any way that holds. A ban moves the activity onto tools and clouds you cannot see, so the control that works is a sanctioned, secured place to run. You govern these apps by giving them somewhere governed to go, which is exactly what Portainer-Run is.
How do we discover the ones already running?
Every app deployed through Run passes one governed pipeline and carries the identity that deployed it, so the inventory is complete by construction rather than reconstructed after the fact. For apps already stood up outside, the offramp brings them into that same inventory.
Is our data leaking to the AI app provider?
It can be, when an app runs on a provider's cloud and reaches back for your data to do its job. Apps deployed through Run run on your own clusters and your own infrastructure, so the app and its data stay inside your environment.
Do business users get access to our clusters?
No. They connect through Portainer under their own identity, bound entirely by your Portainer RBAC role. They never receive a kubeconfig or direct cluster access.
Does our data leave our environment?
No. Apps run on your own clusters and your own infrastructure, including on-prem and air-gapped. Portainer-Run is the control plane that places them there, not a hosting service.
Does this work in regulated or air-gapped environments?
Yes. Portainer Business runs in regulated, distributed, and air-gapped environments. The cluster API stays off the network perimeter throughout.
Is there an audit trail, and can we roll back?
Yes. Every deployment is committed to your Git repo, giving you a full version history. You can roll back to any previous version in one click from Portainer Business.
How is each app locked down at runtime?
Every app deploys hardened by default. Containers run unprivileged with all Linux capabilities dropped and privilege escalation disabled, under the RuntimeDefault seccomp profile, and no Kubernetes service account token is mounted. Each app also carries sensible resource requests and limits, so nothing runs unbounded.
Who can reach a deployed app?
Only the internal users you choose. We recommend and fully support Pomerium as the in-cluster ingress, configured to pre-authenticate access to each app, so a deployed app is reachable only by authenticated internal users and never open on the network by default.
Governing the motion
Not in any way that holds. A policy that says no does not stop the work; it moves it onto personal accounts, unmanaged tools, and outside clouds you cannot see, which is the opposite of control. The approach that works is to give these apps a sanctioned, secured place to run inside your environment, so the activity comes to a surface you govern rather than going further out of view. Portainer-Run is that place.
For anything deployed through Run, discovery is not a hunt: every app passes one governed pipeline, carries the identity of whoever deployed it, and is defined in your Git repo, so the inventory is complete by construction. For apps your people already stood up outside, the offramp is how you bring them in, at which point they join the same complete inventory as everything else.
It can be, and this is the exposure most worth closing. An app that runs on a provider's cloud and reaches back into your systems for data moves that data across your boundary every time it runs. Apps deployed through Run run on your own clusters, on your own infrastructure, including on-prem and air-gapped, so the app and its data stay inside your environment and there is no provider in the path to leak to.
Access and authorization
No. They connect through Portainer with a personal access token, and everything they can do is bound by your Portainer RBAC role. They never get a kubeconfig or direct cluster access. Portainer is the gateway, and it deploys on their behalf.
Deployments are scoped by environment and namespace, and access is governed by Portainer Business RBAC, so a builder can only deploy into the space you have granted.
Yes. An administrator sees every app deployed through Run in one place, regardless of who deployed it, and each app's manifest and source also live in your Git repo. The only way in is the governed pipeline, so the inventory is complete by construction and there is no shadow deployment to find after the fact.
Every deployment is made under the Portainer identity that triggered it, so you know who deployed what, and the app and its history live in your Git repo. Nothing reaches the cluster anonymously.
Only the internal users you allow. We recommend and fully support Pomerium as the in-cluster ingress for Run apps, configured to pre-authenticate every request to each app. Nothing an AI builder deploys is exposed openly on the network by default, and access is bound to authenticated internal users through the identity provider you already run.
Code integrity and supply chain
Every artifact commits to your sanctioned repo, where your scanning and secret detection run, and the cluster's admission controllers reject anything that does not meet policy before it starts. The gate is yours.
No. IT configures a shared Git target once, with your code scanning and policy enforcement on it, and every app deployed against that target inherits those controls automatically. You set the gate a single time and it applies to every builder who uses the target, with no per-app trust decision.
The token for the source repo is stored as a Kubernetes Secret and injected into the clone step by reference, so it never appears in the deployment spec or on any command line.
Portainer Business reconciles the manifest from your repo as a GitOps stack and polls for changes on a set interval. Before the container starts, three init containers run in sequence: the first clones the committed source from Git into a persistent volume, the second installs dependencies with the package manager for the detected runtime (npm, pip, and so on) inside the runtime image, and the third writes a .env file from the values entered at deploy. There is no image build and no registry in the path.
Runtime control
Only in the clusters and namespaces IT designates. You define the deployment space, and nothing lands outside it.
Every app deploys to the Kubernetes baseline pod security profile by default. Containers run unprivileged, with all Linux capabilities dropped, privilege escalation disabled, and the RuntimeDefault seccomp profile pinned. The pod does not mount a Kubernetes service account token, so a deployed app has no ambient credentials to the cluster API. These controls are written into the committed manifest, so they are visible and auditable in your Git repo rather than applied invisibly.
Every app is deployed with sensible resource requests and limits already applied, so nothing runs unbounded even before you add namespace policy. Apps also deploy into namespaces you control, where you set resource quotas of your own, so a runaway app is bounded by the same Kubernetes controls you already use. Because the requests and limits live in the committed manifest, a platform administrator can tune them in Git for a workload that genuinely needs more.
Only what you allow. Apps deploy into dedicated namespaces which you can pre-configure with network policies, and even zero-trust networking.
You see each app's status and logs in Portainer and can stop or roll one back at once. Because these are ordinary Kubernetes workloads, your existing runtime monitoring applies to them too.
Updates take the same path as the first deploy. The change is committed to Git and Portainer Business reconciles it from there, so the running state always tracks the repo. That removes out-of-band drift and means every deployment, first or hundredth, is fully repeatable.
Operations and lifecycle
The app does not depend on them. It is standard source in Git running as a standard Kubernetes deployment, owned by the platform rather than the person. Deploy access is governed by Portainer RBAC, so a leaver or role change is handled by your normal identity process, and the running apps are unaffected and can be reassigned.
Every app is visible in one place and defined in Git, so retiring one is deliberate: remove it and its manifest leaves the repo and the workload leaves the cluster. You always hold the full inventory, so nothing becomes an untracked zombie.
Each one is standard source and a standard Kubernetes deployment, versioned in your Git repo and running on a platform your team already operates. There is no proprietary runtime to learn. You review, update, roll back, and hand off a Run app the same way you would any other Git-backed workload.
Data and compliance
No. Apps run on your own clusters, on your own infrastructure, including on-prem and air-gapped. The app and its data stay inside your environment. Run is the control plane that places them there, not a hosting service that takes your data elsewhere.
Yes. Portainer Business runs in regulated, distributed, and air-gapped environments, and the cluster API stays off the network perimeter.
Yes. Every deployment is committed to your Git repo, so you have a full version history, and you can roll back to a previous version in one click.
Request a briefing
We will show you Portainer-Run deploying a real AI-generated app onto a governed Kubernetes environment, and what it takes to stand it up in yours.