Hetzner Load Balancer

What Hetzner Load Balancer actually is

Hetzner Cloud Load Balancers are managed Layer 4/7 traffic distributors that live inside Hetzner Cloud and route to Hetzner targets — cloud servers and dedicated root servers alike. That last point is the one we find most useful in practice: you can front a mixed estate of virtual machines and bare metal with a single managed entry point, over public or private IPv4 addresses, without running your own HAProxy pair. Our database row claimed billing is "pay only for traffic processed" and that the balancing algorithms include IP-hash; neither is true. Billing is per running load balancer (hourly, capped monthly), and the algorithm choice is Round Robin or Least Connections — two options, documented as such.

The feature set is deliberately compact. Services speak TCP plus HTTP/HTTPS, with HTTP/2 by default where clients support it. HTTPS services terminate TLS at the load balancer (using uploaded or Hetzner-managed certificates) and talk plain HTTP to the targets; if you want end-to-end TLS you configure a TCP service and terminate at the backend yourself. HTTP-level features include cookie-based sticky sessions (default cookie HCLBSTICKY, 300-second lifetime), automatic HTTP-to-HTTPS redirection, and proxy protocol support for passing client IPs to backends. Health checks are per-service and per-target: HTTP, HTTPS, or TCP probes with configurable port, interval, timeout, retries, expected response body, TLS verification, and expected status codes; unhealthy targets drop out of rotation automatically.

Operationally it behaves like the rest of Hetzner Cloud: create in seconds from the console, API, CLI, or Terraform, reconfigure almost instantly, and label and organize resources like any other cloud object. There is a first-party Terraform provider and Kubernetes cloud-controller integration, which is what makes the "auto-scaling integration" claim in our database half-right: scaling is not a load balancer feature, but the API and Kubernetes integration make automated target management practical.

Pricing: what you really pay

Three plans, published prices, no negotiation, VAT excluded. LB11 costs €7.49/month (€0.0120/hour) and includes 5 services, 25 targets, 10 SSL certificates, and 20 TB of traffic in EU locations (1 TB at US and Singapore locations). LB21 is €21.49/month (€0.0344/hour) with 15 services, 75 targets, 25 certificates, and 2 TB (US/SIN) to 20 TB (EU) traffic. LB31 tops out at €42.99/month (€0.0689/hour) with 30 services, 150 targets, 50 certificates, and 3 TB (US/SIN) to 20 TB (EU) traffic. A Primary IPv4 address is included in the load balancer price; each LB also gets a public IPv6 address and, when attached to a private network, a private IPv4.

Hourly billing with a monthly cap means a load balancer spun up for a launch week costs cents per day, and deleting it stops the meter — Hetzner bills for existence, not for bytes. Traffic beyond the included allocation is billed at the standard overage rate (Hetzner's documented excess rate for cloud and load balancer products is €1.00/TB for outgoing traffic).

Two things about the money. First, the entry price rose materially in spring 2026 — third-party trackers list the LB11 at €5.39/month earlier in the year before the €7.49 figure took effect — so older comparisons in forum threads are stale. Second, and more important: at €7.49/month the LB11 is still among the cheapest managed load balancers with a real feature set anywhere, and it is dramatically cheaper than hyperscaler equivalents (AWS's cheapest ALB alone costs several times that before counting LCU charges). For the load balancer category, the price floor is the headline.

Performance & infrastructure

Hetzner publishes no throughput numbers per plan — its docs say performance "depends on configuration and workload," which is honest but unhelpful for capacity planning. What we can say from the architecture: the load balancers run on Hetzner's own network (50.12 Tbit/s total bandwidth, redundant Juniper routing), TLS termination happens on the LB tier so backends save that CPU, and the six available locations cover three network zones — Falkenstein, Nuremberg, Helsinki (eu-central), Ashburn (us-east), Hillsboro (us-west), Singapore (ap-southeast). Load balancers are location-bound to their zone, so multi-region setups need one LB per zone plus DNS steering.

Targets are flexible within Hetzner's walls: public or private IPv4 of cloud servers and dedicated root servers, with private networks acting as the backplane so the LB can be the only internet-facing node. The health-check machinery is thorough enough for production (HTTP checks against a /healthz path with expected body and status codes, retries before eviction), and configuration changes propagate in seconds — faster than most managed LB services we track.

The reliability story is Hetzner's overall operational record rather than a contractual one. Each load balancer is a managed service without an SLA document of its own; Hetzner publishes min. 99.9% network availability for its data centers but no product-level uptime commitment or credit scheme for Cloud Load Balancers. For most buyers that is fine; if your business needs credits when the entry point dies, this is not your product.

Where it falls short

Feature depth is the honest gap against AWS ELB, Google Cloud Load Balancing, or Cloudflare. There is no IP-hash or weighted balancing, no WAF, no path-based routing across target groups (services are port-mapped, not L7-routed), no request logs at all — Hetzner states explicitly that load balancers do not log individual requests for privacy, performance, and cost reasons, so you instrument backends yourself — and no autoscaling built in. If you need canary routing, per-URL rules, or integrated bot management, you will be building that above Hetzner's layer.

Second, IPv6 asymmetry: every LB gets a public IPv6 address, but documented target IPs are IPv4 only (public or private). IPv6-only backends are not a documented target type. Combined with the fact that HTTPS services terminate TLS and forward plain HTTP, teams with strict end-to-end encryption requirements end up on TCP services and lose the HTTP features.

Third, the product is only a good deal inside Hetzner Cloud. It cannot front AWS instances, an on-prem rack, or a multi-cloud estate; the same lock-in that keeps prices low (targets are Hetzner Cloud servers and Robot dedicated servers) limits portability. And since each LB is single-location, resilient multi-region entry means buying several LBs plus external DNS failover — at which point the managed simplicity erodes.

Finally, a note on transparency: the docs are thin on performance characteristics, session limits, and DDoS behavior for load-balancer IPs specifically, and Hetzner's DDoS filtering is a network-level service rather than a per-LB feature you can configure. What you cannot see is what you cannot tune. One more practical note: because Hetzner bills for the load balancer's existence rather than its traffic, an idle LB in staging costs exactly as much as a production one under load. Delete parked load balancers instead of leaving them running — the hourly cap only helps when you actually delete the resource.

Who should pick this

We pick Hetzner Load Balancers whenever the backends already live in Hetzner Cloud or on Hetzner dedicated boxes and the job is straightforward: distribute HTTP(S) or TCP traffic with TLS termination, health checks, and sticky sessions across a handful to a few dozen targets. Typical wins are web apps behind two to five app servers, small Kubernetes clusters fronted by the cloud-controller integration, game and TCP services, and staging environments where per-hour billing matters. At €7.49/month the LB11 is our default recommendation in the load balancer category for European workloads.

We look elsewhere when you need L7 routing rules or a WAF, when backends span multiple clouds, when contractual uptime credits are a procurement requirement, or when you need detailed request logging at the edge. In those cases a Cloudflare or hyperscaler entry point in front of Hetzner origins is the pragmatic build — and Hetzner's included traffic allowances make the extra hop less painful than it sounds.

Key takeaways

• Managed L4/L7 traffic distribution from €7.49/month (LB11: 5 services, 25 targets, 10 certificates), hourly billing with a monthly cap; top plan LB31 is €42.99/month.
• Balancing algorithms are Round Robin and Least Connections only — no IP-hash or weighting, despite what our database previously claimed.
• Targets include both Hetzner Cloud servers and dedicated root servers over public or private IPv4; every LB gets public IPv4 (included in price) and public IPv6.
• Real HTTP feature set: TLS termination with managed certificates, sticky sessions, HTTP-to-HTTPS redirect, proxy protocol, configurable HTTP/HTTPS/TCP health checks.
• Six locations across four network zones (Falkenstein, Nuremberg, Helsinki, Ashburn, Hillsboro, Singapore); included traffic 20 TB in EU, 1–3 TB in US/Singapore.
• No request logs, no WAF, no autoscaling, no product-level SLA — great value inside Hetzner, the wrong edge for multi-cloud or compliance-heavy setups.

Sources

• https://www.hetzner.com/cloud/load-balancer/
• https://docs.hetzner.com/networking/load-balancers/overview/
• https://docs.hetzner.com/networking/load-balancers/faq
• https://docs.hetzner.com/robot/general/traffic/
• https://docs.hetzner.com/cloud/general/locations/
• https://github.com/hetznercloud/terraform-provider-hcloud/blob/main/docs/data-sources/load_balancer.md
• https://library.tf/providers/hetznercloud/hcloud/latest/docs/resources/load_balancer_service
• https://betterstack.com/community/guides/web-servers/hetzner-cloud-review