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.
DigitalOcean Load Balancers support only 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.
You can scale load balancers to have a maximum of 100 nodes.
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 (e.g. port 443 to 443), load balancers do not support headers that preserve client information, such as
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.
Accounts can have up to 10 load balancers by default. You can increase this limit by making a support request.
You cannot apply cloud firewalls to load balancers.
Load balancer connections have a keep-alive time of 60 seconds.
Load balancers have a maximum number of simultaneous connections they can maintain. See Plans and Pricing for the connection limits of each load balancer size.
Load balancers have a maximum number of new SSL connections they can establish per second depending on their size. 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 and you’ll 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.
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.
If your certificate isn’t issued on the first try, we will automatically retry at 20 minute intervals up to 3 times. After that, we’ll 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, will not be able to 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. Please note that per Let’s Encrypt, even with the downgraded certificates older Android devices will begin to see errors in September 2024.