Load Balancer

A Load Balancer is a dedicated server type that sits in front of your App Servers and distributes incoming traffic across them. Use one when a single App Server cannot handle your traffic, or when you need redundancy: if one App Server fails, the load balancer routes around it.

Creating a Load Balancer

1. In the Console, click Add Server.
2. Pick Load Balancer as the server type.
3. Pick a provider (Hetzner or Custom Setup) and continue with the standard provisioning flow.

Depfloy installs nginx and configures it for load-balancing use. The Load Balancer screen on the server view is where you point it at backends.

The Load Balancer screen

Open the server in the Console and switch to Load Balancer. You'll see three sections:

• Algorithm — how requests are distributed across backends
• Backends — the App Servers behind the load balancer
• Domains — the public hostnames the load balancer answers on

After any change in this screen, click Apply Configuration to push it to the running nginx and start sending traffic accordingly. Until you apply, changes are saved but not yet live — which makes it safe to stage several edits and apply them together during a maintenance window.

Backends

A backend is an App Server that the load balancer can send traffic to. Each backend has:

• Server — pick one of your existing App Servers from the dropdown.
• Port — the port the application listens on (80 is the default).
• Weight — how often this backend is chosen relative to the others. Use it to send more traffic to a beefier server, or less to a smaller one. Default is 1 (equal weighting).
• Max fails — how many failed health checks before the load balancer marks the backend as unhealthy and stops sending it traffic.
• Fail timeout — how long (in seconds) to wait before retrying an unhealthy backend.
• Backup — when ticked, the backend only receives traffic when every primary backend is down. Useful for cold-standby setups.

You can enable or disable a backend with one click — disabled backends stay in the list but stop receiving traffic on the next Apply.

Domains

Add the public hostnames the load balancer should answer on (app.example.com, www.example.com, and so on). Each domain you add gives the load balancer permission to terminate TLS for that hostname and route the request to a backend.

DNS for each domain should point at the load balancer's public IP, not at any individual backend.

Algorithms

Pick how requests are distributed:

• Round robin — the default. Each backend takes the next request in turn, weighted by the Weight value you set.
• Least connections — the backend with the fewest active connections gets the next request. Good for workloads where some requests are much slower than others.
• IP hash — the same client IP is consistently routed to the same backend. Useful when your application stores per-user state in memory rather than in shared storage.

The algorithm change does not take effect until you click Apply Configuration.

Apply Configuration

Changes you make on the Load Balancer screen are persisted to Depfloy but not yet active on the server. Clicking Apply Configuration rebuilds the nginx configuration on the load balancer and reloads it — there is no connection interruption, in-flight requests finish on the previous configuration and new requests pick up the new one.

You can apply as often as you like; reasonable workflow is to stage several edits and apply them together once you're happy.