The enterprise landing pad for apps your business teams build with AI.
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.
Your people are already building. The apps have nowhere to land.
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.
Your app, live in minutes. No tickets, no drama.
Upload your files
Drag in the folder or zip your AI tool gave you. A single HTML page, or a Node or React project, as is.
Click deploy
Choose where it runs from the options IT set up for you. No git, no commands, no waiting on another team.
Done, it's live
Your app is running on the company's infrastructure. Share the link and move on.
The only platform in the open gap
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.
Run on top of Portainer Business, on your Kubernetes anywhere.
When a builder clicks deploy, 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. Updates take the same path, 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.
The builder gets self-service. You get governance.
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.
Built with the CISO in mind
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. The deployment logic is public in the Portainer-Run repository, so every claim below is verifiable in source.
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.
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.
See it run on infrastructure you already operate.
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.