Harness uses a Delegate installed inside your own network instead of Harness's cloud calling your infrastructure directly — how does this architecture work, and what fails when the Delegate can't reach either your cluster or the Harness Manager?

Think of a Harness Delegate like a hotel concierge who works inside the building instead of a remote call-center agent trying to unlock your hotel room door from outside. The concierge (Delegate) sits inside your network, walks over to reception (your Kubernetes cluster, cloud account, Vault instance) using the keys you already gave it, and only calls the corporate office (Harness Manager, the SaaS control plane) to ask for its next instruction. Nobody outside the building ever gets a key to your rooms — the concierge always initiates the call outward, never the other way around.

Harness's SaaS control plane orchestrates pipelines (definitions of build and deploy stages) but deliberately never holds direct network access to a customer's infrastructure. This was designed for a real problem: most enterprises will not open inbound ports from a public SaaS vendor into a production VPC or on-prem data center. So Harness inverted the connection model — the Delegate, a process running as a container, pod, or VM inside the customer's network, polls the Manager over outbound HTTPS, picks up queued tasks, executes them locally with locally-scoped credentials such as a kubeconfig, cloud IAM role, or Vault token, and reports results back over that same outbound channel.

When a pipeline stage runs, the Manager doesn't reach into your cluster — it publishes a task, such as "apply this Helm chart to namespace payments-api," onto a queue tied to a Delegate selector (tags like env:prod or region:us-east-1). Any Delegate matching that selector picks up the task on its next poll cycle, executes it using the local kubeconfig or cloud SDK, streams logs back to the Manager in near real time, and acknowledges completion. If multiple Delegates share the same tags, Harness distributes work across whichever is idle, giving basic load distribution without any inbound connection ever being required.

At scale, teams typically run three or more Delegate replicas per cluster for high availability, since a single Delegate is a single point of failure for anything targeting that cluster. What to monitor: Delegate heartbeat and connectivity status in the Harness UI, Delegate pod CPU and memory (large Helm charts or big kubectl diffs can spike memory), and certificate or token expiry for the Delegate's connection to the Manager. A common failure mode is the Delegate running out of disk on its ephemeral volume from accumulated task logs, causing new tasks to fail even though the Delegate still shows "Connected."

The non-obvious gotcha is that a "Connected" Delegate in the UI only proves it can reach the Manager — it says nothing about whether it can reach the deployment target. Engineers get paged for a stuck deployment, check the Delegate page, see green, and waste twenty minutes before realizing the Delegate's outbound route to a newly peered VPC was never added to a security group. Always verify target-side connectivity, such as running kubectl get ns from inside the Delegate pod, separately from Delegate-to-Manager health.