# Load Balancers

Octopus Deploy can work with any http/https load balancer technology.  There are plenty of options when it comes to choosing a load balancer to direct user traffic between each of the Octopus Server nodes.

## Load Balancer Basics

Octopus Server provides a health check endpoint for your load balancer to ping: `/api/octopusservernodes/ping`.

:::figure
![Load balancer ping UI](/docs/img/shared-content/administration/images/load-balance-ping.png)
:::

Making a standard `HTTP GET` request to this URL on your Octopus Server nodes will return:

- HTTP Status Code `200 OK` as long as the Octopus Server node is online and not in drain mode.
- HTTP Status Code `418 I'm a teapot` when the Octopus Server node is online, but it is currently in drain mode preparing for maintenance.
- Anything else indicates the Octopus Server node is offline, or something has gone wrong with this node.

:::div{.hint}
The Octopus Server node configuration is also returned as JSON in the HTTP response body.
:::

We typically recommend using a round-robin (or similar) approach for sharing traffic between the nodes in your cluster, as the Octopus Web Portal is stateless.

All package uploads are sent as a POST to the REST API endpoint `/api/[SPACE-ID]/packages/raw`.  Because the REST API will be behind a load balancer, you'll need to configure the following on the load balancer:

- Timeout: Octopus is designed to handle 1 GB+ packages, which takes longer than the typical http/https timeout to upload.
- Request Size: Octopus does not have a size limit on the request body for packages.  Some load balancers only allow 2 or 3 MB files by default.

## Polling Tentacles

Polling tentacles deserve special attention due to how they work with Octopus Deploy.  Each node that processes tasks must be registered with every polling tentacle.

We recommend having a dedicated URL for each node in the primary region and routing all traffic through a load balancer or a traffic manager.  When you have to fail over to the secondary region, update the dedicated URLs to point to a corresponding node in the secondary region.

:::div{.warning}
Important! You must configure the traffic to be "pass through" with no SSL off-loading.  The tentacles and Octopus Deploy establish a two-way trust via certificates.  If a third unknown certificate is introduced, the tentacle and Octopus deploy will reject the connection.
:::

## gRPC Services

Several Octopus features (eg. Kubernetes Live Object Status and Argo CD integration) rely on communications via gRPC that require specific configuration to account for certificate trust.

Octopus generates a self signed certificate for gRPC communications. When the a gRPC client needs to connect to Octopus via a load balancer, there are two common methods to achieve this:

1. Using TLS/SSL bridging, with verification disabled between the load balancer and Octopus. Additional configuration will be required for the gRPC client to trust the load balancer certificate.
2. Using TLS/SSL passthrough

## Third Party Load Balancers

This section contains information on how to set up third-party load balancers for use with Octopus High Availability:

- Local Options
  - [Using NGINX as a reverse proxy with Octopus](/docs/installation/load-balancers/use-nginx-as-reverse-proxy)
  - [Using IIS as a reverse proxy with Octopus](/docs/installation/load-balancers/use-iis-as-reverse-proxy)
  - [Configuring Netscaler](/docs/installation/load-balancers/configuring-netscaler)
- [AWS Load Balancers](/docs/installation/load-balancers/aws-load-balancers)
- [Azure Load Balancers](/docs/installation/load-balancers/azure-load-balancers)
- [GCP Load Balancers](/docs/installation/load-balancers/gcp-load-balancers)