unsubbed.co

HAProxy

For proxy servers, HAProxy is a self-hosted solution that provides very fast and reliable reverse-proxy offering high availability.

Infrastructure-level reverse proxy and load balancer, honestly reviewed. No marketing fluff — just what you get when you self-host it.

TL;DR

  • What it is: Free, open-source (GPL 2) reverse proxy and load balancer that handles TCP, UDP, QUIC, and HTTP traffic. The project claims over one billion downloads on Docker Hub and G2 category leadership in load balancing, API management, DDoS protection, and container networking [1].
  • Who it’s for: DevOps engineers, infrastructure teams, and technically fluent founders running multi-server setups who need high-availability traffic routing without paying for cloud-native load balancers. Not a tool for non-technical founders to configure themselves.
  • Cost savings: Cloud load balancers (AWS ALB, Cloudflare Load Balancing) run $16–$50+/month depending on traffic volume. HAProxy Community Edition is free software — your only cost is the server it runs on.
  • Key strength: Battle-hardened performance. It’s genuinely what large-scale companies run in production. Configuration is highly programmable via ACLs and Lua scripting [2].
  • Key weakness: The configuration is a text file with a steep learning curve. There is no web UI in the community edition. Non-technical users will struggle. HAProxy Enterprise adds commercial features (WAF, bot management, OIDC, API gateway) but pricing is not publicly listed [1][2].

What is HAProxy

HAProxy is a reverse proxy and load balancer. It sits in front of your servers, accepts incoming connections — HTTP, HTTPS, TCP, or raw UDP — and routes them to a pool of backend servers according to rules you define. It handles health checks (stops sending traffic to a dead server automatically), TLS termination, session persistence, and rate limiting, all in a single binary with no runtime dependencies [2].

The project has been active since 2001, making it older than most of the SaaS tools it competes with. The GitHub mirror sits at 6,407 stars, but that number undersells its adoption — the actual canonical repository is hosted at git.haproxy.org, not GitHub. The Docker Hub download count of over one billion is the more meaningful signal [1].

HAProxy ships in two editions. The Community Edition is GPL 2 licensed — free to use, free to self-host, no commercial agreement required. The Enterprise Edition (HAPEE) is a commercial product from HAProxy Technologies LLC that adds a next-generation WAF, bot management, OIDC authentication, an API/AI gateway, and Kubernetes-native ingress capabilities [1][2]. The commercial edition is sold as a paid subscription; pricing is not published publicly.

The current stable release is HAProxy 3.3 as of this writing. HAProxy 3.0, released in 2024, introduced major changes including a new certificate store configuration section, JSON and CBOR log formatting, stats persistence across reloads, and improved HTTP/2 glitch detection [1].


Why people choose it

The case for HAProxy over alternatives consistently comes down to three things: performance, reliability, and zero licensing cost.

Versus cloud load balancers (AWS ALB, Cloudflare, GCP LB). Cloud-native load balancers are easier to set up but charge you per connection-hour, per LCU, or per health check query. At any meaningful scale — say, a busy SaaS with multiple backend pods — those bills grow predictably and never shrink. HAProxy runs on a VPS you already pay for, and it doesn’t care how many requests it processes [2].

Versus nginx as a load balancer. nginx can load balance but it’s primarily a web server with load balancing bolted on. HAProxy is a load balancer first, with proxying as the mechanism. The practical difference shows up in health check granularity, backend weighting algorithms, and the stats/management API that gives you real-time visibility into connection state [2].

Versus Traefik. Traefik is the modern, Docker-native alternative with automatic service discovery and a web dashboard. Traefik wins on ease of configuration (YAML instead of haproxy.cfg syntax, dynamic reconfiguration without reloads). HAProxy wins on raw throughput, stability, and the breadth of its ACL language for traffic manipulation. Engineering teams running very high request volumes generally choose HAProxy. Teams running Kubernetes or Docker Swarm who want low-friction configuration often prefer Traefik [4].

Versus Caddy. Caddy is the easiest reverse proxy to operate — automatic HTTPS, simple Caddyfile syntax, no manual certificate management. But Caddy is not a load balancer in the HAProxy sense. For routing to a farm of backend services with weighted algorithms, session stickiness, and granular health checks, HAProxy is in a different class.

The HAProxy blog documents Docker Swarm integration [4] and Kubernetes deployment patterns, which signals the team’s understanding of where HAProxy actually gets deployed: as the edge layer of a container cluster, not as a standalone appliance.


Features

Based on the official documentation, release notes, and the configuration guide [1][2]:

Core load balancing:

  • Multiple balancing algorithms: round-robin, least connections, source IP hash, URI hash, random, sticky tables [2]
  • Layer 4 (TCP) and Layer 7 (HTTP) load balancing in the same tool [2]
  • Active and passive health checks — marks backends down automatically and recovers them [2]
  • Weighted server pools with slow-start for bringing new servers online gracefully [2]
  • Session persistence (sticky sessions) via cookies or stick tables [2]

Traffic handling:

  • TLS termination with SNI routing — one HAProxy can front dozens of domains [2]
  • HTTP/2 end-to-end, including gRPC support [4]
  • QUIC support (added in 3.x line) [1]
  • ACL-based routing: route traffic to different backends based on URL path, headers, cookies, client IP, or custom Lua logic [2]
  • Rate limiting and connection throttling at L4 and L7 [2]
  • Compression, caching headers, and HTTP header manipulation [2]

Observability:

  • Built-in stats page — a live HTML dashboard showing connection rates, error rates, and server health [2]
  • Prometheus metrics endpoint for Grafana integration [4]
  • Structured logging, now including JSON and CBOR formats as of HAProxy 3.0 [1]
  • Stats persistence across reloads (HAProxy 3.0) — the stats page no longer resets on config reload if GUIDs are set [1]

Operations:

  • Zero-downtime config reloads via socket-based Runtime API [1]
  • Lua scripting for custom logic without recompiling [README]
  • SPOE (Stream Processing Offload Engine) for offloading decisions to external agents [README]
  • Multi-threaded architecture that scales across CPU cores [README]
  • Runs on Linux, FreeBSD, NetBSD, and Solaris; CI covers musl/Alpine, AWS-LC, and Illumos [README]

Enterprise only (HAPEE):

  • Next-generation WAF [1][2]
  • Bot management module [2]
  • OIDC authentication [1]
  • API and AI gateway capabilities [1]
  • Global rate limiting across distributed instances [2]
  • Kubernetes application routing and ingress controller [1][2]

Pricing: SaaS vs self-hosted math

HAProxy Community Edition: $0. GPL 2 license. Compile from source, install from your distro’s package manager, or run the official Docker image.

HAProxy Enterprise: Commercial subscription. Pricing is not published — you contact their sales team. This is standard for enterprise infrastructure software but worth flagging: you cannot self-serve a trial or get a number without a sales call [1][2].

Cloud load balancer costs for comparison:

AWS Application Load Balancer charges per Load Balancer Capacity Unit (LCU) — a composite of new connections, active connections, processed bytes, and rule evaluations. A moderately busy application can easily run $20–$50/month on ALB, scaling higher with traffic. Cloudflare Load Balancing starts at $5/month for two origin servers plus $0.50 per additional origin and separate charges for health check queries. GCP Cloud Load Balancing bills per forwarding rule plus per processed GB.

Self-hosted HAProxy math:

  • Software: $0
  • Server to run it: $4–6/month on Hetzner or Contabo (HAProxy is lightweight — a 1-core, 2GB RAM VPS handles substantial traffic)
  • For true high availability, you run two instances with Keepalived for failover: $8–12/month total

Over a year: AWS ALB at $30/month average = $360. Self-hosted HAProxy pair = ~$100. That’s the math, and it compounds — cloud load balancer costs grow with traffic, HAProxy costs don’t.

Caveat: this assumes you have someone technical who can configure and maintain it. If you’re paying a DevOps engineer to set it up, their time costs real money. Budget two to four hours for initial configuration on a non-trivial setup.


Deployment reality check

HAProxy is not a point-and-click install. Configuration lives in a text file (/etc/haproxy/haproxy.cfg) with its own syntax. There is no web GUI in the Community Edition [2]. The stats page gives you read-only visibility; all changes require editing the config file and triggering a reload.

What you actually need:

  • A Linux server (Debian/Ubuntu are best-supported via the official HAProxy PPA)
  • A static IP or floating IP if you want HA
  • Working knowledge of networking concepts: frontends, backends, ACLs, health check URIs
  • For HTTPS: a certificate and understanding of how to configure TLS on the bind line
  • For high availability: a second server and Keepalived for virtual IP failover — this is not included in HAProxy itself

What can go sideways:

  • Configuration errors bring down your traffic routing. Unlike Nginx where a syntax error just blocks the reload, a misconfigured HAProxy can drop connections. Always validate with haproxy -c -f haproxy.cfg before reloading.
  • The stats page is read-only. You cannot drain a server, change weights, or disable a backend from the UI — you edit the config and reload, or use the Runtime API via socket. Neither is beginner-friendly.
  • The ACL language is expressive but arcane. Matching traffic on custom headers, rewriting paths, and chaining conditions requires careful reading of the 900-page configuration reference. This is not hyperbole — the HAProxy configuration reference is genuinely that long [README].
  • High availability requires external tooling. HAProxy itself doesn’t do active-active failover. That’s Keepalived’s job. Running a single HAProxy instance is a single point of failure, which defeats part of the purpose [2].
  • The Docker Swarm integration requires additional DNS configuration for service discovery — HAProxy doesn’t automatically detect new containers the way Traefik does [4].

Realistic setup time: one to two hours for a technically fluent engineer who’s read the docs. Half a day if you’re doing it for the first time on a real multi-server setup. For HA with Keepalived, add another two to three hours.


Pros and Cons

Pros

  • Twenty-plus years of production hardening. HAProxy runs at GitHub, Reddit, Twitter scale. When the community edition says “battle-tested,” it means it [1].
  • Zero software cost. GPL 2 license, no seats, no nodes, no task limits. Install it on as many servers as you want [README].
  • Comprehensive Layer 7 traffic manipulation. ACLs let you route, rewrite, rate-limit, and reject based on virtually any aspect of the HTTP request [2].
  • Mature stats and observability. Built-in stats page plus Prometheus metrics out of the box. Structured JSON logging added in 3.0 [1][4].
  • Extremely low resource footprint. Handles tens of thousands of concurrent connections on modest hardware [1].
  • Active development. HAProxy 3.0 in 2024 brought meaningful new features (stats persistence, GUID-based tracking, QUIC improvements, HTTP/2 glitch detection) — this is not abandonware [1].
  • Strong community. Discourse forum, mailing list, Slack, and IRC — multiple official channels, active maintainers [README].

Cons

  • No web UI in the Community Edition. All configuration is text files. Intimidating for anyone who hasn’t run infrastructure before.
  • The configuration syntax is dense. The reference manual is enormous. Simple things are simple; complex things require real study [2][README].
  • High availability requires Keepalived (external). HAProxy does not self-cluster. You build HA yourself [2].
  • Enterprise features — WAF, bot management, OIDC, AI gateway — are commercial-only. If you need those, you’re buying HAPEE with an unlisted price [1][2].
  • GitHub star count (6,407) is misleading. The real development happens at git.haproxy.org; GitHub is a mirror. The actual adoption dwarfs the star count, but the low number can make the project look less active than it is.
  • Not appropriate for non-technical users. This is not a product you hand to a marketing team. If you want a load balancer with a UI, look elsewhere.
  • Docker Swarm integration requires DNS service discovery setup — not as automatic as Traefik’s native Docker integration [4].

Who should use this / who shouldn’t

Use HAProxy if:

  • You’re an engineering team or technically capable founder running multiple backend servers and paying for cloud load balancers you’d rather not.
  • You need Layer 7 traffic manipulation — routing based on URL paths, headers, or cookies across different backends.
  • You’re building a high-availability setup and understand (or are willing to learn) Keepalived for virtual IP failover.
  • You want a load balancer that scales from a two-server setup to GitHub-level traffic without changing tools.
  • You’re already running Docker Swarm or bare-metal servers and need battle-proven edge routing [4].

Skip it and use Traefik if:

  • You’re running containers (Docker or Kubernetes) and want automatic service discovery without manually editing a config file every time a service changes.
  • You want a dashboard that lets you see and manage backends without touching config files.
  • Your team is not comfortable with a 900-page configuration reference.

Skip it and use Caddy if:

  • You need a simple reverse proxy with automatic HTTPS and are routing to one or two backends.
  • You’re a solo founder who wants “point it at my app server and get HTTPS” without learning load balancer concepts.

Skip it and use a cloud load balancer if:

  • You have no one technical who can own the infrastructure.
  • Your compliance requirements mandate managed-service infrastructure with SLA guarantees.
  • You’re early-stage and the $20–50/month AWS ALB cost is trivially small compared to your engineering time.

Alternatives worth considering

  • Traefik — Docker-native, automatic service discovery, web dashboard, automatic HTTPS via Let’s Encrypt. Easier than HAProxy; less raw throughput and less flexible ACL language. The choice for most Kubernetes and Docker Swarm setups.
  • Caddy — Simplest reverse proxy with automatic HTTPS. Not a load balancer in the HAProxy sense, but handles most single-app setups with zero configuration friction.
  • nginx — Web server that also load balances. Broader documentation ecosystem and familiarity. The upstream block is simpler than HAProxy’s frontend/backend model for basic use cases.
  • Envoy — Google-origin L7 proxy used as the data plane in Kubernetes service meshes (Istio). More complex than HAProxy; designed for microservices-to-microservices traffic, not edge load balancing.
  • AWS ALB / Cloudflare Load Balancing / GCP Cloud LB — Managed alternatives. No maintenance, SLA-backed, priced per usage. The obvious choice if you don’t want to run infrastructure.
  • Pingora (Cloudflare, open source) — Rust-based proxy from Cloudflare. Newer, less mature than HAProxy, but gaining traction for teams that want a modern codebase.

Bottom line

HAProxy is infrastructure, not software. It doesn’t have a marketing site that explains what it does in friendly language because its audience already knows. It is the load balancer that companies reach for when performance and reliability are non-negotiable and the software licensing bill needs to be zero. For engineering teams already running their own servers, the self-hosted math is straightforward: your cloud load balancer bill disappears, replaced by a config file on a VPS that costs less per month than a Netflix subscription.

The honest caveat: this is not a tool for non-technical founders to self-deploy on a Saturday afternoon. The configuration is powerful precisely because it’s detailed, and detailed means learning time. If you want the infrastructure savings without the setup work, that’s exactly what upready.dev deploys for clients — you get HAProxy running in front of your servers, configured correctly, with high availability, without spending your weekends reading the configuration reference.


Sources

  1. HAProxy Blog — “Announcing HAProxy 3.0” (haproxy.com). https://www.haproxy.com/blog/announcing-haproxy-3-0
  2. HAProxy Blog — “HAProxy Load Balancer Configuration Basics: Step-by-Step” (haproxy.com). https://www.haproxy.com/blog/haproxy-configuration-basics-load-balance-your-servers
  3. HAProxy Legal — “HAProxy Trademark Policy” (haproxy.com). https://www.haproxy.com/legal/haproxy-trademark-policy
  4. HAProxy Blog — “HAProxy on Docker Swarm: load balancing & DNS service discovery” (haproxy.com). https://www.haproxy.com/blog/haproxy-on-docker-swarm-load-balancing-and-dns-service-discovery

Primary sources: