For years, Liftoff relied on a managed enterprise proxy vendor. It worked, until it didn’t. As traffic grew, so did the challenges: rising operational costs, vendor lock-in, and performance limitations threatened their ability to maintain the ultra-low latency their ad tech platform demanded.

These obstacles led Liftoff to migrate to HAProxy, reducing costs by 87.6% and improving latency by 75%. Tommy Nguyen and Ken Chin shared their journey at HAProxyConf, and we unpack their story below.

Liftoff’s proxy was a managed service sitting outside their infrastructure. Every configuration change went through the vendor. Routine updates that should have taken a day could stretch across an entire sprint cycle.

The vendor’s platform also added extra network hops between Liftoff’s systems and their backend services. This added latency is a real problem for an ad tech company where milliseconds directly affect revenue.

Agility and performance weren’t the only challenges faced.

Costs scaled with traffic, but not in a manageable way. Their vendor's pricing model made it harder for the business to grow efficiently. And because the proxy was proprietary, Liftoff didn’t have the flexibility to change directions if their architecture needs shifted.

Liftoff decided they needed a sovereign infrastructure solution that they could own, configure, and run themselves.

Building their architecture with HAProxy

The team spent six months moving from initial testing to a production-ready HAProxy deployment. They ran performance tests, collaborated across teams, and built the automation and monitoring tooling needed before going live.

The architecture they landed on used GitHub Actions to trigger builds, HashiCorp Packer to create pre-configured machine images, and Ansible to handle consistent provisioning across servers. AWS EC2 instances ran HAProxy, with Route 53 directing inbound traffic. AWS Network Load Balancers (NLBs) sat between HAProxy and backend Kubernetes clusters spread across multiple availability zones.

The results were immediate and significant. Operational costs dropped by 87.6%. Latency improved by 75%. Configuration deployments that previously took weeks could now be completed in a single day — a 93% improvement in deployment speed.

That was phase one.

Using HAProxy to address outages and NLB blind spots

After a period of stable operation, a major traffic failure hit the Liftoff platform. The team couldn't restore normal service for several hours. The outage was painful, but what made it worse was not being able to pinpoint the cause quickly.

The NLBs sitting between HAProxy and the backend pods were a blind spot. There wasn't enough visibility into that layer to diagnose what was happening during the incident. Troubleshooting required guesswork, and that cost time.

The incident pushed the team to rethink the architecture – to lean more on the trusted and reliable HAProxy deployment. The question wasn't just how to prevent another failure; it was how to make HAProxy the single, observable control point for all traffic decisions.

Rebuilding with dynamic service discovery

To make that work at scale, the team integrated Consul service discovery with HAProxy. Backend services automatically register themselves in Consul's catalog. HAProxy reads those records in real time, so its routing table stays up to date without manual changes or configuration redeployment. When a pod turns unhealthy, Consul removes it, and HAProxy stops sending traffic there — immediately, automatically.

As a result, HAProxy now makes the routing decisions. It knows which backends are healthy, where they are, and how to reach them. There's no secondary system making routing choices that HAProxy can't see.

This flatter design brought an additional 20% reduction in operational costs, simply by eliminating the abstraction layer that was no longer needed. While that improvement was not the original intention, it reflects how much unnecessary overhead the old architecture carried.

End-to-end visibility with HAProxy

The new architecture gave Liftoff something they hadn't had before: end-to-end visibility from the moment a request hits HAProxy through to storage.

They use HAProxy's native Prometheus exporter to export metrics to Prometheus, then visualize everything using a modified version of HAProxy's Grafana template. The dashboards track connection rates, backend response times, latency, HTTP response codes, and Consul catalog counts throughout the day.

Because Liftoff's traffic follows predictable patterns, they can also run reliable week-over-week comparisons and spot anomalies early. They take their logs out of HAProxy and ingest them into their Loki, giving the team a centralized place to query and analyze log data alongside their metrics.

This kind of observability stack is what the first architecture was missing. Now, when something goes wrong, the team has the data to diagnose it quickly.

What the HAProxy roadmap looks like for Liftoff

Liftoff is planning to upgrade HAProxy to the latest version, with several specific capabilities driving the decision.

Glitch limit functionality will help the team handle protocol glitches without draining CPU resources. Enhanced logging will give them finer-grained data at the HAProxy layer, improving their ability to correlate events across the stack. Enhanced stick tables and improved traffic prioritization will let them shape traffic more precisely across different service tiers (particularly useful when some services have tighter latency requirements than others).

They're also planning to move from a third-party auto-scaling solution to a first-party one, giving them more direct control over how HAProxy instances scale against their specific traffic patterns. And they're working on grouping HAProxy instances by traffic destination, so that high-priority or latency-sensitive services get dedicated capacity rather than competing for shared resources.

Further out, the team is watching HAProxy's AI gateway capabilities. As LLM-based API traffic becomes more common in their stack, routing it through HAProxy (with the same performance, configurability, and observability they already rely on) is a natural extension of what they've built.

While Liftoff achieved these results with the open source version of HAProxy, organizations that need enterprise-grade service discovery, automated configuration management, direct-to-pod routing, centralized observability, and high-throughput performance at scale can get these capabilities out of the box with HAProxy One, the world's fastest application delivery and security platform.

The report carries a CVSS v4.0 score of 8.7 (High). We want to be transparent about that score and equally clear about our assessment: the real-world risk is low. This is not realistically exploitable.

The issue was observed only on a custom-modified HAProxy build, and neither our team nor the reporter was able to reproduce it on a standard build. There is no known proof-of-concept and no evidence of exploitation in the wild. The CVSS vector also reflects an availability-only impact (a process crash) with no impact to confidentiality or integrity.

The reason comes down to how modern systems manage memory. Triggering this bug requires an allocation to return NULL under memory exhaustion. Still, on a normally configured Linux system, the kernel's out-of-memory (OOM) killer terminates a memory-starved process before that can happen. Returning NULL in this path generally requires a non-default memory-overcommit configuration that very few deployments use. In practice, a server would already be in a critical low-memory state before this code path could be reached.

We committed a fix regardless, out of respect for the report and to keep our codebase clean, and we are rolling it out through our normal release process rather than as an emergency patch. We recommend customers update to a fixed version once it is available for their product. In the meantime, the most effective safeguard is the one we recommend for any production deployment: size HAProxy to the memory available on its host so the process does not approach Out-of-Memory (OOM) conditions.

Vulnerability details

• CVE Identifier: CVE-2026-55204

• CVSS v4.0 Score: 8.7 (High) — base score assigned by the CNA (VulnCheck)

  • Vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

  • For reference, the equivalent CVSS v3.1 base score is 7.5 (High): CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

• Weakness: CWE-476 (NULL Pointer Dereference)

• Affected component: HAProxy HPACK dynamic header table — hpack_dht_insert() in src/hpack-tbl.c

• Reported by: Tristan Madani

• Published: June 18, 2026 (CVE source: VulnCheck)

• Description:

  • The issue was first reported to HAProxy Community Edition as a minor bug, demonstrated using a custom version of HAProxy.

  • hpack_dht_insert() does not validate the return value of hpack_dht_defrag() when the memory pool is exhausted. HPACK dynamic table insertions under memory pressure can dereference a null pointer, crashing HAProxy worker processes and causing a denial-of-service.

  • HAProxy Technologies was unable to reproduce the bug with a standard version of HAProxy, and has no evidence of exploitation. CISA's automated SSVC assessment also records exploitation status as "none."

  • Because the trigger is memory-pool exhaustion, deployments with insufficient memory (reaching OOM or similar states) are most relevant to this issue.

HAProxy's assessment

Based on our analysis, we do not consider this a meaningful avenue for attacking or weakening HAProxy services. A rolling release is typical for HAProxy Enterprise patches addressing low-risk issues: fixes flow continuously from HAProxy Community Edition and are picked up for upcoming HAProxy Enterprise releases and backports. 

We are publishing this advisory because a CVE with a high CVSS score has been filed, and we want customers to have the full picture (both the score and our assessment) so they can make an informed decision about when to update.

Affected versions and remediation

This issue is present across currently supported versions of HAProxy — the CVE record cites all releases up to and including 3.4.0, so it is not limited to the latest branch. Because the affected code is part of the core HTTP/2 engine, products built on HAProxy (HAProxy Community Edition, HAProxy Enterprise, and HAProxy ALOHA) should be assumed in scope. The fix is committed upstream in commit 9a6d1fe.

At the time of writing, the fix has not yet been included in a tagged HAProxy Community Edition release — it is available in source for anyone who wishes to compile it themselves — and HAProxy Enterprise packages and builds are being rebuilt now. The HAProxy Community Edition team is targeting a tagged release in its next release series

The issue is fixed in HAProxy Enterprise after the following builds:

The permanent fix is delivered by updating to a patched version. In the meantime, the most effective safeguard is the one we recommend for any production deployment: size HAProxy to the memory available on its host so the process does not approach Out-of-Memory conditions. A system kept within healthy memory limits will not reach the state required to trigger this issue.

Upgrade instructions

Once fixed images are available, users of affected products should update by pulling the latest version for their respective release track. Instructions are linked below (customer login required):

• Upgrade HAProxy Enterprise

• Upgrade HAProxy Enterprise with HAProxy Fusion

• Upgrade HAProxy ALOHA

• HAProxy Community Edition: update to the fixed tagged release once published, or build from source.

Support

If you are an HAProxy customer with questions about this advisory or about upgrading to the latest version, please contact our support team.

We were there to talk about HAProxy One, the world’s fastest application delivery and security platform. It puts load balancing, next-gen security layers, Kubernetes routing, and API gateway in a single stack. HAProxy Enterprise is the data plane: it processes the traffic. HAProxy Fusion is the control plane: it handles management, observability, automation, and integration with the infrastructure around it. HAProxy Edge is the global edge network: it provides fully managed application delivery services from a global low-latency network.

As we spoke to attendees, four clear themes kept coming up. These are patterns from real booth conversations with engineers across company sizes, industries, and cloud maturity levels. Each pattern reveals a technical challenge and a business need that HAProxy One is a great fit for: 

• Integration with AWS 

• Portability across infrastructure 

• Consolidation of tool-sprawl (especially in security) 

• Pricing that helps you scale

1. Designed to work on AWS

The engineers we spoke to wanted tools designed to work in the AWS environment. Third-party tools that require significant integration work lose before they start.

AWS-native services like ALB and AWS WAF work out of the box. Everything else can feel bolted on. Engineers want the performance and flexibility of best-of-breed tooling, without the operational friction.

One question came up in various forms: "How does your product integrate with AWS?" This was an understandable pre-qualification question. If the answer wasn't convincing, the conversation moved on.

Fortunately, HAProxy One provides scalable AWS load balancing and security:

• HAProxy Fusion Control Plane connects directly with AWS Route 53, and supports Auto Scaling Group awareness for load balancing with HAProxy Enterprise.

• Hardened AWS AMIs for HAProxy Enterprise ship with automatic HAProxy Fusion registration.

• Native support for Graviton instances, with performance measured at over 2 million HTTPS requests per second on Graviton2. 

• SSL/TLS processing with AWS-LC cryptography delivers up to 2X the TLS performance of OpenSSL 3+.

• HAProxy Enterprise is in the AWS Solutions Library, co-validated and architecturally integrated with the platform.

HAProxy is built to live inside an AWS environment without being dependent on it.

2. Cloud-neutral and infrastructure-agnostic

The engineers who sounded most nervous were the ones with the most mature AWS environments and the deepest integration, who faced the biggest impact if something were to change.

Those who have built on AWS for years know that every AWS-native architectural decision is a sunk cost that makes the next one harder to reverse. They want full AWS integration today without closing the door on tomorrow.

More than one engineer said something to this effect: they were all-in on AWS right now, but they'd been all-in on things before, and they knew how those stories could end. So they can’t afford to be locked into one environment. Any assets they can carry over to another cloud or on-premises data centers has more long-term value. 

HAProxy suits this approach. It runs the same platform, with the same configuration and behavior, in any environment: on-prem, AWS, GCP, Azure, bare metal, VMs, and Kubernetes. No proprietary APIs, no “migration tax” when architecture evolves. 

Engineers were asking for exactly this: for any application, on any infrastructure, without compromise.

3. One unified platform to replace many tools

Security was the number-one conversation starter at the NYC booth, and the most common frustration was that securing an AWS application typically means running multiple products. A load balancer here, a WAF somewhere else. Then a third product for DDoS, each with its own console and its own incident playbook. Each additional tool adds operational overhead. It also adds a network hop in the request path, and the latency cost compounds. So does the attack surface between integrations.

AWS makes it easy to add another managed service. The bill and the complexity grow together. Several engineers described sprawl they'd built one service at a time and were now trying to rationalize.

The billing complexity was a specific frustration, but the deeper concern was decision overhead. Every additional capability engineers needed as they grew meant evaluating a new tool, budgeting for it separately, and absorbing the operational cost of adding it to their deployment. Sprawl is the inevitable outcome when each problem gets its own product.

HAProxy One puts load balancing, WAF, bot management, DDoS protection, Kubernetes ingress and routing, and API gateway in a single platform. All of it runs through one data plane in the traffic path, managed by one sovereign control plane (that you deploy and manage). 

The HAProxy Enterprise WAF, powered by the Intelligent WAF Engine, delivers exceptional balanced accuracy and ultra-low latency, so consolidation doesn't require compromising on security or performance. The HAProxy Enterprise Bot Management Module, powered by the Threat Detection Engine, stops complex, high-impact threats including application layer DDoS, brute force attacks, web scrapers, and vulnerability scanners. These powerful security layers run locally with no external connection, keeping your traffic and telemetry private.

Can one product excel in all these categories, without compromise? Well, that’s what more than 900 verified user reviews on G2 tell us. In the latest G2 Summer 2026 Grid^® Reports, HAProxy received a perfect Satisfaction Score of 100, and was named a Leader in Load Balancing, WAF, DDoS Protection, Container Networking, and API Management.

A unified stack is faster to operate, harder to misconfigure, and reduces the cost and complexity of decisions as you grow.

4. Pricing that makes sense at scale

Consumption-based pricing works in the early stages. At scale, it stops working for the customer.

Any traffic spike (usually good news) comes with a matching bill (bad news). DDoS events and high-volume API endpoints are no different. The engineers most exposed to this problem are exactly the ones who've succeeded most. High-traffic applications protected by AWS WAF and load-balanced by ALB are billed per request or per connection, and at scale that adds up fast.

Several engineers described the experience of a strong traffic month where their security bill scaled with it at exactly the same rate — growth penalized by the model designed to protect it. Their eyes would light up at the thought of flat, predictable pricing.

HAProxy is instance-based: you pay for the instance, not the traffic. No per-request fees, no bill surprises during high-traffic events. At scale, the TCO advantage over consumption-priced alternatives is substantial and compounds. 

There's a longer-term dimension here as well. Pricing predictability is partly a vendor stability question. HAProxy is independently owned and profitable, not subject to the acquisition cycles that have repriced infrastructure for a lot of teams over the last few years.

Cloud and AI without compromise

These four themes aren't coincidental. Engineers see immense value in building on AWS, but they are also keenly aware of the trade-offs that come with investing heavily in one environment.

They want to build well, not just build fast. Depth without dependency. Consolidation without compromise. Pricing that rewards growth and success. That's what HAProxy One is built to deliver.

These factors are particularly useful for engineers building internal AI infrastructure: load balancing across GPU clusters, routing requests to the right model, handling inference traffic at scale. Engineers want to know whether their infrastructure will be agile and scalable enough to keep up, without introducing dozens of new components.

The good news is the traffic management fundamentals that HAProxy excels at — intelligent routing, integrated security, and performance efficiency — apply directly to AI inference. HAProxy is already the load balancing layer in production AI deployments: NVIDIA Run:ai v2.24 recommends HAProxy for the Kubernetes ingress controller, and Anyscale documented an 11.1X throughput improvement using HAProxy with Ray Serve. 

The engineering fundamentals don't change when the payload is a prompt.

If you want to see HAProxy One in action, contact our team to schedule a demo and a consultation.

For a decade, Clover ran HAProxy at the center of its infrastructure. At HAProxyConf, engineers Dilpreet Singh and Anirudh Ramesh explained how they pushed that relationship further with the HAProxy One platform, using HAProxy Enterprise and HAProxy Fusion Control Plane to build a traffic routing model they call “rainbow deployments.”

Blue-green deployments provide teams a safe way to release software. You run two environments in parallel and shift traffic from the stable version to the new one when it is ready. If something goes wrong, you can reroute the traffic back.

But Clover’s business demands more than a clean two-environment switch can provide. The company serves a wide range of merchants, including traditional banks and financial institutions that are cautious about version changes (and the risk they can pose to their business). Some customers need to stay pinned to specific versions, while others require hotfixes and experimental features without affecting the broader merchant base.

Blue-green deployments cannot provide that level of control. Once you switch traffic, everyone moves together. What Clover needed was a way to run multiple versions simultaneously and route each customer to the right one.

A deployment model built on multiple colors

HAProxy Enterprise sits in the middle of all this, deciding which color handles each request, but how is this accomplished?

The routing uses a weighted map file with number ranges corresponding to different backends. HAProxy Enterprise generates a random number between 1 and 100, looks up its position in the map, and sends the request to the corresponding backend. A split of 1 to 33 might route traffic to green. 34 to 67 to blue. 68 to 100 to red. This would give each color roughly equal traffic, but the team has the freedom to adjust those ranges at any time to shift traffic incrementally toward a new release or to pin a specific customer group to a single backend, entirely.

This approach lets Clover release version changes during normal business hours. Since the new version initially receives a controlled fraction of traffic, the platform team can monitor for problems and expand the rollout gradually. If something breaks, they adjust the map file. No all-hands rollback, no off-hours deployment windows.

How the infrastructure fits together

In their Hashicorp Nomad cluster, Clover runs three versions of their COS monolith, each represented by a color. Three blue nodes run the blue version of COS, three green nodes run the green version, and three red nodes run the red version. Each node also runs an HAProxy Enterprise instance as a sidecar container.

Traffic from the outside world arrives and is distributed across all nine nodes on port 8080. At that point, HAProxy Enterprise load balancer takes over. The lb-haproxy frontend receives the request, consults the weighted map file, and forwards it to the appropriate color backend. The request then travels to the HAProxy Enterprise instance running on a node of that color, which terminates SSL and passes the decrypted request to COS running locally on port 8020.

HAProxy Enterprise also handles egress from COS. When the monolith needs to talk to a microservice running in Kubernetes, it makes a request to a local port. HAProxy Enterprise picks that up and forwards it to the Kubernetes Istio ingress, which routes it internally. This turns HAProxy Enterprise into a service mesh for COS, without requiring the monolith itself to know where downstream services live.

Bootstrapping and dynamic backend management

The bootstrapper creates the cluster, configures Consul integration, and registers backend resource templates for each color. HAProxy Fusion then uses Consul service discovery to dynamically populate the backend server pools. When Clover registers a Nomad node in Consul with a blue, green, or red tag, HAProxy Fusion picks it up and adds it to the matching backend. Scaling the cluster up or down does not require manual backend configuration.

Once HAProxy Fusion has the configuration, it pushes it to all nine HAProxy Enterprise instances simultaneously. Changes that previously required touching individual load balancer configs now happen in one place and propagate automatically.

Low-risk deployments at any time of day

The shift to rainbow deployments changed how Clover thinks about releases. The team can now release during the day because a bad deployment affects only a slice of traffic, not every merchant at once. They can test a new version under real load by giving it 10 or 20 percent of traffic before committing fully. They can pin conservative customers to a stable version indefinitely while still moving the rest of the platform forward.

Singh put it plainly during the talk: zero on-call pages and zero drama. HAProxy has operated as a silent workhorse in Clover's stack for ten years, and the move to HAProxy Fusion extends that reliability into a more complex multi-version deployment model.

What comes next

The map file and configuration changes were still applied manually through the HAProxy Fusion UI. The team's next goal is to automate that fully through the REST API, so developers can trigger traffic shifts and version pins without touching the HAProxy configuration directly.

Clover also plans to build an application model that abstracts away the deployment target entirely. Application teams would define what they want to deploy, and the platform team's tooling would handle whether it goes to Nomad, Kubernetes, or a cloud function, with HAProxy routing configured automatically as part of the process.

Every cluster, backend, frontend, and Consul integration is configurable through the API, which means the entire deployment pipeline can eventually run without a human touching the load balancer configuration at all.

At a glance

• The issue: A critical resource-exhaustion vulnerability known as the "HTTP/2 Bomb" affects multiple major web servers, including NGINX, Apache HTTPD, Microsoft IIS, Envoy, and Cloudflare Pingora (CVE-2026-49975).

• Severity: Critical. A single home computer on a 100 Mbps connection can knock a vulnerable server offline in seconds.

• Status: Proof-of-concept (PoC) code is available, and technical details are public.

• HAProxy protection:

  • HAProxy Enterprise / Community: HAProxy is architecturally safe from being overwhelmed by this exploit due to its strict memory constraints.

  • Configuration: An optional configuration update can be applied immediately to drop malicious clients at the network edge and conserve CPU cycles.

What is CVE-2026-49975?

On June 2, 2026, security researchers disclosed a remote denial-of-service (DoS) exploit named the HTTP/2 Bomb. This flaw allows unauthenticated remote attackers to rapidly exhaust server memory, rendering major web servers inaccessible.

Technical impact

The vulnerability stems from an attack chain that combines two older techniques: a compression bomb and a Slowloris-style hold.

1. Compression bomb: The attack targets HPACK, the HTTP/2 header compression scheme. The attacker seeds the server's dynamic table with a nearly empty header and emits thousands of 1-byte indexed references to it. Because the header is tiny, standard decoded-size limits never fire.
   
   However, each 1-byte reference forces the server to create a fresh per-entry bookkeeping allocation, causing massive memory amplification (up to 5,700:1). For servers that cap field counts, attackers bypass limits by splitting the Cookie header into individual crumbs, which Apache and Envoy fail to count properly.

2. Slowloris hold: The attacker advertises a zero-byte flow-control window. This action blocks the server from finishing its response, while the attacker drips 1-byte WINDOW_UPDATE frames to reset send timeouts.

This combination pins allocations in memory indefinitely. A single client can consume and hold 32 GB of server memory in less than 20 seconds, pushing backend machines into swap and killing system performance.

• Default configurations of NGINX (before 1.29.8)

• Apache HTTPD (before mod_http2 v2.0.41)

• Microsoft IIS (Windows Server 2025

• Envoy (1.37.2 and older

• Cloudflare Pingora

Defending your infrastructure: Virtual patching vs. host reconfiguration

If your web servers are exposed directly to the internet without a security proxy in front of them, you must immediately configure manual host limits or rush out vendor updates to completely remove the threat:

Option A: Manual server reconfiguration

• Patch the source: Apply the official vendor patches to your backend web servers as soon as possible.

  • NGINX: Upgrade to version 1.29.8 or later to use the new max_headers directive.

  • Apache HTTPD: Upgrade mod_http2 to version v2.0.41 or later.

• Disable HTTP/2 on un-patched servers: If patches are unavailable (such as for IIS, Envoy, or Pingora), disable HTTP/2 on those specific servers to avoid exposure.

• Cap host worker memory: Configure cgroups, container limits, or ulimit -v tight enough on your web servers so that a bombed worker gets OOM-killed and respawned clean before it drags the host machine into a memory-swap loop.

Option B: “Virtual patching” with HAProxy

If you deploy HAProxy or HAProxy Enterprise in front of your web servers, none of the intrusive backend modifications above are required. Because HAProxy acts as an isolated protocol terminator at the edge of your network, it safely handles client-side HTTP/2 processing within its own tightly budgeted, fixed-size memory boundaries. 

It then passes sanitized (un-bombable) traffic down to your internal infrastructure. Even if your underlying web applications remain un-patched or vulnerable, they are immediately 100% protected. HAProxy acts as an instant virtual patch that removes the administrative rush to reconfigure your core server fleet.

How HAProxy protects your infrastructure

While patching upstream web servers is the ultimate remediation, HAProxy sits at the edge of your network, providing a critical first line of defense. You can stop the attack before it ever reaches your vulnerable servers.

Unlike most load balancers and reverse proxies that struggle with multiplexed streams because they rely on dynamic memory tracking, HAProxy stands out. HAProxy treats HTTP/2 streams with strict memory constraints and processes frames at bare-metal speeds.

Automatic protection with HAProxy

HAProxy is architecturally safe from being overwhelmed by the HTTP/2 Bomb exploit. Its core design limits the memory footprint of individual connections and streams, preventing an attacker from triggering out-of-memory (OOM) conditions or massive memory inflation that hits other servers. HAProxy stays stable even under high-intensity resource-exhaustion attempts.

You don't need to change anything for HAProxy itself to survive this attack

Optional: Immediate mitigation configuration

Even though HAProxy will not crash, you can use its configuration layer to actively reject attacking clients rather than spend CPU cycles processing malformed frames. In fact, it will actually “reverse” the attack by causing the malicious client to use twice as much memory and 100 times as much CPU as HAProxy!

Using HAProxy stick tables, you can track anomalous protocol behavior, including rapid resets and malformed continuation frames, and reject malicious connections before they reach application backends. 

Add the following configuration snippet to your frontend to conserve resources and frustrate the attacker:

Conclusion

Vulnerabilities like CVE-2026-49975 highlight the volatility of the modern threat landscape and show that relying solely on patching backend applications leaves a dangerous window of exposure. HAProxy provides the robust, high-performance security needed to virtually patch vulnerabilities instantly at the edge of your network.

Next steps:

• Community users: Apply the optional mitigation configuration above to reject abusive traffic early and reduce unnecessary CPU load. This will also reject other types of similar attacks.

• Evaluate your security: If you want comprehensive threat protection and automated zero-day defense, start a free trial of HAProxy Enterprise load balancer today.

Dynamic backend management simplifies integration with modern architectures, memory efficiency improves across a broader range of workloads, native cryptographic operations at the proxy layer open new possibilities for API security architectures, and OpenTelemetry support makes HAProxy a first-class participant in distributed tracing pipelines. 

Meanwhile, operational improvements in health checking, attack resistance, and log management mean HAProxy remains the best choice for the world's most demanding environments.

These advances extend HAProxy's lead across G2 categories in Load Balancing, API Management, Container Networking, DDoS Protection, and Web Application Firewall (WAF).

What’s new in HAProxy 3.4?

HAProxy is the world’s fastest and most widely used software load balancer. It provides high availability, load balancing, and best-in-class SSL/TLS processing for TCP, QUIC, and HTTP-based applications.

HAProxy is the open source core that powers HAProxy One, the world’s fastest application delivery and security platform. The platform consists of a flexible data plane (HAProxy Enterprise) for TCP, UDP, QUIC, and HTTP traffic; a scalable control plane (HAProxy Fusion); and a secure edge network (HAProxy Edge).

HAProxy is trusted by leading companies and cloud providers to simplify, scale, and secure modern applications, APIs, and AI services in any environment.

How to upgrade to HAProxy 3.4?

You can install HAProxy 3.4 in any of the following ways:

• Install the new HAProxy packages for Ubuntu, Debian, and RHEL.

• Run it as a Docker container. View the Docker installation instructions.

• Compile it from source. View the compilation instructions.

Flexibility

The headline addition is the introduction of dynamic backends, which extends HAProxy’s strengths in modern, automated environments. Building on the dynamic servers capability introduced in HAProxy 2.4, dynamic backends allow backends to be added, published, and deleted at runtime without requiring a reload. The result is fully automated backend lifecycle management, driven directly from your control plane or orchestration layer.

Experimental QMux support also lands in 3.4, enabling HTTP/3 and QUIC over TCP, useful in networks where UDP is blocked or not a suitable transport layer.

Dynamically add and delete backends

New HAProxy Runtime API commands let you add, delete, and publish backend sections. Publish makes the backend available for use. 

First, consider this HAProxy configuration:

We use the HAProxy Runtime API to perform the following:

• Create a new test-backend backend with a server, inheriting settings from the mydefaults defaults section.

• Enable the server and its health checks.

• Publish the backend so that the frontend can use it.

• Add an entry to our map file to route requests for the path /test to the new backend.

The corresponding HAProxy Runtime API commands are shown below:

To delete the server, backend, and map entry, use the following commands:

• A backend referenced by the default_backend or use_backend directives in a frontend, will be skipped if it has been disabled or unpublished. Set force-be-switch to override and force HAProxy to use the backend.

• In order to ensure that all named defaults sections are available to dynamic backends, they are now stored in memory. If you don't intend to use dynamic backends,  set the global tune.defaults.purge directive to free that memory.

QMux protocol

This version adds experimental support for QMux, a protocol that, according to the draft specification, allows sending QUIC frames over any transport protocol that provides an ordered, reliable, bidirectional, byte-oriented stream. It enables TCP to transport QUIC, offering an alternative for networks where QUIC's processing overhead over UDP outweighs its benefits (e.g., fast and reliable intra-datacenter networks).

To enable QMux, add the alpn h3 argument to the target frontend bind or backend server line and include expose-experimental-directives in the global section. Since the protocol is still in its early stages, one practical way to test this is to chain two HAProxy instances together, as illustrated by the configuration below, which allows QMux to be evaluated on both the frontend and backend.

HAProxy can now be built with the latest version of Lua (version 5.5), incorporating five years’ worth of improvements in the language. 

A new global directive, tune.lua.openlibs, provides control over which Lua standard libraries are loaded. Omitting unused libraries reduces the attack surface of Lua scripts and helps enforce security practices, particularly when scripts originate from third parties or external customers. For example:

• Omitting os disables os.execute() and os.exit().

• Omitting io disables io.open() and io.popen().

• Omitting package prevents loading native C modules via require().

• Omitting debug prevents introspection of HAProxy internals via debug.getupvalue(), debug.getmetatable(), or debug.sethook().

Set timeouts dynamically

The http-request set-timeout directive, introduced in HAProxy 2.4, originally gave the ability to change the timeout server and timeout tunnel values dynamically on a per-request basis. HAProxy 2.9 extended it to cover timeout client. Now, in HAProxy 3.4, http-request set-timeout can also adjust the values of timeout connect, timeout queue, and timeout tarpit. Together, these make it easier to apply application-specific timeouts, especially when combined with map files.

New fetches have been added to return the values of these timeouts: be_connect_timeout, be_queue_timeout, be_tarpit_timeout, cur_connect_timeout, cur_queue_timeout, cur_tarpit_timeout, and fe_tarpit_timeout.

Binary HTTP headers

New HTTP request and response actions manage (add, set, or delete) HTTP headers, storing them as data with a variable-length integer binary encoding. Refer to the documentation for these actions:

• add-headers-bin

• set-headers-bin

• del-headers-bin

Passing headers as binary data is a convenient way to modify them as a group rather than individually. This format is commonly used with the Stream Processing Offload Protocol (SPOP), making these actions particularly useful when communicating with stream processing offload agents. HAProxy also provides the req.hdrs_bin and res.hdrs_bin fetches, which return request and response headers in this format. Captured headers can be stored in variables and restored to their original state when needed.

This simplifies the exchange of multiple HTTP header fields between HAProxy and an SPOE agent: headers can be serialized and deserialized via a single variable, allowing multiple headers to be exchanged with a single declaration when the agent is trusted. A matching prefix can be specified on these actions to isolate the headers that an agent is permitted to manipulate.

QUIC protocol

This release introduces several improvements to HAProxy's QUIC protocol implementation:

• The quic-cc-algo argument is now supported by the server directive, whereas it had been supported only by the bind directive. This argument defines the QUIC congestion control algorithm, allowing the algorithm to be tuned independently for the frontend and backend network topologies. This change has been backported to HAProxy 3.3.

• The new global directive tune.quic.fe.stream.max-total limits the maximum number of requests that a single QUIC connection can handle. Once the limit is reached, HAProxy initiates a graceful shutdown of the connection (a GOAWAY frame in HTTP/3) and the connection is closed when all remaining transfers are completed.

HTTP compression

The syntax for HTTP request and response compression has been revised. Previously, compression was enabled by setting filter compression in a backend, with the option to set the compression direction directive to indicate whether to compress requests, responses, or both. The new model splits this into two filters: filter comp-req for request compression and filter comp-res for response compression. Separating the two simplifies the eventual addition of a decompression filter.

The following example compresses responses:

A new directive, filter-sequence, provides explicit control of the order in which filter directives are applied. Previously, filter execution was determined by the order in which filters were declared. With filter-sequence, filters can now be declared in any order and their execution sequence is managed independently. This is especially useful when execution order affects behavior. A good example is traffic shaping configurations that combine bandwidth limiting and compression filters. Placing compression before the limiter causes the limit to be applied on compressed traffic, which changes whether the traffic is actually throttled.

Another practical benefit of the filter-sequence directive is that any filter declared in the configuration, but omitted from the sequence directive is skipped. That's a convenient way to temporarily disable a filter without removing it from the configuration.

do-log action

In HAProxy 3.4, the do-log action now accepts the name of a log profile section as an argument.

The do-log action, introduced in version 3.1, emits custom log messages at various stages of request and response processing. The workflow is straightforward: define a log-profile section with log format strings (templates), then have do-log invoke them. For instance, a log format string might print the value of a variable named req.log_message during the processing of HTTP request rules. In the corresponding frontend, the variable would be set and then invoked with http-request do-log to log its value. 

Previously, the log profile was selected per frontend via a log line. That meant that every do-log action in a specific frontend had to use the same log profile. Now each do-log action can specify its own profile. This gives you greater flexibility in choosing the log format strings to use depending on the type of request.

HAProxy's buffer system has been reworked: large buffers can be allocated on demand for body-inspection workloads, eliminating the need to raise the global tune.bufsize and inflate memory consumption across every connection. Small buffers can also be substituted for queued and retried requests, reducing memory pressure under load. 

A scheduler overhaul preserves low latency under extreme load, shared stats counters can be split by thread group, and new CPU topology controls deliver further gains on large-core-count hardware.

Tuning buffer size

New buffer size options provide finer-grained control over the amount of memory HAProxy uses for different categories of data. Buffers play a central role in HAProxy's operation and are used in various places to store incoming and outgoing data, including HTTP requests and responses, log messages, health check exchanges, and payload data. A uniform global buffer size often results in suboptimal memory allocation: a large buffer may waste memory when used to store small queued requests, while a smaller buffer might be insufficient to handle larger payloads, such as HTTP message bodies.

The new global directives tune.bufsize.large and tune.bufsize.small allow distinct sizes to be defined for different categories of data. The corresponding directive option use-small-buffers, set in a backend or defaults section, enables the small buffer for queues, L7 retries, and health checks. The large buffer applies to the action wait-for-body, used during HTTP message body processing. These directives enable appropriate buffer sizes for these use cases, while keeping the global buffer size unchanged.

The release also adds tune.cli.max-payload-size, which defines the maximum payload size accepted by the HAProxy Runtime API.

Task scheduler

As a request moves through HAProxy, different stages of processing are handled by short-running functions called tasks. HAProxy's task scheduler determines which task will run next on each thread based on each task's priority and urgency. This release includes some enhancements to the scheduling mechanisms that address inconsistencies in wake, queueing, and prioritization behavior for tasks. These are edge cases that surface under sustained attack traffic or recovery scenarios. Testing confirms reduced latency when processing large queues of tasks and improved responsiveness of the HAProxy Runtime API.

Stats page counters

A new directive, stats calculate-max-counters, controls whether stats max counters are computed. Counters in this category include the max connection rate per second, max session rate per second, and max request rate per second.

Calculating maximums requires an expensive coordination between all threads, and in practice, virtually nobody uses it anymore since it only lasts for the process's lifetime; today, users have external solutions that collect stats and calculate maxes over periods of time instead.

This directive is enabled (on) by default; it may be set to off to disable these counters and save resources.

Automatic CPU binding

HAProxy 3.2 introduced options for tuning the automatic CPU binding, or how HAProxy organizes its threads to make efficient use of the underlying hardware. Version 3.4 adds a global keyword, cpu-affinity, that enables more control over how the threads bind to CPUs. HAProxy organizes its threads based on system topology and assigns  each thread group a set of CPUs; threads in a group are only allowed to run on those CPUs.

On NUMA systems, this keeps inter-thread operations within physically adjacent CPUs to reduce latency. The default, per-group, lets any thread in a group run on any CPU assigned to that thread group. While this offers the most OS flexibility in scheduling, this may not always be the best choice for latency. The options for cpu-affinity allow changes to this behavior:

• per-core: a thread may run on any hardware thread of a single SMT core (typically two threads per core in modern SMT implementations). The OS retains flexibility in scheduling IRQ activity. For example, from the NIC. HAProxy's threads can run on either hardware thread, keeping latency between HAProxy and the NIC low.

• per-thread: each thread will be bound to a single, specific hardware thread. Stricter than per-core, which permits movement between the hardware threads of a core.

• per-ccx: on systems with multiple CCX, such as AMD EPYC, this setting allows each thread to run on any hardware threads within all the cores of a single CCX.

There is an additional loose option for cpu-affinity per-group (cpu-affinity per-group loose). When a set of CPUs must be split over several thread groups, this allows multiple thread groups to use all CPUs in the list without each thread group being confined to a specific subset of the CPUs. The default, auto, which prevents this sharing by assigning each group to its own subset of CPUs, is usually the better choice. However, loose can perform better when CPU usage is uneven across groups.

This release adds a new threads-per-core option for the cpu-policy global directive, accepting a value of either 1 or the default, auto. Setting the value to 1 constrains HAProxy thread to a single thread per core on SMT-enabled CPUs (such as those implementing Intel's Hyper-Threading), leaving the other thread of the core free for other usage, most commonly the NIC. Improved performance has been observed in situations where there is high network activity on the same CPUs or during periods of frequent reloads that result in multiple HAProxy processes remaining active for extended periods of time. With the default auto setting, HAProxy creates a thread per each hardware thread. When threads-per-core is set to 1 and no explicit cpu-affinity value is set, the affinity defaults to per-core.

The following examples illustrate common configurations.

Intel Xeon with 64 cores with SMT (Hyper-Threading) enabled, where HAProxy will use one thread and the NIC may use the other thread of the same cores:

The next example involves AMD EPYC with 4 cores per CCX, where each thread in a group may use all hardware threads within a single CCX:

A new global option, max-threads-per-group, sets the maximum number of threads permitted in a single thread group. HAProxy defines the number of thread groups automatically based on the underlying hardware, and any tuning directives, including cpu-policy and cpu-affinity. On NUMA systems, this value often corresponds to the number of CPUs per CCX, and on systems with a single, unified L3 cache it corresponds to the total number of available cores. Setting max-threads-per-group provides fine-grained control. A higher number of threads in a group can introduce contention, while a lower number can increase the number of sockets required. Internal testing identified 16, the default, as the best overall tradeoff across the majority of systems.  

Before adjusting these defaults, it is recommended to evaluate the  system’s CPU topology, NUMA characteristics and NIC configurations. The performance tuning guide provides a step-by-step reference.

HTTP/2 performance

New global directives help mitigate HTTP/2 protocol attacks:

• tune.h2.fe.max-frames-at-once – Sets the maximum number of HTTP/2 incoming frames processed at once on a frontend connection. Typically, you can leave this at the default value.

• tune.h2.be.max-frames-at-once – Sets the maximum number of HTTP/2 incoming frames processed at once on a backend connection. Typically, you won't change this.

• tune.h2.fe.max-rst-at-once – Sets the maximum number of HTTP/2 incoming RST_STREAM frames processed at once on a frontend connection. A low value (1 to 10) is effective for sites that face frequent RST-based attacks. Note that very low values, such as 1, which are the most effective at erasing the impact of such attacks, might slightly increase the perceived latency on highly-interactive sites or gRPC services. 

• tune.h2.fe.max-total-streams – Sets the maximum number of HTTP/2 streams in total processed per incoming connection. Once the limit is reached, the connection will be recycled. This curbs the ability of misbehaving clients to flood connections. Values around 1000 are already very effective without observable impact for the user.

• tune.streams-elasticity – Defines a target percentage of streams per frontend connection relative to the maximum number of concurrent connections (maxconn) when all connections are established. As the number of concurrent connections grows, the number of per-connection concurrent streams is reduced, dynamically redistributing unallocated streams over existing connections. The result is that the service remains highly responsive at moderate loads and resists overload under extreme loads, while maintaining reasonable resource usage.

Additionally, the global tune.h2.fe.max-concurrent-streams directive, which sets the maximum number of HTTP/2 concurrent streams per incoming connection, now accepts two new arguments: rq-load and min. The rq-load argument dynamically adjusts concurrency based on the executing thread's run-queue load. The min argument sets a floor on the advertised concurrency level when using rq-load, even if this results in a higher load than the configured target.

Reusing idle server connections

The new global directive tune.idle-pool.shared enables sharing idle server connections across threads. Idle connection reuse is a valuable optimization in most deployments, and this directive provides explicit control over the behavior. Accepted values are on (share connections between threads in the same thread group), full (share across all threads), and off (disable sharing entirely, useful for debugging a connection reuse issue). This new directive deprecates tune.takeover-other-tg-connections, which was introduced in version 3.2 and served a similar purpose.

HATerm

The HAProxy GitHub repository now includes haterm, a lightweight HTTP server built on HAProxy. It’s intended for benchmarking and other exercises that require a simple, configurable HTTP server with options for customizing its internal configuration and behavior. 

It's the successor to the earlier httpterm utility, which was HTTP/1 only and lacked SSL support. This new utility supports H1/H2/H3 over QUIC, TCP and SSL, and benefits from HAProxy's scalability under extreme load. A complementary client, haload, is under active development and will be released soon to replace h1load.

Learn more in the HATerm documentation.

Security and TLS

JSON Web Tokens

This release adds new options for validating JSON Web Tokens (JWTs). HAProxy can now decrypt JWE tokens natively at the proxy layer, enabling inspection of encrypted JWT claims before routing or access decisions.

• The global directive jwt.decrypt_alg_list defines a colon-separated list of permitted algorithms in tokens decrypted by the jwt_decrypt_* converters. This enables you to reject tokens that use an unsupported algorithm for the alg parameter.

• The global directive jwt.decrypt_enc_list defines a colon-separated list of permitted encryption algorithms in tokens decrypted by the jwt_decrypt_* converters. This enables you to reject tokens that use an unsupported encryption algorithm for the enc parameter.

• The converter jwt_decrypt_cert performs asymmetric decryption with ECDH-ES with EC certificates. When provided a certificate, the converter returns the decrypted contents of the JWT input sample.

• The converter jwt_decrypt_secret, when provided with a base64-encoded secret, returns the decrypted contents of the JWT input sample.

• The converter jwt_decrypt_jwk, when provided with a JSON Web Key, returns the decrypted contents of the JWT input sample following the JSON Web Encryption format.

AES CBC converters

This release adds new converters relating to AES CBC encryption and decryption, supporting token manipulation, payload masking, and secure session handling natively in HAProxy.

• The aes_cbc_dec converter decrypts the raw byte input using the AES128-CBC, AES192-CBC, or AES256-CBC algorithm, depending on the bits parameter.

• The aes_cbc_enc converter encrypts the raw byte input using the AES128-CBC, AES192-CBC, or AES256-CBC algorithm, depending on the bits parameter.

Enhanced ACME features

HAProxy is an early adopter of a new way to validate domain ownership through the ACME protocol for TLS certificate issuance. The DNS-PERSIST-01 challenge works by publishing a TXT record in your DNS server that contains the CA name and ACME account ID to serve as proof of domain ownership and, subsequently, authorizes issuing a TLS certificate. Contrary to DNS-01, which requires periodic updates of the challenge in the DNS record, DNS-PERSIST-01 permits setting a persistent record, so is more suitable for DNS zones managed manually, where rotating a record at each renewal isn’t practical. Rollout of this new challenge type is ongoing at providers like Let's Encrypt with wider availability expected later this year.

Also in this release, the acme configuration section has a new directive, challenge-ready, that sets how HAProxy can determine if the TXT record of a DNS-01 challenge is ready. The available options are:

• dns instructs HAProxy to resolve the TXT record to ensure that it's ready. 

• cli instructs HAProxy to use an external tool to check DNS. 

• delay instructs HAProxy to add a delay period.

• none instructs HAProxy to proceed with validation immediately.

The defaults are sensible for most deployments, so this directive can usually be left unset. Two complementary directives tune the active modes: dns-delay sets the delay wait period under delay, and dns-timeout sets the maximum resolution time for the TXT record under dns.

The acme configuration section also introduces a profile directive that implements the ACME Profiles extension. An ACME profile indicates the type of certificate to request from the certificate authority; valid options are determined by the profiles offered by the CA. For example, Let's Encrypt offers several ACME profiles.

In addition, this release supports the inclusion of IP addresses in the Subject Alternative Name (SAN) field of ACME-issued certificates, configured via the ips argument on the load directive within a crt-store section.

HAProxy 3.4 further introduces support for ACME EAB (External Account Binding), which aims to protect ACME accounts against unauthorized access. You can configure EAB through the following directives:

• eab-key-id – Configure the path to the EAB key ID file. The credential is provided by the CA and must be placed at the specified path before starting HAProxy. It's used during account creation only.

• eab-mac-key – Configure the path to the EAB MAC key file. The credential is provided by the CA and must be placed at the specified path before starting HAProxy. It's used during account creation only.

• eab-mac-alg – Configure MAC algorithm used for EAB signing. The default is HS256. The EAB MAC key must be large enough to support the specified MAC algorithm. Not all CAs support algorithms other than HS256.

TLS dummy certificate

HAProxy can now generate a self-signed TLS certificate directly, which can be useful in testing and scenarios where certificates might become available only after HAProxy has started. The following arguments are available on the load directive within a crt-store section:

• generate-dummy – Sets a self-signed certificate and private key.

• keytype – Sets the type of key, either RSA or ECDSA.

• bits – Sets the number of bits to use for RSA certificate generation.

• curves – Sets the elliptic curve to use for ECDSA certificate generation.

TLS certificate compression

HAProxy now supports TLS certificate compression as defined by RFC 8879. The new global directive tune.ssl.certificate-compression governs the feature. The default value, auto, follows the configuration of the underlying TLS library, while a value of off disables compression entirely. Compressing certificates exchanged between clients and HAProxy reduces transferred bytes and can lead to latency improvements.

Decrypting TLS 

This release simplifies decrypting TLS during debug sessions by introducing variables that return the properties required to create a keylog file. Previously, you had to combine several variables into a log format string to produce the keylog output. Two new consolidated variables, HAPROXY_KEYLOG_FC_LOG_FMT and HAPROXY_KEYLOG_BC_LOG_FMT, can be referenced directly in a log format.

Reliability

HTTP/1 glitches

Two updates affect HTTP glitch detection:

• HAProxy 3.4 expands the glitch detector to include the HTTP/1 multiplexer. Previously, only HTTP/2 and QUIC were covered.

• When HAProxy is configured to terminate connections that have too many glitches, it will now try to gracefully close the connection upon reaching 75% of the configured threshold rather than waiting until the limit is reached. Frontend and backend thresholds are set with tune.h1.fe.glitches-threshold and tune.h1.be.glitches-threshold.

HAProxy 3.0 introduced the concept of glitches. The term refers to unusual HTTP messages that could cause problems in the infrastructure if handled. Glitches might signal a malfunctioning client or server, or in some cases it may indicate a protocol attack. Several of the recent HAProxy releases have steadily expanded the glitch detector: the fc_glitches and bc_glitches fetches return the number of glitchy requests and responses; glitch_cnt and glitch_rate stick table data types make it possible to track glitches over time; and global options can terminate connections that exceed a configured glitch threshold. Expanding this functionality to HTTP/1 rounds out this helpful feature.

Health check section

A new healthcheck section promotes defining reusable health-check directives. Directives declared in a healthcheck section are applied to a server via the healthcheck argument on the server line, as shown below:

Better random algorithm

The random load balancing algorithm, which became the default in version 3.3, replacing roundrobin, now provides improved traffic distribution. The algorithm selects two servers at random from the pool of available servers and chooses the least loaded server, with load measured by the concurrent connection count. 

When comparing servers with the same number of concurrent connections, HAProxy now also considers recent traffic history (HTTP requests per second). This produces a more even distribution across large backend pools where many servers sit at identical connection counts. HAProxy can then make a more informed choice when selecting a server.

Fetching the HTTP version

HAProxy 3.4 standardizes the retrieval of the HTTP protocol version associated with a request or response.

Identifying the HTTP version is non-trivial, as HTTP/1, HTTP/2, and HTTP/3 each indicate their versions differently. HAProxy provides several fetches for this purpose, such as req.ver, res.ver, capture.req.ver, and capture.res.ver, but coverage across protocol versions has been inconsistent. In this release, these fetches operate uniformly across all supported HTTP versions. Both req.ver and res.ver return the version as major.minor; the capture variants return HTTP/major.minor.

Prometheus local update metric for stick tables

The HAProxy Prometheus endpoint exposes stick table metrics whenever a stick table is declared in the configuration. HAProxy 3.4 adds a stick table metric named haproxy_sticktable_local_updates. This gauge reports the cumulative number of updates on the stick table, allowing you to monitor the rate of updates over time.

HTTP/2 error logs

While having comprehensive logging is essential, controlling the volume of logs is also important. A new global directive named tune.h2.log-errors defines the scope of error logging for HTTP/2 traffic, accepting values of stream, connection, or no error. The default, stream, is the most verbose. Having the ability to adjust this setting as needed lets you favor efficient resource use while preserving the option to increase verbosity when required.

Debugging

The global directive set-dumpable supports a new value, libs, which instructs HAProxy to embed a copy of the binaries and libraries required for debugging into the resulting core dump. This eliminates the need to locate these files on the filesystem after the fact and removes the risk that they don't match the core. You can then extract the embedded libraries by using the libs-from-core tool, which is published in the HAProxy GitHub repository.

Also, the show profiling HAProxy Runtime API command now provides finer-grained information about runtime memory consumption when invoked with the memory argument, thanks to the notion of execution context.

Observability with OpenTelemetry

The new OpenTelemetry filter allows HAProxy to generate spans (the individual units of work that make up a distributed trace) alongside logs and metrics, all in the standard OpenTelemetry format. This makes each request's journey through the load balancer directly consumable by any OTLP collector over gRPC, HTTP endpoints, or local files.

HAProxy's event subsystem provided the architectural groundwork for this integration, enabling fine-grained hooks into the load balancer's inner workings.

OpenTelemetry is the industry standard for distributed observability. By adopting it, HAProxy can now surface telemetry data in the same unified view as the rest of the stack, providing full visibility into the many steps a request undergoes as it traverses the infrastructure — without the need for custom integrations or proprietary SDKs.

Enabling the feature requires a new filter opentelemetry directive. The integration is controlled by two configuration files that define which HAProxy events are subscribed to and the endpoints to which telemetry data is forwarded.

Events can be enriched with key-value attributes, custom log messages, and ACL conditions to filter which events are captured. 

The OpenTelemetry client library is experimental and ships as a separate add-on via the haproxy-opentelemetry repository and must be compiled into HAProxy to be enabled. The GitHub repository has build instructions and documentation. Configuration tutorials are coming soon.

New fetch methods in this release are as follows:

New converters in this release are as follows:

HAProxy 3.4 deprecates these features:

• The compression-direction directive is deprecated.

• OpenTracing is deprecated in version 3.4 and will be removed in 3.5.

Breaking changes

HAProxy 3.4 has the following breaking changes:

• The Stats page won't display the HAProxy version, but it can be enabled by using stats show-version.

Conclusion

HAProxy 3.4 introduces a dynamic backend system that streamlines operation in modern architectures, smarter buffer allocation, measurable throughput gains, native JWT decryption and AES processing at the proxy layer, and native OpenTelemetry support — alongside operational improvements in health checking, attack resistance, and log management.

Ready to upgrade or make the move to HAProxy? Now’s the best time to get started. You can install HAProxy 3.4 in any of the following ways:

• Install the new HAProxy packages for Ubuntu, Debian, and RHEL.

• Run it as a Docker container. View the Docker installation instructions.

• Compile it from source. View the compilation instructions.

In a presentation at HAProxyConf, Austin Ellsworth, Infrastructure Manager at Weller, shared how he leads the team responsible for servers, storage, firewalls, and networking. His goal was to ensure that infrastructure never gets in the way of the business.

That goal led him to a months-long project centered on the HAProxy One application delivery and security platform. By leveraging HAProxy Enterprise load balancer for high-performance application delivery and HAProxy Fusion Control Plane for centralized management and observability, Ellsworth established an active-active data center architecture capable of failing over in under a second.

Weller’s primary users are its own associates. Employees use virtual desktops to log into the enterprise resource planning (ERP) system, take orders, and manage production. When something goes wrong, the people on the floor feel it immediately.

Traditional data center disaster recovery treats the secondary site as a cold standby. Backup appliances are "easy to go out and buy," and storage replication is simple to set up, but spinning up a workload after a disaster could take as much as four hours. For Weller, the reality of this previous cold-site approach meant that if the primary site went down, the business could wait hours for a full recovery.

Ellsworth knew this setup would not deliver the most value. “I didn’t really feel that that was an efficient use of our resources,” he said. “I didn’t think we were netting our company the most profit or serving our users the best.”

He wanted to move every application he could to an active-active model, where both data centers ran identical workloads simultaneously. The only problem was with routing. If both sites were live, something had to decide where to send users and how to react when a site went down.

Choosing the right routing approach

When deciding on the best path forward, the team considered several options. VMware Site Recovery Manager and Zerto were on the table, but both tools worked more like recovery mechanisms than live traffic managers. Conducting a failover with those products still involves taking storage offline at one site and bringing it online at another before anything can run. That process takes time that the business did not have to spare.

DNS was briefly considered, but a colleague quickly talked Ellsworth out of it. Local DNS caches and propagation delays make it an unreliable tool for fast failovers.

The approach that made sense was Anycast BGP. Large companies use it to direct traffic at the network layer with no dependency on DNS and no manual switching. The routing table itself determines the path, and when conditions change, it updates.

That meant Weller needed a load balancer that could inject routes into the network based on the health of backend servers. HAProxy Enterprise, with its Route Health Injection (RHI) module, was the answer.

“HAProxy Enterprise was not only the fastest, but it also seemed like the easiest to configure," Ellsworth said.

Read more:

• How Criteo handles 23M requests per second (RPS)

• How PayPal hyperscaled Kubernetes routing

• Securing 80,000 transactions per second at Infobip

Building the active-active architecture

The implementation began by replacing a software-defined wide-area network (SD-WAN) solution and migrating all branch locations to next-generation firewalls. Every network component in both data centers runs open routing protocols, specifically open shortest path first (OSPF) and border gateway protocol (BGP), giving teams full control over traffic paths.

To speed up failure detection, the team enabled bidirectional forwarding detection (BFD). While HAProxy handles application-layer health checks, BFD covers physical network paths. Standard BGP can take up up to 180 seconds to detect a peer going down, but BFD brings that down to 100 milliseconds.

All applications, whether they had multiple backend servers or just one, were positioned behind HAProxy Enterprise. Even single-server deployments benefited from route health injection. If that server goes offline, the route disappears, and traffic automatically shifts to the other data center.

Subsecond data center failover demonstrated live

Ellsworth ran an impressive live demonstration in Weller's production environment.

His demo script sent a GET request once a second to a web application behind HAProxy Enterprise. He disabled the connection servers on VMware Horizon, the company's VDI platform, and let HAProxy Enterprise's health checks detect the service-level failure. 

Within moments of the health check tripping, the RHI module stopped injecting the Grand Rapids route, signaling the network to withdraw the path. For immediate physical network or link-layer failures, the team paired this setup with BFD, which drops peer detection down to 100 milliseconds. Combined, these two layers ensured that traffic shifted to Indianapolis instantly

Not a single GET request was missed.

Employees connecting to virtual desktops were redirected to the secondary VDI pool, with all their user data intact and synchronized in real time using FSLogix Cloud Cache.

From the user's perspective, nothing happened.

The same shift in traffic can be achieved during planned maintenance. The team can now take a server offline during business hours, patch it, and bring it back up at the other site without scheduling overnight windows or asking anyone to stay late.

Managing the solution at scale with HAProxy One

To manage this infrastructure at scale, Ellsworth’s team runs HAProxy Fusion, which provides centralized management, observability, and automation for large-scale HAProxy Enterprise deployments. With HAProxy Fusion, all HAProxy Enterprise nodes across both data centers are managed from a single interface, with log data aggregated in a single location.

“It simplifies your life,” Ellsworth said.

HAProxy Enterprise and HAProxy Fusion are part of HAProxy One, the world’s fastest application delivery and security platform. For Weller, the combination means a high-performance data plane at each site and a unified control plane to manage and monitor everything across both.

Small team, big ROI

Ellsworth ran the numbers on what an equivalent cloud deployment would cost. His estimate came out at $90,000 to $100,000 a month in compute alone, which would be enough to rebuy the on-premises hardware twice a year. The ROI case, he said, was straightforward.

All this was possible with only a small team. Ellsworth and a team of four physically visited all of Weller's branch locations, swapped network hardware, migrated subnets, deployed the load balancers, and tested applications. They completed the entire rollout in under six months.

"You don't have to be a giant organization to be able to deploy something like this," Ellsworth said. "And you don't have to be massive to benefit from it either."

The result is world-class application delivery infrastructure that automatically handles failures, patches during business hours, and scales cleanly. 

Want to see what subsecond data center failover looks like for your own infrastructure?

Request a demo.

FAQs

What is a data center failover?

Data center failover is the automatic redirection of traffic from a primary data center to a secondary one when the primary becomes unavailable. Traditional approaches treat the secondary as a cold site that takes hours to spin up. Active-active failover, by contrast, runs identical workloads at both sites simultaneously and shifts traffic in seconds or, as Weller Truck Parts demonstrated, in under a second.

How is data center failover different from an outage?

An outage is the underlying failure, while a failover is the engineered response that keeps that failure from reaching the user. The distinction matters because most infrastructure investment focuses on preventing outages, when the real measure of resilience is how quickly the system absorbs one. Done well, failover means an incident at one location never becomes an incident for the business.

How do you test data center failover?

The only credible test is a live one in production. At HAProxyConf, Weller demonstrated this directly: a script sending one GET request per second against a live application while the team disabled the primary site. HAProxy Enterprise health checks caught the application failure, the Route Health Injection module withdrew the route from the BGP table, and traffic shifted to the secondary data center. Not a single request was missed. Pairing scripted synthetic monitoring with planned production failovers is how teams confirm the architecture behaves the way the diagram promises.

What's the biggest challenge with data center failover?

Routing. Storage replication and backup tooling are mature and easy to buy. The hard problem is deciding where to send users when both sites are live and reacting quickly enough when one fails. DNS is unreliable for fast failover because of caching and propagation delays. Recovery products such as VMware Site Recovery Manager and Zerto are designed for disaster recovery, but not for live traffic management. Anycast BGP solves the routing problem at the network layer, which is why Weller built its architecture around it.

A few hours later, Proof of Concept exploits began surfacing on GitHub. We tested several variants of publically available PoCs, along with in-house developed PoCs, against the HAProxy Enterprise WAF. Our web application firewall (WAF) was engineered from the ground up for high performance and does not rely on conventional attack signatures. As a result, it frequently blocks zero-day exploits without requiring any updates, with this particular Drupal vulnerability being just the latest example.

Issue details

Drupal websites configured to use a PostgreSQL database are exposed to a flaw in which an attacker can craft a request that injects malicious values into array keys of specific filters, such as those used by JSON:API.  Drupal passes the keys to the database layer without proper sanitization, resulting in SQL Injection. 

Affected versions

Drupal 11

If you use Drupal 11.3.x, update to Drupal 11.3.10.
If you use Drupal 11.2.x, update to Drupal 11.2.12.
If you use Drupal 11.1.x or 11.0.x, update to Drupal 11.1.10.

Drupal 10

If you use Drupal 10.6.x, update to Drupal 10.6.9.
If you use Drupal 10.5.x, update to Drupal 10.5.10.
If you use Drupal 10.4.x or earlier, update to Drupal 10.4.10.

Drupal 9 and 8

If you use any version of Drupal 9, try manually applying the Drupal 9.5 patch for this issue.
If you use Drupal 8.9, try manually applying the Drupal 8.9 patch for this issue.

The official patch illustrates both the root cause and the condition under which the vulnerability is triggered.

Recommended actions

Customers using the HAProxy Enterprise WAF are already protected and do not need to update or modify their rules.

This screenshot from the HAProxy Fusion Control Plane Request Explorer shows that the HAProxy Enterprise WAF detects and blocks the attack:

Let’s be real: building reliable tech products is hard. Modernizing that same tech without compromising the user experience is even harder. The "rip and replace" approach to modernization can severely disrupt your customers’ integration efforts and workflows. When it doesn’t work, reversing course might be the least-worst option. 

By contrast, the evolution of the HAProxy One application delivery platform architecture at HAProxy Technologies over 25 years has been gradual and consistent. This approach has yielded a mature platform that has stood the test of time. Its modern control-plane/data-plane architecture makes application delivery and security fully programmable, with automation and Infrastructure as Code (IaC) built in. 

1. The challenge of modernizing the control plane and data plane

Application delivery, like any traffic management and routing system, divides cleanly into distinct layers: the “data plane” and “control plane.” The data plane handles the heavy lifting, forwarding packets, load balancing, and encrypting traffic. The control plane makes the decisions and exposes them through the API and UI.

Traditional architecture integrates the control plane and data plane into a single appliance. However, modern architectures tend to separate control plane and data plane components. A centralized control plane can be used to manage a distributed data plane for greater scalability and simpler management. 

Since these architectures require very different approaches, re-architecturing an integrated appliance into a distributed control-plane/data-plane can be incredibly complex (if not impossible). While it might be tempting to start from scratch by building an entirely new platform, this comes with its own cost in customer adoption and reintegration.

At HAProxy Technologies, we have pursued a different path with a gradual and consistent approach to product development, and the progressive addition of programmatic management to extend the platform’s capabilities and simplify operation.

2. The path to authoritative central control

From our open source products (HAProxy, HAProxy Data Plane API, HAProxy Kubernetes Ingress Controller, and HAProxy Unified Gateway) to our HAProxy One platform for enterprise customers (including HAProxy Enterprise load balancer, HAProxy Fusion Control Plane, and HAProxy Edge), we have gone from standalone proxies to an authoritative control plane and data plane without re-architecting the core technologies. It's the kind of evolution that's only possible when you consistently build on the fundamentals.

A philosophy of building blocks, not band-aids

Our evolution is rooted in the philosophy that has guided HAProxy’s development from the beginning and infuses both our open source products and enterprise platform. 

Willy Tarreau, who wrote HAProxy’s first source code and now serves as CTO and lead developer, has always held a fierce commitment to the community and an understanding that the critical attributes of performance, reliability, and flexibility must be prioritized evenly so that the product is well-balanced and not compromised in any one area. 

Crucially, Willy’s approach to product development was never about delivering a single, bespoke feature. Instead, sound product development meant creating the flexible, high-performance building blocks that would enable that feature and many others besides, refined by robust community feedback.

This foundational philosophy – prioritizing performance, reliability, flexibility, and community – has always been the DNA of HAProxy Technologies. Our long-term commitment to this approach has enabled us to continuously deliver the building blocks of progressive programmability, and is the reason why we are uniquely positioned to manage modern complexity without disruption.

The foundational data plane of HAProxy 

Since its first release in 2001, the open-source HAProxy has been the de-facto standard reverse proxy and load balancer, known for its performance, reliability, flexibility, and security.

HAProxy is a trusted foundation on which the world's leading companies build the most demanding applications. Our focus on the core data plane is our starting point, and the reason we have never had to abandon our past to build for the future.

From the beginning, HAProxy has used file-based configuration. Administrators would connect via SSH to an HAProxy instance, make changes to the config file, then reload HAProxy to apply the changes. Simple, direct configuration management. That was true then, and it’s still true today. However, this method was designed primarily for manual use and not for automation driving configuration at scale.

As application delivery grew more complex, the need for greater programmability in the data plane became essential. Rather than start over with a new platform, we built a native, programmable interface directly in HAProxy. 

Early versions of HAProxy made certain parts of the HAProxy configuration and operations more dynamic, with in-memory changes. In 2016, these capabilities were combined and enhanced to form the HAProxy Runtime API, providing robust, general-purpose programmability. 

This development enabled real-time configuration changes and fine-grained control over everything from SSL certificate management to debugging metrics, without dropped connections or downtime, which our customers continue to appreciate. 

This was a principled first step: we built the ability for the data plane to be dynamically controlled from within. This approach ensured that any future external control layers would work with a data plane that was designed, in its very fabric, to be orchestrated. What’s more, the HAProxy Runtime API continues to evolve as we extend dynamic, in-memory programmability to cover more of HAProxy’s capabilities, as well as the new capabilities available in each release.

With the HAProxy Runtime API providing dynamic control over in-memory changes, the next crucial step was to provide programmatic management of the HAProxy configuration file itself. This HAProxy Native Client, which launched in 2017, exposes methods for programmatically reading and changing HAProxy configuration files, allowing for the management of the persistent configuration state. 

This capability was pivotal because it allowed automation engines to manage the configuration without requiring manual SSH access or a full product reload.   

We made a deliberate and strategic choice: we released this core capability as an open-source library. This decision was a direct reflection of our commitment to the community, ensuring flexibility and programmatic access were available to all. 

The HAProxy Native Client was the key component that enabled us to move on to the next step (the HAProxy Data Plane API). It also provided the flexibility needed to launch new products, such as the HAProxy Kubernetes Ingress Controller. The HAProxy Native Client dramatically extended HAProxy’s programmatic flexibility in the cloud-native era.

Automating HAProxy with HAProxy Data Plane API

With the HAProxy Runtime API providing internal control, and the HAProxy Native Client providing configuration management, the next logical step was to create a robust, programmatic bridge for external systems. The open-source HAProxy Data Plane API, which launched in 2019, operates as a sidecar to HAProxy, fully incorporates the HAProxy Native Client, and provides a RESTful interface to programmatically configure HAProxy instances at scale. The HAProxy Data Plane API is conformant with the OpenAPI Specification (OAS), which enables users to interact with the API with any common coding language via a generator.

It allows administrators to use simple HTTP calls to configure and update HAProxy, instead of using SSH to connect directly to the HAProxy instance. This allows for programmatic remote management of both the HAProxy configuration file (for persistent changes) and the HAProxy Runtime API (for dynamic, real-time changes) through a single interface.

The HAProxy Data Plane API also removes complexity: it validates input, decides whether HAProxy needs to be reloaded, minimizes interference with user traffic, and can manage map files, ACL files, and SSL/TLS certificate files.

This API was the key to empowering modern automation, allowing users to manage their application delivery infrastructure dynamically through CI/CD pipelines, orchestration tools, and Infrastructure-as-Code (IaC) platforms. It brought our battle-tested data plane fully into the dynamic, multi-cluster environments that were rapidly becoming the standard.

The final and most powerful management layer in our architectural journey is the HAProxy Fusion Control Plane. HAProxy Fusion is the authoritative control plane that provides centralized management, observability, and automation for a distributed HAProxy Enterprise data plane across multi-cluster, multi-cloud, and multi-team environments.

HAProxy Fusion itself is an API, enabling automation via scripts and other control systems, as well as integration with third-party services, infrastructure layers, and data providers. For example, service discovery for Kubernetes and Consul can be used to generate HAProxy configuration for automated traffic routing for dynamic servers, while Ansible Playbooks and a Terraform Provider enable full-lifecycle automation.

HAProxy Fusion extends programmability to HAProxy Enterprise's full security stack: the Threat Detection Engine, WAF, ACLs, Global Profiling Engine, and more. This is managed through Security Profiles (customizable policies deployable in a few clicks) and the Threat-Response Matrix (a visual policy builder requiring no HAProxy configuration expertise).

This successful control-plane/data-plane architecture enables modern solutions such as Load-Balancing-as-a-Service (LBaaS), sovereign edge security, and automated traffic management for blue/green application deployments. 

Critically, all of this is built on a shared, first-party code base, ensuring seamless integration and authoritative support that simply isn't possible with a collection of disparate, acquired technologies. 

The launch of HAProxy Fusion empowered our users and extended the capability set available to them. In fact, we planned this milestone many years in advance, starting with the HAProxy Native Client. The excitement among our users, and the rapid adoption of HAProxy Fusion in real customer deployments, proves that we made the right choices, and gives us confidence that building with and for our community is always the right path forward.

To make it as simple as possible to deploy and manage these products, and to consolidate all the architectural advances, we've arranged the three key layers of our enterprise products into a single platform called HAProxy One. The platform consists of a flexible data plane (HAProxy Enterprise), a scalable control plane (HAProxy Fusion), and a secure edge network (HAProxy Edge).

Meanwhile, HAProxy Edge (which processes billions of requests per day for our ADN customers) produces global threat intelligence, enhanced by machine learning, to power the security layers in the control plane and data plane. This includes the HAProxy Enterprise Bot Management Module (powered by the Threat Detection Engine) and the HAProxy Enterprise WAF (powered by the Intelligent WAF Engine). 

HAProxy One’s intelligent integration between its components provides class-leading threat mitigation and centralized control, with the flexibility to deploy the data plane in any environment. Crucially, with this model, administrators have complete control of their infrastructure from deployment and ecosystem integration to updates and security settings.

Summary

3. The approach that powers customer success

First-party authority, seamless integration

Our most significant advantage is a matter of core principle: we're authoritative on all of our components. Our data plane, control plane, and edge network work together because they are built from the same DNA and maintained by the same team. We own the entire stack, which allows us to provide unparalleled support, integration, and optimization.

A consistent approach to product development

We built new capabilities to seamlessly extend our existing, trusted foundation. We started with our core data plane, then built programmatic APIs, and finally built a control plane on top. Our path was incremental and non-disruptive, adapting as much as possible to customer environments and habits. This has allowed our existing customer base, which includes the world's leading companies, to adopt new capabilities without starting from scratch.

Real-world validation

The power of our architecture is visible in the success of our customers, as showcased at HAProxyConf 2025. HAProxy Fusion serves as an enabling technology that allows these customers to creatively design and implement solutions optimized for their specific needs:

• PayPal uses HAProxy Fusion to manage dynamic service discovery for tens of thousands of Kubernetes backends, and to create a universal mesh across multiple public clouds, resulting in a 24% reduction in latency.

• Clover uses HAProxy Fusion to manage a "rainbow deployment" strategy with a service mesh, demonstrating the platform’s advanced traffic management and automation.

• Dartmouth College uses HAProxy Fusion to enable Load-Balancing-as-a-Service (LBaaS), empowering application teams to self-service their delivery needs within guardrails set by the infrastructure team.

Additionally, the integration between HAProxy Edge and the security layers in HAProxy Enterprise enables customers to build their own edge to secure millions of requests per second.

• Roblox uses HAProxy Enterprise WAF to provide ultra-low latency protection against application attacks, with no impact on resource consumption.

• Infobip uses HAProxy Enterprise WAF to significantly reduce false positives and set up new applications without fine-tuning WAF rules.

4. Vision for the future

Our commitment to the cloud-native ecosystem is underscored by the HAProxy Fusion Operator, which brings the full control plane natively into Kubernetes clusters. This joins the HAProxy Unified Gateway, which will unify Gateway API and Ingress-based traffic management together in a single component, available now as a standalone open source product (v1.0) and to be incorporated into HAProxy Fusion for managing multiple Kubernetes clusters and Gateway classes.

The official Terraform Provider and enhanced Ansible Playbooks for HAProxy Fusion make IaC workflows easily achievable for application delivery: the same configuration objects that administrators once managed manually over SSH can now be declared, version-controlled, and deployed reproducibly at scale.

In our relentless drive to push performance boundaries, we announced the adoption of a modern high-performance SSL/TLS library and performance optimizations for massively multi-core systems.

Finally, we continue to dream big! With the power of centralized control and ML/AI automation, HAProxy Fusion and HAProxy Edge have the potential to unlock more revolutionary capabilities and use cases. Subscribe to our blog to be the first to know what’s next.

A modern application delivery platform, built to last

Core architectural decisions are supremely important. We're reminded of this when even big companies face dead ends, cancellations, and costly reversals with their products. 

HAProxy Technologies, through a gradual and consistent evolution, has built a modern platform that's authoritative, forward-looking, and trusted by the world's leading companies and cloud providers to deliver the most demanding applications.

The difference isn't only what you build, but how you build it. Our foundational data plane, our programmatic APIs, and our authoritative control plane with next-gen security orchestration represent an elegant and unified solution to the challenges of modern application delivery and serve as the platform for innovation by our customers. 

In 2026, HAProxy celebrates its 25th anniversary. It was always built to last, and will continue to be. Here’s to the next quarter-century.

Schedule a demo with our experts to see how HAProxy One can simplify your app delivery at scale.

As the largest independent AdTech company, Criteo processes 9 billion bid requests every day across three continents and six data centers. Their infrastructure is built on bare-metal hardware, with over 30,000 servers. This scale requires an infrastructure that moves beyond manual configuration. To manage the massive flow of traffic, Criteo transitioned from vendor-locked hardware appliances to a fully automated Load Balancing as a Service (LBaaS) platform built on HAProxy.

Handling 1 terabit per second across six data centers means any change to the system must be efficient. Criteo moved away from traditional configuration management and made the HAProxy Runtime API the primary interface for all operational changes. This allows the infrastructure to scale and update without manual intervention.

The scale of the operation makes this approach necessary. Because certificates and backends must be continuously updated and scaled, the system requires a high level of automation. If these events required manual work or process restarts, the overhead would quickly add up.

To avoid this, Criteo designed a system where the configuration remains static while the internal state of the load balancer changes dynamically. This shift removes the operational cost associated with high-frequency updates.

Automating TLS certificate management

The team uses a three-part system to handle these updates. 

1. The certificate provider microservice manages the lifecycle and communicates with external authorities.

2. A control plane pulls renewed TLS certificates and sends updates to provisioners.

3. These provisioners run locally on the load balancer nodes to update HAProxy.

The provisioners use the HAProxy Runtime API to modify TLS certificates in memory. This process involves a four-step transaction. The system allocates a new certificate, sets its contents, commits the transaction, and adds it to the list. This method allows Criteo to renew roughly 100 certificates daily without manual config updates.

This architecture ensures that the file system and the running process stay synchronized. If a node restarts, it loads the latest certificates from disk. This automation helps address the industry trend toward shorter certificate lifespans, with proposals to reduce validity to as little as 47 days.

Dynamic server provisioning for rapid autoscaling

Criteo operates over 100,000 containers across Kubernetes and Apache Mesos clusters. Application instance counts fluctuate significantly throughout the day. One application may grow from 115 instances to 600 in a few hours.

Modern infrastructure requires a way to add and remove these backends instantly. Criteo uses dynamic servers introduced with full support in HAProxy 2.5 to manage these changes. Dynamic servers allows the team to provision and delete servers on the fly.

Named servers are a practical benefit of this approach. Where older server templates used generic indexes like srv1 and srv2, dynamic provisioning gives each server a unique, descriptive name in the logs, making it significantly easier to trace errors to a specific container during an incident.

Removal follows a deliberate sequence: disable the server, drain active sessions, wait for the short "removable state" window, then delete. This prevents dropped requests during autoscaling and preserves consistent hashing for Criteo's Varnish cache layer, ensuring requests for a given path always reach the same cache node.

Aligning software threads with CPU hardware

Data travels much faster between cores on the same chiplet than it does across the I/O die. The latency for data sharing increases significantly when a thread moves from one die to another. To solve this, Criteo uses new CPU policy features to group threads logically.

The team uses the group-by-2-clusters policy to bind HAProxy threads to the physical layout of the AMD chip. This keeps related threads on the same core complex, which helps the CPU share data more efficiently and reduces the need for the processor to move information across the entire chip.

Criteo’s tests showed that this configuration reduced context switching by 20%. This change frees up CPU cycles to handle actual request traffic. The team also binds management processes to a specific core to avoid interrupting the main load balancing threads.

Read more: How HAProxy takes advantage of multi-core CPUs

Key takeaways for your infrastructure

Criteo's journey shows what HAProxy can achieve when you treat it as a programmable engine rather than a static process: a platform that adapts to demand in real time, at any scale. As Criteo looks toward the future, they are working with the HAProxy team to implement even more dynamic features, including dynamic backends and frontends, to reach 100% automation.

For teams looking to build similar automation at scale — without building the control plane from scratch — HAProxy One makes this kind of infrastructure automation production-ready out of the box.