Last checked and updated on 06 Jun 2026
How Does HAProxy Decide How Long a Version Is Supported?
HAProxy uses a branch numbering system to signal support duration upfront. Even-numbered branches (2.6, 2.8, 3.0, 3.2...) are designated LTS (Long-Term Support) and maintained for 5 years from release. Odd-numbered branches (2.7, 2.9, 3.1, 3.3...) are called stable and receive maintenance for only 12 to 18 months.
The distinction is intentional and targets two different operator profiles. LTS branches are for teams who prioritize stability over features and want a long runway between upgrades. Stable branches are for engineers who stay close to the cutting edge and are comfortable rolling back when something breaks.
| Branch Type | Version Numbering | Support Duration | Target Users | Feature Backports |
|---|---|---|---|---|
| LTS | Even minor version (e.g. 2.8, 3.0, 3.2) | 5 years from release | General users, embedded deployments | Bug fixes and security only |
| Stable | Odd minor version (e.g. 2.9, 3.1, 3.3) | 12--18 months (flexible) | Advanced users, frequent upgraders | Occasionally, if low-risk and in demand |
EOL dates published on the HAProxy website use a YYYY-Qn format rather than exact dates. This is a deliberate choice by the maintainers to preserve flexibility. The release table above uses the conservative interpretation: the first day of the given quarter (Q1 = January 1, Q2 = April 1, Q3 = July 1, Q4 = October 1).
More details are available on the official HAProxy website and the HAProxy mailing list.
What Can Go Wrong When You Run an Unsupported HAProxy Branch?
Running an EOL HAProxy branch in production means your load balancer -- the single component sitting in front of every upstream service -- stops receiving fixes. For most software this is a gradual risk. For a proxy that terminates TLS and forwards HTTP traffic at high volume, the exposure is immediate and architectural.
No more CVE patches
HAProxy handles TLS negotiation, header parsing, and HTTP/2 framing. Vulnerabilities in these areas have historically allowed request smuggling, header injection, and in some cases connection hijacking. When a branch reaches EOL, none of these get patched regardless of severity.
ACL and configuration directive drift
New HAProxy versions regularly deprecate or rename directives. Staying on an old branch while the rest of your infrastructure moves forward creates subtle config incompatibilities, especially when using configuration management tools (Ansible, Chef, Terraform) that generate HAProxy config from templates targeting current syntax.
Backend and upstream protocol mismatches
If your upstream services begin using newer HTTP features -- HTTP/3, extended CONNECT, revised ALPN negotiation -- an old HAProxy branch may silently mishandle them. Load balancers are expected to be transparent; an outdated one can introduce protocol-level bugs that are very hard to diagnose.
Stable branches expire faster than teams expect
The 12--18 month window on stable branches catches teams off guard more than any other aspect of HAProxy's lifecycle. If you deployed a stable branch thinking "we'll upgrade in a year," the EOL date may arrive before your next scheduled maintenance window. In practice, LTS branches are a safer default for most infrastructure teams.
What Actually Happens When an HAProxy Branch Goes EOL?
When an HAProxy branch reaches its EOL date, the upstream project stops publishing patch releases for it. There are no security advisories, no backported fixes, and no further entries in the changelog. The branch is marked as "unmaintained" on the HAProxy website.
Unlike some projects that enter a "critical fixes only" phase before full EOL, HAProxy moves directly from active maintenance to unmaintained -- with one exception. Some LTS branches go through a transitional period where only critical fixes are applied before the branch is fully dropped. You can identify this status in the release table above.
The HAProxy binary itself continues to run after EOL. Nothing breaks immediately. But from that point forward, any bug you encounter -- whether it is a crash under load, a TLS regression, or a header parsing edge case -- will not receive an upstream fix. Your options become: patch it yourself, stay on the broken behavior, or upgrade.
Most distributions that package HAProxy (Debian, Ubuntu, RHEL) track LTS branches specifically to avoid shipping EOL software to end users. If your distro's package manager stops updating HAProxy, it is a signal that the branch it is tracking has reached or is approaching EOL.
How To Check Your HAProxy Version
The fastest way to check your running HAProxy version is with the -v flag:
haproxy -v
This prints the version string along with the build date and compile-time options. A typical output looks like:
HAProxy version 3.2.15-c24b2f0 2026/03/19 - https://haproxy.org/
Status: long-term supported branch - will stop receiving fixes in 2030/Q2.
Known bugs: http://www.haproxy.org/bugs/bugs-3.2.15.html
Running on: Linux 6.1.0 #1 SMP x86_64Note that recent builds include a Status line that directly tells you the branch type and when support ends. This is one of the most developer-friendly EOL disclosures of any open source project.
If HAProxy is running as a service, you can also query the process without restarting:
haproxy -vv
The -vv flag adds verbose build information including enabled features (OpenSSL version, Lua support, PCRE, etc.), which is useful when diagnosing compatibility issues across environments.
To check via the stats socket at runtime (without restarting):
echo "show info" | socat stdio /var/run/haproxy/admin.sock | grep VersionThe minor version number in the output tells you immediately whether you are on an LTS or stable branch: even = LTS, odd = stable.
FAQ
Q1: What is the difference between HAProxy LTS and stable branches?
LTS branches have an even minor version number and are supported for 5 years. Stable branches have an odd minor version number and are supported for only 12 to 18 months. LTS branches receive bug fixes and security patches throughout their lifecycle. Stable branches may occasionally receive feature backports, but the short window makes them unsuitable for most production deployments unless your team actively tracks upgrades.
Q2: Why does HAProxy use YYYY-Qn instead of exact EOL dates?
The HAProxy project uses quarter-based EOL dates intentionally, as documented on the mailing list. The maintainers prefer flexibility -- a branch may be extended or closed slightly earlier depending on the release activity of the next branch. The conservative interpretation (first day of the given quarter) is what the release table above uses, and it is adjusted if a newer release shifts the timeline.
Q3: Should I run an HAProxy stable branch in production?
It depends on your team. Stable branches are explicitly aimed at experienced users who upgrade frequently and can roll back if needed. For most infrastructure teams managing HAProxy as a long-lived component, LTS branches are the better choice. The 12--18 month window on stable branches is short enough that it often expires before the next planned upgrade cycle.
Q4: Does HAProxy have a "security-only" support phase before EOL?
Not as a formal policy. Some LTS branches enter a "critical fixes only" phase near the end of their lifecycle, but this is informal and not guaranteed for every branch. Once a branch is marked unmaintained, no fixes of any kind are published. This is different from projects like Python, which have a defined multi-year security-only phase.
Q5: How do I know if the HAProxy version shipped by my Linux distro is still supported?
Check the minor version number of the package your distro ships. If it is an even number, it is an LTS branch -- cross-reference the EOL date in the release table above against the current date. Major distributions like Debian and Ubuntu intentionally track LTS branches; if the packaged version is an odd number, it is likely old enough that it has already reached EOL upstream. In that case, consider adding the official HAProxy PPA or using a container image from Docker Hub.