Open Source Load Balancers
A load balancer is the one hop every request passes through, which makes it both the thing that decides who your service even is to the outside world and the riskiest place to hand control to an appliance you cannot inspect. When it misbehaves, the symptoms show up as application bugs - odd timeouts, dropped streams, requests that retry when they should not - so how it routes, terminates TLS, and spreads traffic across backends needs to be logic you can read rather than a black box at your front door. Open source load balancers and reverse proxies sit at that edge on infrastructure you operate, so the rules and the failure behavior are yours to test, version, and reason about under load.
Caddy
Web server that provisions and renews TLS certificates for you, then reverse-proxies and load-balances
NGINX
Event-driven web server and reverse proxy that load-balances HTTP and TCP/UDP, and caches content
MetalLB
Gives bare-metal Kubernetes the LoadBalancer Services that cloud clusters get for free
HAProxy
High-performance TCP and HTTP load balancer that fronts demanding sites at L4 and L7
Seesaw
Google's LVS-based L4 load balancer that runs as a redundant two-node cluster with a floating VIP
Katran
Meta's L4 load balancer that forwards packets inside the kernel with XDP and eBPF
Keepalived
VRRP failover and IPVS load balancing that keeps a Linux service alive when a node dies
gobetween
Minimalist L4 load balancer that discovers its own backends from Docker, Consul, SRV, and more
Our picks
These span the common edges, from an L4 and L7 workhorse to bare-metal Kubernetes and floating-IP failover.
L4 and L7 workhorse for busy sites: HAProxy Balances raw TCP at Layer 4 and inspects and routes HTTP at Layer 7, so one proxy covers database connections and web requests alike. It handles HTTP/2, HTTPS with TLS 1.3 termination, IPv6, FastCGI, and the PROXY protocol, with content caching and DDoS mitigation.
Reverse proxy with automatic HTTPS: Caddy Obtains and renews TLS certificates automatically over ACME, so a hostname in the config is enough to serve real HTTPS, with a managed local CA for internal names. The same binary reverse-proxies and load-balances across backends over HTTP/1.1, HTTP/2, and HTTP/3, driven by a readable Caddyfile or a live JSON API. It removes certificate handling as a source of outages.
LoadBalancer services on bare-metal Kubernetes: MetalLB Fills the gap where a bare-metal or on-prem cluster has no cloud to provision external load balancers, so type LoadBalancer services no longer sit pending forever. It hands out reachable IPs and announces them with ARP in Layer 2 mode or by peering with your routers over BGP. It runs inside the cluster and integrates with FRR.
L4 balancing with VRRP failover: Keepalived Drives the kernel IPVS module for Layer 4 load balancing and speaks VRRP so a floating virtual IP moves to a standby node the instant the active one fails. Health checkers prune dead backends automatically, and BFD detects link failure fast enough to fail over before clients notice.
Choosing between Layer 4 and Layer 7
The layer you need to control shapes everything else. Layer 4 balancers move raw TCP and UDP by hashing connections to backends, which keeps them fast and protocol-agnostic: Katran forwards packets in the kernel with XDP and eBPF for very high volume, Seesaw and Keepalived pair Linux Virtual Server balancing with floating-IP failover, and gobetween discovers its backends from Docker, Consul, or SRV records. Layer 7 balancers understand HTTP, gRPC, headers, paths, and cookies, which is more powerful but makes them part of your application contract. Caddy and NGINX front web stacks at Layer 7, while HAProxy works at both layers, so decide where TLS ends and whether you need pass-through before comparing anything else.
Look at the control plane, not just the packet path. Some of these are configured through static files and predictable reloads, and others expect an API, service discovery, or a cluster scheduler to feed them changing backends. In Kubernetes the model matters most: MetalLB exists specifically to give bare-metal clusters the LoadBalancer services that cloud clusters get for free, announcing addresses over ARP or by peering with routers over BGP. Check how health checks, connection draining, and canary routing are represented, and whether a reload drops live connections - acceptable for internal batch traffic, not for a public API.
Treat failure behavior and observability as selection criteria, not afterthoughts. Ask what happens when a node dies, a backend flaps, or a certificate expires, and confirm you get metrics for connection rates, retries, upstream latency, and TLS errors. Caddy provisions and renews certificates automatically, which removes one common outage, but whatever you pick, keep the configuration portable so replacing it later is not a redesign of every service at once.
Related categories
Frequently asked questions
What is the difference between a Layer 4 and Layer 7 load balancer?+
Layer 4 balancers route connections by IP address and port, so they work for any TCP or UDP service without understanding the application; Katran, Seesaw, Keepalived, and gobetween all operate here. Layer 7 balancers inspect protocols like HTTP and can route by host, path, header, or cookie, which Caddy and NGINX do. Layer 7 gives more control but adds parsing, retry, and timeout decisions that affect application behavior. HAProxy does both.
Should TLS terminate at the load balancer or pass through to the backend?+
Terminate at the load balancer when you need centralized certificates, HTTP routing, or request-level policy - HAProxy and Caddy both handle TLS termination, and Caddy automates certificate issuance and renewal over ACME. Use pass-through when backends must see the original TLS session or client certificates; L4 tools like gobetween support that. A common middle ground is terminating at the edge and re-encrypting to upstreams. Test SNI, rotation, and any mTLS requirements rather than assuming them.
How do I keep the load balancer from being a single point of failure?+
Run at least two nodes with a failover mechanism in front. Keepalived and Seesaw are built for this: they move a floating virtual IP to a standby node the moment the active one fails, and Keepalived adds fast BFD link-failure detection. In Kubernetes, MetalLB in Layer 2 mode fails an address over on node loss. Then test node loss under real traffic, because config distribution and stateful features also have to survive failover.
Which of these work with Kubernetes?+
MetalLB is purpose-built for it, giving bare-metal and on-prem clusters the type LoadBalancer services that managed clouds provision automatically, announced over ARP or BGP. Others sit outside the cluster and treat nodes or ingress endpoints as backends. If the load balancer is part of the cluster lifecycle, favor something that reads Kubernetes objects; if it is a separate network tier owned by platform operations, a standalone proxy like HAProxy or NGINX can front the cluster.
Do I need a separate tool for automatic HTTPS?+
Not if the proxy handles it. Caddy obtains and renews TLS certificates automatically over ACME, using public CAs for public names and a managed local CA for internal names and IPs, so a single hostname in the config is enough to serve HTTPS. gobetween also supports ACME certificates alongside TLS termination and pass-through. With NGINX or HAProxy you typically pair an external ACME client, so certificate automation is one thing worth checking up front.
How do these handle WebSocket, gRPC, and long-lived connections?+
They need protocol-aware timeouts and connection handling. WebSocket and gRPC streams stay open far longer than normal HTTP requests, so idle timeouts, maximum connection age, backend draining, and retry behavior all matter. A retry that is safe for a short idempotent request can be wrong for a stream. Layer 7 proxies like HAProxy, NGINX, and Caddy support these protocols, but test deployments and backend restarts with long-lived clients connected, not just fresh requests.
What should I benchmark before choosing one?+
Benchmark the traffic shape you actually run, not a generic requests-per-second figure. Test concurrent connections, keep-alive behavior, TLS handshakes, large uploads, slow clients, and WebSocket or gRPC streams, plus backend failure. Measure latency percentiles, CPU, and memory growth, and the impact of a config reload. A proxy that looks fast on short HTTP requests can behave very differently with long-lived connections or expensive TLS settings, so use realistic rule counts.