The Reliable, High Performance TCP/HTTP Load Balancer

  Mirror Sites: Master
  Language: English

Quick links

Quick News
Recent News
Download & doc
Live demo
They use it!
Enterprise Features
Third party extensions
Commercial Support
External links
Slack channel
Mailing list
Coding style
Open Issues
Known bugs

HATop: Ncurses Interface
Herald: load feedback agent
haproxystats: stats collection
Alpine-based Docker images
Debian-based Docker images
RHEL-based Docker images
Debian/Ubuntu packages

visitors online
Thanks for your support !

Latest versions

BranchRelease dateEnd of lifeLatest versionChangelogLinks
2.6-dev ~2022-Q2 2027-Q2 (dev » LTS) 2.6-dev0 2021/11/23 git / web / dir / announce
2.5 2021-11-23 2023-Q1 (stable) 2.5.0 2021/11/23 git / web / dir / announce / bugs
2.4 2021-05-14 2026-Q2 (LTS) 2.4.9 2021/11/24 git / web / dir / announce / bugs
2.3 2020-11-05 2022-Q1 (stable) 2.3.16 2021/11/24 git / web / dir / announce / bugs
2.2 2020-07-07 2025-Q2 (LTS) 2.2.19 2021/11/29 git / web / dir / announce / bugs
2.0 2019-06-16 2024-Q2 (LTS) 2.0.25 2021/09/07 git / web / dir / announce / bugs
1.8 2017-11-26 2022-Q4 (critical fixes only) 1.8.30 2021/04/12 git / web / dir / announce / bugs
1.7 2016-11-25 2021-Q4 (critical fixes only) 1.7.14 2021/03/31 git / web / dir / announce / bugs
Hide/Show unmaintained

Quick News

Nov, 23th, 2021 : HAProxy 2.5.0 release

November 5th, 2021 : Cool hardware donation from Zerodha

    Just after the HAProxy 2.4.0 release in May this year, Kailash Nadh, CTO of Zerodha contacted me and offered to donate a pair of SolidRun HoneyComb LX2 boards to help us continue to improve out threading scalability. With 16 ARM cores, 32GB RAM, 64GB eMMC, 4x10GbE, and PCI-e in a tiny and quiet form factor, there definitely is plenty of potential to emphasize the cost of contention and to further improve our data model and our algorithms! As usual with SolidRun, the hardware design is really awesome (it feels like you're installing a PC, and they're about the only ones featuring the console port). However I must say I was really disappointed by their complete absence of communication during the 5 months it took to ship the board. Vishnu of Zerodha and me probably asked them for status updates 8 times in total and each time we were told "we'll contact you when it ships, no need to ask all the time". Last time we were told the parcel had been sent two weeks ago to DHL who had no way to contact me... no comment! Emailing a tracking number doesn't cost much, especially when their own tracking site still shows the order as "processing" after I received it! Hopefully SolidRun manages to address this deficiency in the future because right now they're among the very few who make affordable server-grade development boards and I hope to continue to be able to order their great products without trouble... Anyway, more news later when the tests really begin! For now the boards boot and are fast (hint: haproxy-2.5 builds in 6 sec). Many big thanks to Kailash and Vishnu of Zerodha for this very kind contribution!

November 3rd, 2021 : HAProxyConf 2021 is in less than two weeks!

    The conference is still scheduled for November 16-17 and will be free to watch on https://www.haproxyconf.com/, with live Q&A sessions after each talk. The list of speakers and their presentations is already published. The conference schedule is being finalized and is to be published in the forthcoming days, please check the site to stay up to date, or register to be notified about last-minute updates. See you soon!

May, 14th, 2021 : HAProxy 2.4.0 release

    HAProxy 2.4 is now the latest LTS release. It comes with lots of new stuff making it more dynamic, more user-friendly, more reliable, more flexible, and more scalable. Please check the announce here for the details.
April 8th, 2021 : Broke new performance record: 2 million req/s & 100 Gbps

    There was no performance report published since the 100k req/s milestone 12 years ago... So here is a great one: 2 million HTTPS requests forwarded per second, and 100 Gbps of bandwidth achieved on AWS's c6gn instances running the 64-core ARM Graviton2 CPUs. This shows that our thread scalability has massively improved since threads made their entry in 1.8, it's immensely rewarding for all those who spent countless hours chasing nanosecond and scratching their heads to eliminate lock after lock! And it confirms if it was still needed that the old multi-process model can now rest in peace, being completely obsolete by 2021's standards.
Older news...


HAProxy is a free, very fast and reliable reverse-proxy offering high availability, load balancing, and proxying for TCP and HTTP-based applications. It is particularly suited for very high traffic web sites and powers a significant portion of the world's most visited ones. Over the years it has become the de-facto standard opensource load balancer, is now shipped with most mainstream Linux distributions, and is often deployed by default in cloud platforms. Since it does not advertise itself, we only know it's used when the admins report it :-)

The HAProxy core team maintains multiple versions in parallel. Since version 1.8, two major version are emitted every year. The first digit usually indicates a breaking change (config format etc) but in practice rarely changes. The second digit indicates new features. Both constitute a branch. One extra number appears after these digits to indicate the bug fix release.

The core team deploys a lot of efforts backporting fixes to older releases while being extremely careful not to break anything. For this reason, it is really important to stay up to date within one branch, i.e. having the highest possible number on the last digits.

Branches with an even number are called "LTS" (for "long term support") and area maintained for 5 years after their release. During this time they will receive fixes for bugs that are discovered after the release. These branches are aimed at general users who seek extreme stability and do not want to qualify a new version too often but still want to receive fixes.

Branches with an odd number are only called "stable", they're aimed at highly skilled users who prefer to upgrade often to benefit from modern features, and who are also able to roll back in case of problem. These versions are maintained between 12 and 18 months. The duration is short and purposely not strict so that the maintenance cycle is decided with users based on feedback, and so that these versions do not end up in embedded products. It may happen that a few features are backported to these version if there is some reasonable demand and the operation is considered riskless enough.

Everyone used to dealing with production knows that it's difficult to upgrade components in field when one has to plan and advertise upwards of any operation. For this reason, the HAProxy core team doesn't insist on users to upgrade, will not ask someone to switch to a new branch (unless they ask for a feature that is part of that other branch), but will often ask the user to re-check with the latest version of their branch before reporting a problem, because nobody likes to troubleshoot a problem a second time. It's often suggested to use the versions that come with the operating system when it follows the official maintenance cycle, and depending on the expected level of stability or exposure, some users may want to update as soon as an update is available while others may prefer to wait a few weeks to a month to be sure the update is reliable enough for them.

The currently supported versions are :

  • version 2.5 : runtime server addition/removal, runtime CA/CRL updates, native HTTP client, simplified HTTPS logging, default TCP/HTTP rulesets, JWT validation, and more
  • version 2.4 : syslog and DNS over TCP, multi-threaded Lua, full sharing of idle conns, lower latency, server-side dynamic SSL update, Opentracing, WebSocket over H2, atomic maps, Vary support, new debugging tools, even more user-friendly CLI and configuration, lots of cleanups
  • version 2.3 : syslog forwarding, better idle conn management, improved balancing with large queues, simplified SSL managment, more stats metrics, stricter config checking by default, general performance improvements
  • version 2.2 : runtime certificate additions, improved idle connection management, logging over TCP, HTTP "return" directive, errorfile templates, TLSv1.2 by default, extensible health-checks
  • version 2.1 : improved I/Os and multi-threading, FastCGI, runtime certificate updates, HTX-only, improved debugging, removal of obsolete keywords
  • version 2.0 : gRPC, layer 7 retries, process manager, SSL peers, log load balancing/sampling, end-to-end TCP fast-open, automatic settings (maxconn, threads, HTTP reuse, pools), ...
  • version 1.9 : improved multi-threading, end-to-end HTTP/2, connection pools, queue priority control, stdout logging, ...
  • version 1.8 : multi-threading, HTTP/2, cache, on-the fly server addition/removal, seamless reloads, DNS SRV, hardware SSL engines, ...
  • version 1.7 : added server hot reconfiguration, content processing agents, multi-type certs, ...
  • version 1.6 : added DNS resolution support, HTTP connection multiplexing, full stick-table replication, stateless compression, ...
  • version 1.5 : added SSL, IPv6, keep-alive, DDoS protection, ...


As shown in this test run on AWS ARM-based Graviton2, HAProxy scales very well with threads and was shown to be able to reach 2 million requests/s over SSL and 100 Gbps for forwarded traffic.

This is made possible thanks to its event-driven architecture that allows to react extremely quickly to I/O events, its parallelism on SMP machines provided by light multi-threading, a task scheduler that permanently composes between low-latency and high throughput, and generally speaking a permanent quest of resource savings at every single architecture layer. These efforts tend to cost a bit in development time but are immediately valued by users who are able to reduce their number of machines upgrade after upgrade. For the vast majority of common loads, the HAProxy process is simply not noticed, which tends to make its users forget it, sometimes resulting in questions regarding extremely old versions.

Please consult this section for more information on the architecture details and some performance test results.

Reliability - keeping high-traffic sites online since 2002

HAProxy is first known for being extremely robust. The core team developers tend to be irritated by certain bugs they fix, but this is because their job is to see them all. Most users report having never ever faced any single crash and claim that HAProxy is the most solid part of their infrastructure. Finding machines with HAProxy processes being up for more than 3 years is not exceptional at all!

All this is not an accident, though. A lot of efforts are made in that direction, to provide excellent observability on what is happening, and an amazing number of protections against bad behaviors. HAProxy is built with many checks for unacceptable situations (impossible conditions, endless loops, etc) that in other products might result in service outages or data corruption, but in HAProxy will immediately result in a crash with a dump of the problem. This rigor pays off since most users have never faced such an issue, thanks to the few who faced them and provided useful reports allowing to fix the problem early.

The development process also encourages quality, with a long term maintenance cycle: versions are maintained for 5 years by the same developers who code the new features. This encourages them to write high quality code and commit messages that correspond to the highest standards. A regression testing suite is used and run along development by all developers and before merging code, as well as after on a wide variety of platforms thanks to the continuous integration (CI) system.

The principle of "eating one's dog's food" applies here as well: haproxy.org runs on the latest development release. This usually helps spot a bug or two per major version before it hits a release. But in addition it maintains a permanent pressure on the development team to release something they're confident in.

The program having been designed from its early age to be extremely conservative on resource usage, a significant number of settings are calculated at startup time and enforce many limits on number of sockets, connections, streams etc, guaranteeing that any processing that was started will complete.

Security - Hardened by default

Security is a very important concern when deploying a software load balancer, because it runs at the edge and takes all the dirty traffic. It is possible to harden the OS, to limit the number of open ports and accessible services, but the load balancer itself stays exposed. The unified and non-fantasist coding style aims at avoiding common traps when writing or reviewing code. Some high standards are sought when it comes to dealing with unvalidated data. Non-portable functions and those having unreliable behaviors are avoided or replaced. Input data gets sanitized very early in the lower layers. Resource usage is carefully controlled. Dangling pointers are forbidden in the code via careful release functions. These standards already help eliminate a great deal of uncertainty in the code itself.

Since zero-bug is not reasonable, the product embarks a number of defensive measures, such as chroot, privilege drops, fork prevention, strict protocol validation, checks for impossible states and detailed traces in case of violation detection, etc. All these usually result in an attempt to exploit a real bug in a failure or possibly a crash. These measures have to be purposely disabled by the user using sufficiently evocative commands so that the reason for doing so has to be regularly questioned.

Complete Download Matrix

Here you will find a quick access to downloadable contents by type and version. Just click on the desired format to access the content in that format.

Git repository Git / Web Git / Web Git / Web Git / Web Git / Web Git / Web Git / Web Git / Web Git / Web Git / Web Git / Web Git / Web Git / Web Git / Web Git / Web Git / Web Git / Web
Latest snapshot tar.gz / Log tar.gz / Log tar.gz / Log tar.gz / Log tar.gz / Log tar.gz / Log tar.gz / Log tar.gz / Log tar.gz / Log tar.gz / Log tar.gz / Log tar.gz / Log tar.gz / Log tar.gz / Log tar.gz tar.gz -
Latest release tar.gz / Log tar.gz / Log tar.gz / Log tar.gz / Log tar.gz / Log tar.gz / Log tar.gz / Log tar.gz / Log tar.gz / Log tar.gz / Log tar.gz / Log tar.gz / Log tar.gz / Log tar.gz / Log tar.gz / Log tar.gz / Log -
Browsable dir Dir Dir Dir Dir Dir Dir Dir Dir Dir Dir Dir Dir Dir Dir Dir Dir Dir
Known bugs Web Web Web Web Web Web Web Web Web Web Web Web Web Web Web Web Web
Starter guide html / txt html / txt html / txt html / txt html / txt html / txt html / txt html / txt html / txt html / txt html / txt - - - - - -
Configuration manual html / txt html / txt html / txt html / txt html / txt html / txt html / txt html / txt html / txt html / txt html / txt html / txt html / txt txt txt txt txt
Management guide html / txt html / txt html / txt html / txt html / txt html / txt html / txt html / txt html / txt html / txt html / txt - - - - - -
Lua ref. manual html html html html html html html html html html html - - - - - -
Lua arch. guide html / txt html / txt html / txt html / txt html / txt html / txt html / txt html / txt html / txt html / txt html / txt
Browsable doc Dir Dir Dir Dir Dir Dir Dir Dir Dir Dir Dir Dir Dir Dir Dir Dir Dir

Please note that official docs are the pure-text ones and directly come from the project, except for the Lua reference manual that is maintained by Thierry Fournier. The HTML versions are direct translations from the text version automatically performed by Cyril Bonté's excellent documentation converter, dconv. A TeX-oriented variant able to produce PDFs was also created by Pavel Lang for versions 1.4 and 1.5 but it is not maintained anymore.

Commercial Support and availability

If you think you don't have the time and skills to setup and maintain a free load balancer, or if you're seeking for commercial support to satisfy your customers or your boss, you have the following options :

  1. contact HAProxy Technologies to hire some professional services or subscribe a support contract ;
  2. install HAProxy Enterprise Edition (HAPEE), which is a long-term maintained HAProxy package accompanied by a well-polished collection of software, scripts, configuration files and documentation which significantly simplifies the setup and maintenance of a completely operational solution ; it is particularly suited to Cloud environments where deployments must be fast.
  3. try an ALOHA appliance (hardware or virtual), which will even save you from having to worry about the system, hardware and from managing a Unix-like system.
I also find it important to credit Loadbalancer.org. I am not affiliated with them at all but like us, they have contributed a fair amount of time and money to the project to add new features and they help users on the mailing list, so I have some respect for what they do. They're a UK-based company and their load balancer also employs HAProxy, though it is somewhat different from the ALOHA.


Feel free to contact us for any questions or comments :

Some people regularly ask if it is possible to send donations, so I have set up a Paypal account for this. Click here if you want to donate.

An IRC channel for HAProxy has been opened on Libera.Chat:

A Slack Workspace for HAProxy exists as well:

External links

Here are some links to possibly useful external contents I gathered on the net. I have found most of them due to their link to haproxy's site ;-)