Load balancers

Updated 2026-10-30

A Wolkra load balancer spreads incoming traffic across several servers and sends it only to targets that pass their health checks. It supports layer 4 (TCP) and HTTP services, and targets can be servers, label selectors or IP addresses, including servers that live only on a private network.

When you need one

• Two or more app servers for capacity or redundancy.
• Zero-downtime deploys: take one server out, update it, put it back.
• One stable public entry point in front of private servers.

Create a load balancer

1. Open Load balancers in the console and choose Create load balancer.
2. Name it, for example web-lb.
3. Optionally attach it to a private network, so it can reach private-only servers.
4. Add services (listening ports).
5. Add targets.
6. Configure health checks.
7. Create it. The console shows the price before you confirm.

Services

A service maps a port on the load balancer to a port on the targets.

Add one service per listening port.

Targets

• Servers: pick individual servers.
• Label selectors: for example role=web. New servers with the label join automatically, and servers that lose the label leave. This works well with servers you create from a snapshot or through the API.
• IP addresses: for backends identified by address.

When the load balancer is attached to a private network, it reaches targets over their private addresses, so the targets need no public IP at all.

Health checks

A health check decides whether a target receives traffic. Configure:

• Protocol: TCP (the port accepts connections) or HTTP (a path returns a success status).
• Port and, for HTTP, a path such as /healthz.
• Interval, timeout and retries.

A minimal health endpoint behind Caddy:

:8080 {
    respond /healthz "ok" 200
    reverse_proxy localhost:3000
}

Make the health check reflect real readiness. If the app needs a database, let /healthz fail when the database is down, so traffic moves to a healthy server.

HTTPS

For HTTPS, add a TCP service on port 443 and terminate TLS on the servers themselves, for example with Caddy. Each server then needs the certificate; Caddy can fetch it automatically, or you can share it between servers. Add a TCP or HTTP service on port 80 so certificate challenges and redirects reach the servers. The Caddy guide covers the server side, including trusting forwarded headers.

Firewalls

Allow the application port on the targets only from where the load balancer connects: the private network range if it is attached to one. Keep SSH restricted as usual. See firewalls.

Deploy without downtime

1. Remove the server's label (or the server) from the targets, or let it fail its health check on purpose.
2. Wait until existing connections finish.
3. Update and restart the app.
4. Restore the label and wait for the health check to pass.
5. Repeat for the next server.

Check that it works

for i in $(seq 1 6); do curl -s http://203.0.113.20/whoami; echo; done   # example address

If each server answers /whoami with its own hostname, you will see the responses alternate.

Billing

Load balancers are billed per started hour and capped at the monthly price, like servers. Traffic through them is unmetered. See pricing.

API

Load balancers are available at https://api.wolkra.com/v1/load_balancers. See API tokens.

More on the product page: load balancers.