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.

Only in the clusters and namespaces IT designates. You define the deployment space, and nothing lands outside it.

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.

Only what you allow. Apps deploy into dedicated namespaces which you can pre-configure with network policies, and even zero-trust networking.

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, which is the role a security or platform lead holds, 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.

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.

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.

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.

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.

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.

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.

Yes. Portainer Business runs in regulated, distributed, and air-gapped environments, and the cluster API stays off the network perimeter.

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.