Load balancers
Route service traffic to healthy droplet backends.
Load balancers expose listeners and route connections to healthy backends on a private network. A load balancer belongs to one project, region, and network.
Create a load balancer
Choose Networking → Load balancers → Create. Select an internal or public endpoint, its network, listener protocol, and backend group. Public endpoints require an available public address and the corresponding quota.
Choose the listener protocol for the application traffic and TLS boundary:
| Option | Type | Default | Behavior |
|---|---|---|---|
| Exposure | Enum | Internal | Internal or public |
| Listener | Protocol and port | Required | TCP, HTTP, or HTTPS on an available port |
| Backend port | Integer | Required | Inclusive range 1–65535 |
| Algorithm | Enum | Round robin | Round robin or least connections |
| Health interval | Integer seconds | 10 | Inclusive range 5–300 |
| Health timeout | Integer seconds | 3 | Inclusive range 1–30; must be below the interval |
| Unhealthy threshold | Integer checks | 3 | Inclusive range 1–10 |
| Healthy threshold | Integer checks | 2 | Inclusive range 1–10 |
Invalid ports, timing combinations, and unsupported protocol options are rejected. TLS listeners require a valid certificate reference and expose desired versus active certificate revisions. TCP forwarding does not terminate or inspect application TLS.
Configure health checks
For HTTP services, use a path that reports whether the backend can accept real
requests. The default success range is HTTP 200–399; configure a narrower
range when redirects should indicate failure. TCP checks verify connection
acceptance and do not establish application correctness.
Health probes use the load balancer's network identity. Permit both probes and service traffic in the backend firewall. A private address that is reachable from an operator's machine can still be unreachable from the balancer.
Backend membership
Add explicit droplet IDs or select droplets by labels. Backends must be reachable through the selected network. A new backend starts receiving traffic after registration and the configured healthy threshold.
Removing a backend enters connection draining. New connections stop after the configuration is applied; existing connections can continue until the drain timeout. Connections still active at timeout can be closed. Coordinate long-lived sessions with application shutdown rather than assuming drain will finish them.
No healthy backends
When all backends are unhealthy, HTTP and HTTPS listeners return a service unavailable response. TCP listeners do not establish a usable backend connection. The balancer does not route to an unhealthy backend as a fallback.
Inspect probe results, firewall rules, backend listeners, and application readiness. A migration or guest restart can create transient failures; use enough independent replicas for the application's availability requirement.
Certificates and updates
Reference certificates through Secrets. Renew a certificate before expiry and verify the applied revision. Listener, certificate, and backend updates are asynchronous operations. The details page shows pending and active configuration separately.
Before deleting a balancer, remove DNS references and drain client traffic. Review whether its public address is retained or released. Backend droplets and their volumes remain independent resources.
Listener protocols and client identity documents HTTP forwarding headers, TCP pass-through, PROXY protocol, and backend trust boundaries.