Skip to main content
The engine cannot always reach a host directly: the host may sit in another network zone, behind a firewall that blocks the engine’s SSH or WinRM connection. You register a Kubernetes cluster or Docker Swarm whose nodes span your network zones, and give the host a placement that names the nodes in its zone. For each task, the engine starts a short-lived executor on one of those nodes. The executor connects back to the engine over TLS, opens the SSH or WinRM connection to the host from inside its zone, and is deleted when the task ends. A remote Kubernetes cluster works the same way, with the engine outside the network zone reaching in to its API server only.

​
How it works

On Kubernetes, the engine creates each executor pod through the cluster’s API: with its own service account when it runs in that cluster, otherwise with credentials you register. On Docker Swarm, the engine runs on a Swarm manager and starts each executor as a Swarm service.
  • No inbound flow. Executors connect out to the engine; nothing dials into the executor’s zone except, for a remote cluster, its API server.
  • No credentials at rest. Host credentials arrive over the TLS session, never in the pod spec or on disk.
  • An unprivileged executor. It runs as non-root with every capability dropped, and holds no service-account token or Docker socket.
  • Nothing resident. The executor is deleted when the task ends.

​
Clusters, Central and plugins

Besides executors for tasks, a cluster’s nodes can run Central and send HTTP API requests. MCP server calls go out from the engine for now; running them on a cluster is planned.