> For the complete documentation index, see [llms.txt](https://developer.harness.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.harness.io/harness-ai/use-harness-platform/references/private-network-connectivity/cloud-private-connectivity.md).

# Cloud Private Connectivity

Connect Harness Cloud VMs and supported Platform connectors to private networks through Tailscale

{% hint style="info" %}
**Note**

Cloud Private Connectivity requires enablement by Harness.
{% endhint %}

Cloud Private Connectivity, powered by Tailscale, connects Harness Cloud VMs and supported Harness Platform connector operations to private services. It provides an encrypted network path rather than an HTTP proxy. Applications keep their normal private URLs, TLS configuration, and authentication.

This setup has been shown to work with hosted Cloud build. It also works with other modules that run on Harness Cloud, such as Infrastructure as Code Management (IaCM).

Harness creates and operates a dedicated private-connectivity network for your Harness account. Harness also deploys the Harness-managed cloud delegate used by supported Platform connector operations. You deploy subnet routers or App Connectors in networks that can reach your private services.

For more information, see [Configure Cloud Private Connectivity](/harness-ai/use-harness-platform/references/private-network-connectivity/cloud-private-connectivity/configure.md) for the complete onboarding workflow. Kubernetes is the recommended appliance deployment. Ubuntu 24.04 VM is also supported.

***

## Supported hosted build images

Select a supported Cloud Private Connectivity image available to your account:

| Hosted build image  | Architecture          | Supported execution types                                |
| ------------------- | --------------------- | -------------------------------------------------------- |
| Ubuntu 24.04        | AMD64 / x86-64        | Native and Linux container steps                         |
| Ubuntu 24.04        | ARM64                 | Native and Linux ARM64 container steps                   |
| Windows Server 2025 | AMD64 / x86-64        | Native PowerShell and compatible Windows container steps |
| macOS Sequoia       | ARM64 / Apple silicon | Native steps                                             |
| macOS Tahoe         | ARM64 / Apple silicon | Native steps                                             |

Select the intended image explicitly; a generic `latest` label can resolve to a different operating system version. Contact Harness Support if a listed image is unavailable or you need a custom image.

Harness installs and initializes Tailscale in the Harness Cloud VM image before pipeline steps run. Do not install Tailscale in a Run step. The operating system of a customer appliance is independent of the Harness Cloud VM image. Hosted Cloud build uses these images. Other modules that run on Harness Cloud use the same private path when they run on a supported Harness Cloud VM.

***

## Components and ownership

Harness operates the network and the cloud delegate; you deploy and manage the appliances that expose your private services.

| Component                      | Purpose                                                                  | Owner                                              |
| ------------------------------ | ------------------------------------------------------------------------ | -------------------------------------------------- |
| Private-connectivity network   | Isolated Tailscale network for one Harness account                       | Harness                                            |
| Network configuration          | Permitted routes, application domains, and split DNS                     | Customer Account Admin, after Harness provisioning |
| Harness-managed cloud delegate | Runs supported Platform connector operations through the private network | Harness                                            |
| Harness Cloud VM               | Ephemeral Harness Cloud VM enrolled for one execution                    | Harness                                            |
| Subnet router                  | Forwards traffic to customer CIDRs                                       | Customer                                           |
| App Connector                  | Discovers and advertises routes for configured domains                   | Customer                                           |

The two Harness traffic paths are independent:

```mermaid
flowchart LR
  tasks["Supported connector operations"] --> delegate["Harness-managed cloud delegate"]
  steps["Harness Cloud steps"] --> vm["Harness Cloud VM"]
  delegate -->|Tailscale| appliance["Customer appliance"]
  vm -->|Tailscale| appliance
  appliance --> service["Private service"]
```

A successful connector test proves the Harness-managed cloud delegate path only. Verify private access from a Harness Cloud VM separately.

***

## Choose the network model

Select the configuration that matches how your private services are addressed — by IP range, by domain, or a combination of both.

| Requirement                                           | Harness configuration                                                          | Customer appliance        |
| ----------------------------------------------------- | ------------------------------------------------------------------------------ | ------------------------- |
| Reach a private range such as `10.77.0.0/24`          | `advertiseRoutes`                                                              | Subnet router             |
| Resolve a private suffix through a private DNS server | Route to the resolver plus `dns.splitDnsDomains`                               | Subnet router             |
| Reach destinations selected by domain                 | `domains` plus an `advertiseRoutes` boundary containing every resolved address | App Connector             |
| Reach CIDRs and configured domains from one network   | Routes and domains                                                             | Combined appliance        |
| Reach routes and domains from different networks      | Routes and domains                                                             | Separate appliance groups |

Harness provisions the account with `advertiseRoutes: ["*"]`, empty domains, and no split-DNS overrides. The wildcard permits supported destination ranges in the server-side policy; it does not make an appliance advertise a default route. A subnet router advertises its actual CIDRs. An App Connector advertises routes it learns for configured domains.

You can replace the wildcard with explicit CIDRs. The same boundary applies to subnet routes and App Connector-discovered addresses. A domain that resolves outside the configured boundary is not reachable through Cloud Private Connectivity.

All eligible workloads in an account use the same account network policy. Appliance groups divide network paths and provide placement or failover; they do not create per-project, per-pipeline, per-domain, or per-port authorization boundaries. Once a route or domain is configured and the relevant activation control is on, every enrolled Harness Cloud VM and opted-in connector operation in that account can use it. Enforce narrower access with destination firewalls, TLS, repository permissions, Vault policies, and application credentials.

Harness manages load balancing and failover across eligible appliances serving the same routes or applications. Each client uses a selected appliance; multiple replicas do not combine bandwidth for one transfer or guarantee an even traffic distribution. Subnet-router replicas must advertise identical CIDRs, and App Connector replicas must resolve and reach the same applications.

Exit nodes are not supported. Do not use `--advertise-exit-node`, `0.0.0.0/0`, or `::/0`. The wildcard configuration excludes default routes and protected ranges.

***

## Network connectivity requirements

No public inbound port is required for the appliance. Permit stateful return traffic for the following outbound connections:

| Source               | Destination                              | Protocol and port                                               | Requirement                                           |
| -------------------- | ---------------------------------------- | --------------------------------------------------------------- | ----------------------------------------------------- |
| Appliance            | Tailscale coordination and DERP services | TCP `443`                                                       | Required to establish and maintain connectivity       |
| Appliance            | Peer destinations                        | UDP from source port `41641` to any destination IP and UDP port | Strongly recommended for direct WireGuard connections |
| Appliance            | Tailscale STUN endpoints                 | UDP destination port `3478`                                     | Strongly recommended for NAT discovery                |
| Appliance            | Tailscale services                       | TCP `80`                                                        | Optional; Tailscale can use TCP `443`                 |
| Appliance            | Customer DNS resolvers                   | Customer DNS ports                                              | Required when names are used                          |
| Appliance            | Customer private services                | Normal application ports                                        | Required                                              |
| Kubernetes appliance | Kubernetes API                           | Normally TCP `443`                                              | Required to persist each pod's Tailscale identity     |

If UDP is unavailable, Tailscale can relay encrypted traffic through DERP over TCP `443`. A relayed path can have higher latency and lower throughput. Appliances also need an approved package source or internal package mirror during installation.

Go to [Tailscale firewall requirements](https://tailscale.com/docs/reference/faq/firewall-ports) for the provider endpoint details.

***

## Activation controls

Harness must enable the account capability and provision the account network before either customer control is used. The capability and both customer controls are disabled by default. Existing Secure Connect connector opt-ins are retained during migration.

| Workload                     | How to enable it                                                                                                             | Effect                                                                          |
| ---------------------------- | ---------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------- |
| Supported Platform connector | In the connector, select **Connect through Harness Platform**, then turn on **Enable Private Connectivity**                  | Sends supported connector operations through the Harness-managed cloud delegate |
| Harness Cloud VM             | Open **Default Settings > Continuous Integration** at the intended scope, then turn on **Enable Cloud Private Connectivity** | Enrolls new supported Harness Cloud VMs in the account network                  |

Open **Account Settings**, **Organization Settings**, or **Project Settings**, then **Default Settings**, for the scope you want to configure.

One control does not enable the other. A connector configured to run on a customer delegate keeps its delegate selectors and does not use the Harness-managed cloud delegate. CI stages running on customer-managed Kubernetes infrastructure are also unaffected.

Supported connector forms are AWS, GCP, Docker Registry, Artifactory, Generic Git over HTTP, GitHub over HTTP, GitLab over HTTP, Bitbucket over HTTP, and HashiCorp Vault with JWT authentication. SSH Git and other Vault authentication modes continue to use their supported customer-delegate paths.

Cloud Private Connectivity and a hosted egress-control integration such as Traceable cannot run on the same Harness Cloud VM. Traceable egress control is account-scoped; moving work to a different stage or project in the same account does not bypass this restriction. Ask Harness to confirm a compatible account configuration before rollout.

***

## Next steps

* [Configure Cloud Private Connectivity](/harness-ai/use-harness-platform/references/private-network-connectivity/cloud-private-connectivity/configure.md): Configure the account, deploy an appliance, and enable private access.
* [Deploy appliances on Kubernetes](/harness-ai/use-harness-platform/references/private-network-connectivity/cloud-private-connectivity/kubernetes.md): Deployment steps for Kubernetes.
* [Deploy an appliance on an Ubuntu VM](/harness-ai/use-harness-platform/references/private-network-connectivity/cloud-private-connectivity/virtual-machine.md): Deployment steps for
* [API and troubleshooting reference](/harness-ai/use-harness-platform/references/private-network-connectivity/cloud-private-connectivity/reference.md): Configure fields, credential renewal, and diagnostics.