Delegate Requirements and Limitations
This topic lists the limitations and requirements of the Harness Delegate.
In this topic:
- Delegate Limitations
- System Requirements
- Whitelist Harness Domains
- Network Requirements
- Permissions and Ports
- Add Certificates and Other Software to Delegate
- Delegate Access Requirements
- Deployment limits: Deployment limits are set by account type. See Harness Products and Editions.
- You might need to install multiple Delegates depending on how many Continuous Delivery tasks you do concurrently, and on the compute resources you are providing to each Delegate. Typically, you will need one Delegate for every 300-500 service instances across your applications.
The Delegate is installed in your network and connects to the Harness Manager.
- Linux/UNIX server or container.
- Minimum 1 CPU.
- Minimum 8GB RAM — There is a cap of 4GB per Delegate, but when the Delegate is updating there might be two Delegates running. Hence, the minimum is 8GB.
Ensure that you provide the minimum memory for the Delegate and enough memory for the host/node system. For example, an AWS EC2 instance type such as m5a.xlarge has 16GB of RAM, 8 for the Delegate and 8 for the remaining operations.If you using the Harness Kubernetes Delegate with Harness Community Edition and using a small server, you can adjust the Kubernetes Delegate YAML setting
memory: "8Gi"to something smaller.
- Minimum 6GB Disk space.
- Shell Script Delegate requires cURL 7.64.1 or later.
- Access to artifact servers, deployment environments, and cloud providers. As shown in the following illustration:
Whitelist Harness Domains
- Harness SaaS (required): Harness Delegates only need outbound access to the Harness domain name (most commonly, app.harness.io) and, optionally, to logging.googleapis.com. The URL logging.googleapis.com is used to provide logs to Harness support.
- Harness Manager: users of the Harness Manager browser client need access to app.harness.io and static.harness.io. This is not a Harness Delegate requirement. It's simply for users to use the browser-based Harness Manager.
- Vanity URL: if you are using a Harness vanity URL, like mycompany.harness.io, you can whitelist it also.
The following network requirements are for connectivity between the Harness Delegate you run in your network and the Harness Manager (SaaS or On-Prem), and for your browser connection to the Harness Manager.
- HTTPS port 443 outbound from the Delegate to Harness.
- HTTP/2 for gRPC (gRPC Remote Procedure Calls)
- Delegate requirements: The Delegate will need API/SSH/HTTP access to the providers you add to Harness, such as:
- Cloud Providers.
- Verification Providers.
- Artifact Servers (repos).
- Source repositories.
- Collaboration Providers.
- SSH access to target physical and virtual servers.
For more information, see Supported Platforms and Technologies.
Permissions and Ports
Add Certificates and Other Software to Delegate
For steps on adding certs or other software to the Delegate, see Common Delegate Profile Scripts.
Delegate Access Requirements
- The Harness Delegate does NOT require root account access, but the Kubernetes, ECS, and Docker Delegates run as root by default. This is to enable the Delegate to install applications using Delegate Profiles (apt-get, etc). If you do not need to install applications using Delegate Profiles, then you can use a non-root account or install the application without the Delegate.
- If you do not run the Delegate as root, be aware that you cannot install any software using a Delegate Profile.