Open source load balancers compared, HAProxy and more

"Load balancer" covers a large range, from a few lines of Nginx to a service mesh. This guide compares five open source tools that people actually run in front of web servers in 2026, and says when each fits. Facts come from each project's own pages, read on 30 October 2026.

The five at a glance

Licences come from each project's own licence file. Active health checks mean the balancer probes servers itself, instead of waiting for a real request to fail. Where the table says Plus, the feature needs NGINX Plus, F5's paid product.

Layer 4 or Layer 7

A Layer 4 balancer passes TCP or UDP connections along without reading them. It is fast, simple and right for databases, mail and anything that is not HTTP. A Layer 7 balancer reads the request, so it can send /api to one group and the rest to another, add headers, terminate TLS and keep a user on the same server. Most web setups want Layer 7, with Layer 4 for the odd extra service.

HAProxy

HAProxy does one job, and is known for it. It handles TCP and HTTP, has active and passive health checks, many balancing algorithms, stick tables for sessions and rate limits, and a statistics page described in its management guide. The project page lists 3.4 as a long term support branch, released 3 June 2026 with end of life planned in 2031 Q2, and 3.2 as another with end of life in 2030 Q2 (as of 30 October 2026).

The licence matters if you ship it inside a product: the core is GPL, and the project's LICENSE file explains that the exported include files are LGPL. HAProxy Technologies also sells HAProxy Enterprise; check its page for what it adds. The community version is complete as a load balancer. The cost is the configuration language, which takes a day to learn and is then very precise.

Nginx

Most servers already run Nginx, so it is the lowest effort: an upstream block with servers, least_conn or ip_hash, and proxy_pass. The HTTP load balancing guide covers it, and TCP and UDP balancing is available through the stream module. The catch is where the free version stops. The health check guide says passive checks work in NGINX Open Source or NGINX Plus, while active health checks and the live activity dashboard need NGINX Plus. The session persistence section says the same for cookie based sticky; Open Source uses hash or ip_hash instead. For a small pool that is often enough.

Traefik

Traefik is built for changing environments: it watches Docker, Kubernetes and files and updates routes by itself, and can request certificates automatically. Its routing reference lists several strategies, health checks and sticky sessions with cookie settings. It is MIT licensed. It fits containers best; for a few fixed servers its model is more than you need.

Envoy

Envoy is a proxy built for service meshes and large platforms. Its load balancing documentation lists weighted round robin, weighted least request, ring hash, Maglev and random, with active health checking per cluster, and the home page shows 1.40.2 as the current release. It is the most capable of the five and the heaviest to configure by hand, which is why it usually sits under a control plane. Pick it when you need that depth, not to balance two web servers.

Caddy

Caddy is the easiest to start: a three line Caddyfile gives you a reverse proxy with automatic HTTPS. The reverse_proxy directive has lb_policy, retry settings, a list of active health check options and a cookie policy for sticky sessions. It is Apache 2.0 licensed. It suits small and medium sites; the configuration tools for fleets are thinner than HAProxy's.

What about a GUI

Searches for "open source load balancer with GUI" are common, and the honest answer is that none of these five ships a full configuration screen. HAProxy has a statistics page, Traefik a dashboard to inspect routes, and Envoy an admin interface. They show state; you still configure by text. If you want point and click, you use a panel that writes the configuration for you. RespireCloud does that for HAProxy only, with a preview first, see load balancers.

Health checks, TLS and sticky sessions

• Health checks. Prefer active checks, with a path that proves the application works, not just that the port opens. With passive checks only, real visitors discover a dead server first.
• TLS. Decide where it ends. Terminating at the balancer means one place to renew certificates and plain traffic inside your network; encrypting to the backend too costs CPU and adds certificate work, but protects traffic if the network is shared.
• Sticky sessions. Avoid them if you can, by keeping sessions in a shared store. If not, use a cookie, and know that a stuck user returns to the server they had, which can unbalance the pool.

Which one should you pick

• Two web servers and Nginx already. Add an upstream block. Move on when you need active health checks.
• A pool of VMs with real uptime needs. HAProxy.
• Docker or Kubernetes, with routes that change. Traefik.
• A platform with many services and a control plane. Envoy.
• A few sites and automatic HTTPS first. Caddy.
• All servers at one cloud, basic needs. The provider's balancer is simpler, and you have nothing to patch.

Whatever you choose, a single balancer is a single point of failure. Put two behind a floating address, and read how pools can grow with traffic in autoscaling that follows your traffic.