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.

Plans and Pricing

Load balancers cost $10.00 per month for each node they contain. For example, if a load balancer contains six nodes, the monthly cost of the load balancer is $60.00 per month.

Each additional node increases the load balancer’s maximum:

  • Requests per second by 10,000
  • Simultaneous connections by 10,000
  • New SSL connections per second by 250

You can add up to 100 nodes to a load balancer.

Load balancers can be scaled up or down at any time to meet your performance needs. The more nodes a load balancer has, the more simultaneous connections and requests per second (RPS) it can maintain. The load balancer’s costs are prorated by the number of hours it runs at each size. The amount of hours it runs at each size will be displayed on a separate line in your invoice. You can resize a load balancer only once per minute.

Performance may vary depending on the load balancer’s workload. Using different protocols and package management settings will produce different results. Therefore, we cannot provide specific performance metrics for each load balancer size, and we strongly recommend that you run your own benchmarks to see what size works for your application’s specific needs.

There is no additional cost to use Let’s Encrypt with load balancers.

The maximum number of new SSL connections does not apply to load balancers configured for SSL passthrough.


The scaling feature is not available in the following regions at this time: AMS2, NYC2, SFO1. In these regions, you can only create load balancers with one node, which equates to a small size load balancer under the legacy scaling system.

The load balancer’s cost per month is based on the number of nodes it contains.


DigitalOcean Load Balancers by themselves don’t generate bandwidth charges, they are bandwidth neutral.

However, the public outbound traffic that originates from your resources and passes through the load balancer counts towards your bandwidth limit. In this scenario, the aggregated bandwidth is reported as part of the load balancer and not attributed to the individual resources behind it.

Regional Availability

Load balancers and Let’s Encrypt certificates are supported in every region.

The Droplets in a load balancer’s backend pool must be in the same region as the load balancer.


There are a number of benefits to adding a load balancer to your infrastructure.

  • Using a load balancer as a gateway gives you the flexibility to change your backend infrastructure without affecting the availability of your services, enabling seamless scaling, rolling deployments, large architecture redesigns, and more.

  • Sharing the processing workload among a group of servers rather than relying on a single server prevents any one machine from being overwhelmed by requests.

Load balancing services like DigitalOcean Load Balancers give you the benefits of load balancing without the burden of managing the operational complexities.

High Availability

All DigitalOcean Load Balancers automatically monitor their backend pools and only send requests to Droplets that pass health checks. You can define health check endpoints and set the parameters around what constitutes a healthy response. The load balancer automatically removes Droplets that fail health checks from rotation and adds them back when the health checks pass.

Additionally, DigitalOcean Load Balancers with more nodes can stay more highly available by distributing traffic among the remaining nodes when a node goes down.

Backend Droplet Tagging

There are two different ways to define backend Droplets for a load balancer:

  • By name, which lets you add individual Droplets to a load balancer using the control panel or API.
  • With a tag, which load balancers evaluate at runtime.

Tags are custom labels you can apply to Droplets.

You can choose up to 10 backend Droplets by name. However, we recommend using tags as a more scalable automated solution. 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.

You can use one tag per load balancer.

Backend Droplet Connections

The load balancer automatically connects to Droplets in its VPC network. If a Droplet’s private networking interface has been disabled, the load balancer connects to the Droplet using its public IP address when added to the load balancer. All Droplets created after 1 October, 2020 are added to a VPC network by default.

Load balancers send traffic to Droplet using dynamic backend IP addresses that are separate from the public IP addresses displayed in the control panel. Backend IP addresses may change at any time and should not be used to configure firewalls.

Load Balancing Algorithm

The load balancing algorithm assigns new connections and requests to the backends as equally as possible, while maintaining performance as more backends are introduced. In nearly all cases, the load balancing algorithm provides better performance and distribution than traditional round robin and least connections options.

Protocol Support

A single DigitalOcean Load Balancer can be configured to handle multiple protocols and ports. You can control traffic routing with configurable rules that specify the ports and protocols that the load balancer should listen on, as well as the way that it should select and forward requests to the backend servers.

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.


Standard HTTP balancing directs requests based on standard HTTP mechanisms. The load balancer sets the X-Forwarded-For, X-Forwarded-Proto, and X-Forwarded-Port headers to give the backend servers information about the original request.

If user sessions depend on the client always connecting to the same backend, a cookie can be sent to the client to enable sticky sessions.


You can balance secure traffic using either HTTPS or HTTP/2. Both protocols can be configured with:

  • SSL termination, which handles the SSL decryption at the load balancer after you add your SSL certificate and private key. Your load balancer can also act as a gateway between HTTP/2 client traffic and HTTP/1.0 or HTTP/1.1 backend applications this way.

  • SSL passthrough, which forwards encrypted traffic to your backend Droplets. This is a good for end-to-end encryption and distributing the SSL decryption overhead, but you’ll need to manage the SSL certificates yourself.

You can configure load balancers to redirect HTTP traffic on port 80 to HTTPS or HTTP/2 on port 443. This way, the load balancer can listen for traffic on both ports but redirect unencrypted traffic for better security.

TCP Balancing

TCP balancing is available for applications that do not speak HTTP. For example, deploying a load balancer in front of a database cluster like Galera would allow you to spread requests across all available machines.


UDP balancing is available for applications that require more time-sensitive transmission, such as live broadcasts. Forwarding rules using UDP require you to set both the entry and target protocols to UDP. When using UDP, the load balancer requires that you set up a health check with a port that uses TCP, HTTP, or HTTPS to work properly.

Because UDP is a stateless protocol, the load balancer maintains its own session state in order to route return traffic from Droplets back to the client. The load balancer triggers a session timeout when it hasn’t detected any sending or receiving traffic for one minute.

When using UDP, the load balancer assigns incoming connections to healthy target Droplets using the source IP of the client. This means that all subsequent requests from the same client land on the same target Droplet. If a target Droplet becomes unhealthy or you add or remove target Droplets, the load balancer assigns clients to new target Droplets.

WebSocket Support

DigitalOcean Load Balancers support the WebSocket protocol without any additional configuration.

When using WebSockets, the load balancer uses a special one hour inactivity timeout instead of the default 60 second timeout.

The following forwarding rule configurations support WebSockets:

  • TCP
  • HTTP to HTTP
  • HTTPS to HTTPS (both with a certificate and passthrough)
  • HTTP/2 to HTTP
  • HTTP/2 to HTTP/2 (both with a certificate and passthrough)

You can use WebSockets with or without backend keepalive enabled.

We test our load balancers against the industry standard Autobahn testsuite for all configurations.

Let’s Encrypt SSL Certificates

DigitalOcean Load Balancer Let’s Encrypt certificates are fully managed and automatically renewed on your behalf every 60 days. You can use SSL certificates with HTTPS and HTTP/2.

PROXY Protocol

PROXY protocol is a way to send client connection information (like origin IP addresses and port numbers) to the final backend server rather than discarding it at the load balancer. This information can be helpful for use cases like analyzing traffic logs or changing application functionality based on geographical IP.

DigitalOcean Load Balancers have support for PROXY protocol version 1. Configure your backend services to accept PROXY protocol headers after you enable it on your load balancer.


  • 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-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.

  • 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 floating 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.

Let’s Encrypt

  • 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:

    • 20 certificates per registered domain per week
    • 100 names per certificate
    • 5 duplicate domain certificates per week

    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.

Latest Updates

Upcoming Changes

  • Starting 1 July 2022, some of our pricing is changing. These changes will go into effect for the July bill which customers wlil receive in the 1 August invoice.

    • We are introducing a new $4 Droplet with 512MB memory, 10GB SSD Disk, 1 vCPU and 500GB of outbound data transfer.

    • We are simplifying pricing for DigitalOcean Kubernetes and some Managed Databases for better accuracy and predictibility.

    • Droplets, Snapshots, Load Balancers, Floating IPs, and Custom Images are increasing in price.

    There is no change to pricing for Spaces, backups, volumes, DigitalOcean Container Registry, or App Platform. There are also no changes to inbound data transfer or bandwidth pricing.

    This is our first major price change in 10 years, and we believe the new model better fits our understanding of our customers and the expanded breadth of our offerings. For a more detailed breakdown of the changes, see our blog post on our new pricing.

15 April 2022

19 January 2022

  • Managed Let’s Encrypt certificates will begin using Elliptic Curve Digital Signature Algorithm (ECDSA) instead of RSA. ECDSA is equally secure and more computationally efficient than RSA. ECDSA certificates follow the shorter root chain and aren’t rooted using the DST Root CA X3 cross-sign which expired on 30 September 2021.

    As we roll out this change, new Let’s Encrypt certificates provisioned for DigitalOcean Load Balancers and Spaces will increasingly use ECDSA and existing certificiates secured with RSA will be secured with ECDSA upon auto-renewal. This change doesn’t require any action from DigitalOcean customers.

10 January 2022

  • You can now resize load balancers once per minute, instead of once per hour. The cost is prorated based on how long the load balancer operates at each size, with a minimum charge of $0.01.

For more information, see all Load Balancers release notes.