Powered by Portainer Business
Portainer-Run lets non-developers deploy their AI-generated apps onto the Kubernetes your organization already runs, attached to your internal systems, governed by Portainer Business. The builder ships. IT keeps control.
The problem
The number of people in your organization who can produce working software has gone vertical. Finance leads, ops managers, analysts, and designers are building real applications with AI. The moment one of those apps needs something inside your network (an internal database, an on-prem API, a system behind the firewall) it hits a wall.
Cloud SaaS hosting cannot reach inside the corporate network. The choices today are to open internal infrastructure to an outside provider, or to drop the app into a ticket queue where it waits and gets abandoned. The volume is only increasing.
How it lands
Drag in the folder or zip your AI tool gave you. A single HTML page, or a Node or React project, as is.
Choose where it runs from the options IT set up for you. No git, no commands, no waiting on another team.
Your app is running on the company's infrastructure. Share the link and move on.
Two ways in. The steps above are the Run interface. Prefer to stay in your AI tool? Portainer-Run also exposes an MCP server, so you can deploy straight from Claude Code or any MCP-capable assistant, no UI at all. Either way runs the same governed pipeline underneath.
Market landscape
The field splits two ways: platforms that lock your apps into vendor infrastructure, and tools built for developers. Portainer-Run is the only option built for the non-technical business builder that runs on your own infrastructure, governed by controls your platform team already operates.
Under the covers
When a builder clicks deploy, 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.
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. The builder connects through Portainer with a personal access token, 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.
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.
Do business users get access to our clusters?
No. They connect through Portainer with a personal access token, 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.
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.
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.
Only what you allow. Apps deploy into dedicated namespaces which you can pre-configure with network policies, and even zero-trust networking.
Apps deploy into namespaces you control, where you set resource limits and quotas, so a runaway app is bounded by the same Kubernetes controls you already use.
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.