The enterprise landing pad for apps your business teams build with AI

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.

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.

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. The implementation is public in the Portainer-Run repository if your team wants to verify it line by line.

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.

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.

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.