Skip to main content
The 2501 engine runs each tool executor in its own isolated sandbox. On Docker and Docker Swarm that sandbox is a container. On Kubernetes and OpenShift the engine creates a short-lived Kubernetes Pod instead: a pod is created when work starts, the engine attaches to it over stdin and stdout, and the pod is deleted when the task ends. This page covers how the Kubernetes backend selects itself, the access (RBAC) and environment it needs, and a reference set of manifests you can adapt for your cluster.
Docker Swarm remains the default deployment target. The Kubernetes backend is newer: treat the reference manifests below as the source of truth and provision the executor RBAC and environment yourself, rather than expecting the install tooling to set them up for you.

​
Executor backend selection

The engine picks an executor backend automatically:
  • When it detects that it is running inside a Kubernetes cluster, it uses the Kubernetes pod backend.
  • Otherwise it falls back to Docker / Swarm.
You can force a backend with the EXECUTOR_MCP_BACKEND environment variable, set to kube or docker.
The engine talks to the in-cluster Kubernetes API directly using the pod’s auto-mounted service-account token. It does not shell out to kubectl, and you do not supply a kubeconfig. This removes the earlier OpenShift startup failure that reported Executable not found: kubectl.

​
Required access (RBAC)

The engine’s ServiceAccount needs permission to manage executor pods in the namespace where those pods run. Grant it a Role and RoleBinding in the executor namespace with these verbs:
ResourceVerbs
podscreate, get, delete
pods/attachcreate
pods/logget (optional, for debugging)

​
Required environment

Set the required environment (including the cluster API CA via NODE_EXTRA_CA_CERTS and the executor namespace) and image pull secret as shown in the reference manifest.
gMSA-bound Windows targets are not supported on the Kubernetes executor backend. They depend on a Docker-volume Kerberos sidecar that this backend does not provide. Use the Docker or Swarm backend for those targets. See Docker Swarm.

​
Reference manifests

The reference manifests are the source of truth for a Kubernetes or OpenShift deployment. Adapt the namespace, registry, image tag, and secret values to your environment. They cover:
  • Namespace
  • ServiceAccount for the engine
  • Role and RoleBinding granting the executor pod RBAC
  • ConfigMap and Secret for engine configuration
  • Engine Deployment (running as non-root)
  • Service
For the full set of engine and Command Center environment variables (database, security keys, LLM providers, optional integrations), see Configuration.