How to Manage Load Balancers

DigitalOcean Load Balancers are a fully-managed, highly available network load balancing service. Load balancers distribute traffic to groups of Droplets, which decouples the overall health of a backend service from the health of a single server to ensure that your services stay online.

After you create a load balancer and add nodes to it, you can manage and modify it on its detail page.

First, click Networking in the main navigation, and then click Load Balancers to go to the load balancer index page. Click on an individual load balancer’s name to go to its detail page, which has three tabs:

  • Nodes, where you can view the nodes currently attached to the load balancer and modify the backend node pool.

  • Graphs, where you can view graphs of traffic patterns and infrastructure health.

  • Settings, where you can set or customize the forwarding rules, sticky sessions, health checks, SSL forwarding, and PROXY protocol.

Point Hostname at Load Balancer

To start sending traffic from your hostname to your load balancer, you need to create an A record on your DNS provider that points your hostname at the load balancer’s IP address.

If your DNS provider is DigitalOcean, reference Create and Delete DNS Records to see how to do this. If you do not use DigitalOcean as a DNS provider, reference your current provider’s documentation to see how this is done.

Droplet Connectivity

Load balancers automatically connect to Droplets that reside in the same VPC network as the load balancer.

To validate that private networking has been enabled on a Droplet from the control panel, click Droplets in the main nav, then click the Droplet you want to check from the list of Droplets.

From the Droplet’s page, click Networking in the left menu. If the private network interface is enabled, the Private Network section populates with the Droplet’s private IPv4 address and VPC network name. If the private network interface has not been enabled, a “Turn off” button is displayed.

Private networking enabled

Manage the Backend Nodes

In the Droplets tab, you can view and modify the load balancer’s backend node pool.

The load balancer detail page on the Droplets tab

This page displays information about the status of each node and its other health metrics. Clicking on a node name will take you to the node’s detail page.

If you are managing backend Droplets by name, you can add additional Droplets by clicking the Add Droplets button on this page. If you are managing by tag, you will instead have an Edit Tag button.

When you add Droplets to a load balancer, the Droplets start in a DOWN state and remain in a DOWN state until they pass the load balancer’s health check. Once the backends have passed the health check the required number of times, they will be marked healthy and the load balancer will begin forwarding requests to them.

View Graphs

Click the Graphs tab to get a visual representation of traffic patterns and infrastructure health. The metrics in this section change depending on whether the load balancer is for a Droplet or for Kubernetes nodes.

The load balancer detail page on the Graphs tab

The Frontend section displays graphs related to requests to the load balancer itself:

  • HTTP Requests Per Second
  • Connections
  • HTTP Responses
  • Traffic Received/Sent

The Droplets section displays graphs related to the backend Droplet pool:

  • HTTP Total Session Duration
  • HTTP Average Response Time
  • Queue size
  • HTTP responses
  • Downtime
  • Health checks
  • Number of connections

The Kubernetes section displays graphs related to the backend Kubernetes nodes:

  • HTTP Total Session Duration
  • HTTP Average Response Time
  • HTTP responses
  • Number of connections

Modify Advanced Settings

Click the Settings tab to modify the way that the load balancer functions.

The load balancer settings screen

Scaling Configuration

The load balancer’s scaling configuration allows you to adjust the load balancer’s number of nodes. The number of nodes determines:

  • How many simultaneous connections it can maintain.
  • How many requests per second it can handle.
  • How many SSL connections it can decrypt per second.
  • The load balancer’s overall monthly cost.

The load balancer must have at least one node, and can have up to 100 nodes. You can add or remove nodes at any time to meet your traffic needs.

Forwarding Rules

Forward rules define how traffic is routed from the load balancer to its backend nodes. The left side of each rule defines the listening port and protocol on the load balancer itself, and the right side defines where and how the requests will be routed to the backends.

You can change the protocols using the drop-down menus. If you use HTTPS or HTTP2, you will need an an SSL certificate or to use SSL passthrough.

DigitalOcean Kubernetes automatically manages its load balancers’ forwarding rules, based on the ports you expose for a given service on your worker nodes. You can also manually update your protocol or SSL options.

Health Checks

Health checks verify that your Droplets are online and meet any customized health criteria. Load balancers will only forward requests to Droplets that pass health checks. If your load balancer uses UDP in its forwarding rules, the load balancer requires that you set up a health check with a port that uses TCP, HTTP, or HTTPS to work properly.

In the Target section, you choose the Protocol (HTTP, HTTPS, or TCP), Port (80 by default), and Path (/ by default) that nodes should respond on.

In the Additional Settings section, you choose:

  • The Check Interval, which is how many seconds the load balancer will wait between health checks.
  • The Response Timeout, which is how many seconds the load balancer will wait between responses.
  • The Unhealthy Threshold, which is how many consecutive times a node must fail a health check before the load balancer stops forwarding traffic to it.
  • The Healthy Threshold, which is how many consecutive times a node must pass a health check before the load balancer will forward traffic to it.

The success criteria for HTTP and HTTPS health checks is a status code response in the range 200 - 399. The success criteria for TCP health checks is completing a TCP handshake to connect.

HTTP and HTTPS health checks may fail with Droplets running Apache on Rocky Linux because the default Apache page returns a 403 Forbidden HTTP response code. To fix this, either change the health check from HTTP/HTTPS to TCP or configure Apache to return a 200 OK response code by creating an HTML page in Apache’s root directory.

Sticky Sessions

Sticky sessions send subsequent requests from the same client to the same Droplet by setting a cookie with a configurable name and TTL (Time-To-Live) duration. The TTL parameter defines the duration the cookie remains valid in the client’s browser. This option is useful for application sessions that rely on connecting to the same Droplet for each request.


The SSL option redirects HTTP requests on port 80 to HTTPS on port 443. When you enable this option, HTTP URLs are forwarded to HTTPS with a 307 redirect. To redirect traffic, you need to set up at least one HTTP forwarding rule and one HTTPS forwarding rule.

Proxy Protocol

Enabling the PROXY protocol allows the load balancer to forward client connection information (such as client IP addresses) to your Droplets. The software running on the Droplets must be properly configured to accept the connection information from the load balancer.

Backend services need to accept PROXY protocol headers or the nodes will fail the load balancer’s health checks.

Backend Keepalive

By default, DigitalOcean Load Balancers ignore the Connection: keep-alive header of HTTP responses from Droplets to load balancers and close the connection upon completion. When you enable backend keepalive, the load balancer honors the Connection: keep-alive header and keeps the connection open for reuse. This allows the load balancer to use fewer active TCP connections to send and to receive HTTP requests between the load balancer and your target Droplets.

Enabling this option generally improves performance (requests per second and latency) and is more resource efficient. For many use cases, such as serving web sites and APIs, this can improve the performance the client experiences. However, it is not guaranteed to improve performance in all situations, and can increase latency in certain scenarios.

The option applies to all forwarding rules where the target protocol is HTTP or HTTPS. It does not apply to forwarding rules that use TCP, HTTPS, or HTTP/2 passthrough.

There are no hard limits to the number of connections between the load balancer and each server. However, if the target servers are undersized, they may not be able to handle incoming traffic and may lose packets. See Best Practices for Performance on DigitalOcean Load Balancers.