DigitalOcean fully manages Regional Load Balancers and Global Load Balancers, ensuring they are highly available load balancing services. Load balancers distribute traffic to groups of backend resources in specific regions or across different regions, which prevents the health of a service from depending on the health of a single server, cluster, or region.
DigitalOcean Load Balancers only support TLS 1.2 and TLS 1.3 for incoming connections, and do not support downgrading incoming connections to TLS 1.0 or 1.1. The same limits apply to connections from load balancers to Droplets.
The number of Load Balancers you can have on your account, and the size of each Load Balancer, depends on the limits set for your account. We use dynamic resource limits to protect our platform against bad actors. Currently, you can’t check your resource limit for Load Balancers, but you can contact support if you reach the limit and need to increase it. We are working on features that allow you to review this limit in the control panel.
Each load balancer node can support up to 10,000 requests per second.
Because DigitalOcean Load Balancers are network load balancers, not application load balancers, they do not support directing traffic to specific backends based on URLs, cookies, HTTP headers, etc.
Load balancers do not support IPv6.
When using SSL passthrough (for example, port 443 to 443), load balancers do not support headers that preserve client information, such as X-Forwarded-Proto, X-Forwarded-Port, or X-Forwarded-For. Load balancers only inject those HTTP headers when the entry and target protocols are HTTP, or HTTPS with a certificate (not passthrough).
Sticky sessions are only visible at the load balancer layer; the cookies used for sticky sessions are both set and stripped at the load balancer. Because those cookies are not present in the request sent to the backend Droplets, backend applications cannot use them.
By default, load balancers do not honor Connection: keep-alive headers returned by target Droplets. You can configure the load balancer to use fewer active TCP connections by enabling the backend keepalive setting.
You cannot add or remove firewall rules to load balancers using the control panel, but you can add them using the API or CLI by adding IP addresses and CIDRs to the allow list and deny list fields.
A load balancer’s firewall can contain up to 500 allow rules and 500 deny rules.
Load balancers have a maximum number of simultaneous connections they can maintain. If this number is exceeded, the underlying TCP connection is closed. See Plans and Pricing for the connection limits of each load balancer size. Because DigitalOcean Load Balancers operate on the transport layer of the OSI model, they do not return an HTTP code when a connection is refused due to maximum capacity.
Load balancers have a maximum number of new SSL connections they can establish per second depending on their size. If this number is exceeded, the underlying TCP connection is closed. See Plans and Pricing for the connection limits of each load balancer size.
You can resize load balancers up to once per minute. The cost is prorated based on how long the load balancer operates at each size, with a minimum charge of $0.01.
HTTP health checks are sent using HTTP/1.1. If your web server uses a version other than HTTP/1.1, the headers in the health check may not be compatible, so you need to use a TCP check.
You cannot assign a reserved IP address to a DigitalOcean Load Balancer.
Sticky sessions do not work with SSL passthrough (port 443 to 443). They do work with SSL termination (port 443 to 80) and HTTP requests (port 80 to 80).
You can add up to 10 backend Droplets by name. If you need to add more than 10 Droplets to a load balancer, you can use a tag. You can apply the tag to as many Droplets as needed and then add the tag to the load balancer. There is no limit to the number of Droplets to which you can apply a tag. Using a tag automatically updates your load balancer when you add or remove the tag from Droplets.
Ports 50053, 50054 and 50055 are reserved on DigitalOcean Load Balancers, so you cannot use those ports in forwarding rules.
You cannot resize load balancers that are sending traffic to Droplets that don’t reside in a VPC network. To resize such load balancers, recreate the Droplets within a VPC network or remove them from the load balancer’s pool.
Each load balancer may have a maximum of 40 forwarding rules.
When using UDP in forwarding rules, the maximum payload size of a UDP packet sent to the load balancer is 1424 bytes.
HTTP/3 rules do not support TLS passthrough.
Setting a custom time out length has no effect on HTTPS and HTTP/2 forwarding rules using TLS passthrough.
Internal load balancers are in early availability and can only be created through the CLI and API.
You must manage your DNS records on DigitalOcean in order for us to manage Let’s Encrypt on load balancers on your behalf.
Let’s Encrypt on DigitalOcean only supports SSL termination. SSL passthrough requires certificates on the Droplets themselves, and DigitalOcean does not install or maintain certificates on unmanaged services like Droplets.
Let’s Encrypt imposes rate limits of:
If your certificate isn’t issued on the first try, we automatically retry at 20 minute intervals up to 3 times. After that, we send email to your account’s address letting you know that the certificate creation failed.
Let’s Encrypt TLS certificates are ECDSA P-256. These certificates follow the shorter chain rooted at ISRG Root X1, and are not cross-signed by the expired DST Root CA X3. This means that very old devices, like those running Android versions prior to 7.1.1, cannot connect to any Load Balancers or Spaces CDNs using these certificates.
If you need to maintain compatibility with older devices, you can contact support and request that we downgrade your Let’s Encrypt certificate to RSA-2048. Per Let’s Encrypt, starting in September 2024, older Android devices show certificate errors even with downgraded certificates.