Load balancers

Updated 2026-10-30

A Wolkra load balancer spreads incoming traffic across several servers in Frankfurt, checks their health, and stops sending requests to any server that fails. It handles layer 4 (TCP) and HTTP traffic, and it can reach servers that have no public IP over a private network.

Why use a load balancer

One server is a single point of failure. With a load balancer in front of two or more servers you can:

• Stay online when a server crashes, reboots or is being patched
• Scale out by adding servers instead of moving to ever-bigger plans
• Release safely by taking servers out of rotation one at a time
• Keep app servers private, with only the balancer exposed to the internet

Features

• Layer 4 (TCP) balancing for any TCP service
• HTTP balancing for websites and APIs
• Health checks that remove failing targets and add them back when they recover
• Flexible targets: pick servers, use a label selector such as role=web so new servers join automatically, or add IP addresses
• Private network support: send traffic to private-only servers over a private network
• Unmetered traffic, like every Wolkra service, with fair use

How it works

1. You create a load balancer. It gets a public address.
2. You define services: which port it listens on and which port on the targets it forwards to, using TCP or HTTP.
3. You add targets: servers, a label selector or IPs.
4. You configure a health check, for example an HTTP request to /health every few seconds.
5. Clients connect to the balancer, which forwards each connection or request to a healthy target.

With a label selector, scaling is simply creating another server with the right label. The balancer picks it up, checks its health and starts sending it traffic.

In the console

Open Load balancers, choose Create, then add services, targets and a health check. The console shows the health of each target so you can see at a glance which servers are in rotation. Step-by-step instructions are in the load balancers doc.

Through the API

Load balancers, their services and targets can be managed with the Wolkra API. Deployment scripts can take a server out of rotation, update it and add it back. In Composer you can draw a load balancer in front of servers on a network and see the total monthly cost before you apply.

A typical setup

Use placement groups to spread the app servers across hosts, so a single host problem cannot take them all down.

Typical uses

• Web hosting and WordPress with more than one web server
• APIs and backends for SaaS startups
• Container stacks in Docker hosting
• TCP services such as game servers or message brokers

Health checks that work

A health check is only as good as the endpoint it calls. A few habits make it reliable:

• Use a dedicated path such as /health that answers fast and does not need a login.
• Let the check touch what really matters, for example a quick database ping, but keep it light.
• Return an error when the app cannot serve users, so the balancer takes the server out.
• During a deploy, fail the check on purpose before stopping the app, then let traffic drain.

Pricing basis

A load balancer is billed per started hour from your prepaid balance and capped at the monthly price. There are no per-GB or per-request fees. See the pricing page for the current price.

Limits to know

• Load balancers run in the same location as their targets. Today that is Frankfurt.
• Health checks decide what is in rotation, so make sure your app answers them quickly.
• Fair use applies to traffic, as described in the Acceptable Use Policy.

Related products

• Cloud servers as targets
• Private networks and firewalls
• Floating IPs for active/standby setups
• Network for bandwidth, IPv4 and IPv6

Put a load balancer in front

Make your service survive a failed server with a few clicks. Sign up for Wolkra and create a load balancer in Frankfurt.