With over 3,200 combined AI use cases cataloged across the US and EU, public sector IT leaders face an identical roadblock: traditional application delivery controllers were not designed to parse or throttle Layer 7 LLM payloads, leading to backend GPU exhaustion.

Generative AI in the public sector introduces demands that traditional architectures were never built for: sensitive data flowing through inference APIs and strict audit requirements.

If you're in the public sector, see how HAProxy One handles government application delivery across on-premises, sovereign cloud, and air-gapped environments, with commercial products available to US buyers through authorized partners on Federal and SLED contract vehicles.

How is AI applied in the public sector?

Government agencies use AI for specific, already-deployed tasks. 

A few examples:

• Fraud detection. The Treasury Department uses machine learning to detect fraud in real time, and recovered over $4 billion in fraudulent funds during fiscal year 2024. Carahsoft

• Service chatbots. The IRS deployed a virtual assistant called "Ask IRS," built on Microsoft Azure AI, which handled over 3 million taxpayer questions in its first year and cut call center volume by 40%. SmartDev

• Document processing. The General Services Administration uses AI to help review procurement documents, which frees up staff for more strategic work. SmartDev

• Threat and anomaly detection, where models flag unusual network activity or suspicious transactions that a manual review would likely miss.

Agentic AI in the public sector

These examples share a pattern: a model flags something or answers something, and a person decides what happens next. Agentic AI removes that middle step. Instead of flagging an anomaly, an agentic system can investigate it. Instead of answering a question, it can complete the underlying task, such as processing a benefits application from start to finish with no human in the loop.

Securing sensitive data in AI inference APIs

Government AI handles some of the most sensitive data in existence: tax records, health histories, law enforcement intelligence, and defense communications. When that data moves through an inference API, it meets threats that ordinary web security was not designed to catch. In the EU, the General Data Protection Regulation (GDPR) raises the stakes further, requiring strict protection for any system that processes the personal data of EU citizens.

The endpoints themselves face a specific set of risks:

• Prompt injection that manipulates a model into leaking data or behaving unpredictably.

• Unauthorized access to inference endpoints, which exposes both model capabilities and the data sitting behind them.

• Model extraction, where an attacker sends repeated probing queries to reverse-engineer proprietary model behavior.

• Autonomous risk escalation: as agentic AI in the public sector spreads, a single compromised endpoint can trigger actions with no human in the loop.

Both the U.S. and the EU are answering with governance frameworks, including NIST's draft Cybersecurity Framework Profile for AI and the EU AI Act. Those frameworks set expectations; the delivery layer is where they actually get enforced.

HAProxy One application delivery platform enforces them through a web application and API protection (WAAP) stack. A web application firewall solution inspects requests and helps protect inference endpoints, achieving 99.65% balanced accuracy in an open source WAF benchmark. Meanwhile, bot management and protection identifies, classifies, and labels high-impact bot threats including application DDoS attacks, brute force attacks, web scrapers, and vulnerability scanners. For AI traffic specifically, an API gateway and AI gateway add rate limiting tied to API keys and token counts, which gives finer control than IP-based limits on their own.

HAProxy One runs consistently across on-premises, sovereign cloud, and air-gapped environments, giving government and public sector teams one security layer for AI services across the environments they operate in.

High availability for mission-critical AI services

Some government AI services cannot go dark. Disaster response coordination, real-time border monitoring, fraud detection across benefits systems, and emergency dispatch all fall into this category. When these systems stall, the cost is measured in public safety: in response times, and in people who can't reach the services they need.

Inference workloads make availability harder to guarantee. They are computationally heavy, and their latency swings with prompt complexity, model size, backend load, and concurrency. A delivery layer built for this kind of unpredictability keeps services responsive in a few concrete ways. Load balancing solutions spread inference requests across model replicas and continuously health-check the backends, rerouting traffic away from any instance that falters. HAProxy can run these health checks against specific endpoints, such as /health or /v1/models, to assess backend responsiveness and reroute traffic away from an overloaded GPU instance before requests start timing out. SSL/TLS offloading moves encryption work off the AI backend so latency stays low even under heavy load. Content-aware routing then sends different request types, such as chat completions and image generation, to the backend pools suited to them, so expensive GPU capacity goes where it is actually needed.

Latency compounds at this layer. When inference already adds hundreds of milliseconds, every fraction the delivery layer contributes counts. HAProxy is built for this: benchmarks showed HAProxy achieved over 2 million requests per second with TLS termination enabled, so the delivery layer adds negligible overhead even as inference traffic scales and demand spikes.

Modernizing legacy systems without a rip-and-replace

Public sector teams rarely get a clean slate. They run mainframe-era systems next to virtual machines and, increasingly, Kubernetes deployments. Older infrastructure predates modern AI workloads by decades, and replacing it wholesale is rarely realistic on a public budget or a public timeline.

HAProxy One deploys consistently across on-premises data centers, public clouds, sovereign clouds, and container environments, which lets it act as connective tissue between legacy systems and new AI services. A Kubernetes ingress controller routes traffic into containerized AI workloads while the same platform manages external load balancing for Kubernetes and the traditional backends beside them. Agencies modernize one service at a time, keeping central control and observability intact, and without locking themselves into a single cloud or compromising between jurisdictions.

AI governance in the public sector carries legal weight. In the U.S., OMB Memoranda M-25-21 and M-25-22 direct agencies to set AI strategies and to put safeguards around high-impact use cases, while updating how they buy AI. In the EU, the AI Act took force in August 2024 and classifies many public sector uses as "high-risk," which brings requirements for risk management, data governance, technical documentation, and fundamental rights impact assessments.

The two regimes approach the problem differently:

These obligations are largely organizational, but several of them (ongoing monitoring, audit trails, and transparency) depend on infrastructure that can show its work. The HAProxy Fusion Control Plane aggregates logs, metrics, and security events from every node it manages, across on-premises, cloud, sovereign-cloud, and Kubernetes environments. Secure management traffic runs over mTLS, so the audit trail itself is protected end to end.

The OECD's guidance on trustworthy government AI points the same way, urging agencies to favor high-benefit, lower-risk applications while they build maturity. Most still lack the measurement to make those calls with confidence, which is exactly why infrastructure-level observability belongs in the design from day one, rather than something retrofitted after a deployment is already live.

Securing your agency's AI future

Every challenge described above has a known answer at the infrastructure layer. The real question for public sector IT teams is whether the platform under their AI services was built for this much load and this much scrutiny.

HAProxy One pairs the performance of the open source HAProxy core with a unified enterprise platform. The HAProxy Enterprise load balancer delivers high-performance load balancing and multi-layered security with token-aware rate limiting for AI traffic, and the HAProxy Fusion Control Plane centralizes management and observability across the estate. ML-enhanced threat intelligence already powers the detection algorithms in the HAProxy Enterprise WAF and Bot Management Module, and the HAProxy Edge application delivery network extends that intelligence to the network edge.

Reach out to discuss how HAProxy One can support your agency's AI infrastructure.

Almost every one of them, whatever it started as, turned into a version of the same question: how do I know? How do I know whether a vendor's AI does what the banner says? How do I know what my agents are doing on the network? Or that every certificate in the inventory will renew before it expires, or what's really running in front of my applications right now?

Verification, not novelty, was the subject of the show.

Our takeaways

1. AI saturation has produced buyer skepticism, and skepticism rewards checkable claims. When every vendor says the same thing, the advantage goes to whoever can be verified, in source code, in documentation, and in practice.

2. The dominant AI security question has shifted from "what can AI do for us" to "how do we control what our AI is doing." Agent and model traffic needs a policy enforcement point, and that's a proxy problem.

3. Smaller rooms help build trust. Some of our best conversations happened at a 250-person forum convened by Major League Baseball at the same time as Black Hat.

Six themes from the Black Hat show floor

1. Every booth claimed AI, and the crowd was skeptical

Every vendor at Black Hat attached AI to its message. Some were selling ways to secure AI workflows. Others were selling AI that does the security work for you, reading logs or running penetration tests. AI saturation produced a predictable reaction: attendees told us their hardest problem was separating useful capability from marketing noise.

It's a change in tone from 2025. Last year the question was what can AI do for security? This year: how do I tell whether yours does anything real? Several people asked, more or less directly, to be shown rather than told.

The correction favors technology whose claims can be tested and verified. HAProxy's core is open source, with a documented configuration language, so an engineer can read what a feature does instead of trusting a marketing headline. Behind the project is a community large enough to have tried nearly every configuration imaginable, in production Many of them publish their setups and experiences in blogs and forums.

Open fundamentals raise the bar for everyone, us included. If the core is free, capable, and readable, then commercial products must add something unique and worthwhile: advanced security, management and orchestration, and support from the engineers who built the product.

2. People wanted proof, from someone who had built it

Blocking unwanted traffic and web attacks was the most common use case attendees raised. Our best answer to this was to walk through the security control plane in HAProxy Fusion at one of our demo stations.

Centralized DDoS protection, bot management, and WAF policy across a whole fleet is easier to show than to describe. It’s simple to understand and configure using HAProxy Fusion’s Security Profiles and the intuitive visual policy builder we call the Threat-Response Matrix. To cap it all, unified observability shows its impact on real traffic.

Attendees wanted to go deep, with multiple technical questions, so it helped that we brought several of our top engineers who helped design and build our solutions, and implement them in real-world deployments. At a show where every banner claims the same capabilities, that expertise and experience is the fastest way to stand out.

3. Agent and MCP traffic is the new perimeter question

Some of the most common AI questions were about securing AI traffic. How do you put a policy enforcement point in front of model and agent calls? And how do you see what those agents are doing on the network once they're running? 

Businesses are also starting to consume third-party MCP (Model Context Protocol) servers, and some are preparing to expose their own. Both directions raise questions, such as who may call this, and what did they ask for? At least one vendor on the floor was building an MCP gateway as its entire product.

A head of AI security at a large organization sought us out to ask what we can do to help. Our answer: this is a proxy problem in new clothes. 

Agent and model traffic is HTTP and gRPC. Authentication, authorization, rate limiting, request inspection, routing, and observability at Layer 7 are among the very fundamentals of HAProxy. You don't need a new category of product to put a control point in front of an agent or MCP server. The control point you already have just needs to see that traffic.

4. Certificate management is as vital as threat protection

For a conference built on offensive research, a striking share of the practical questions at our booth were about certificates. How do you automate issuance and renewal across thousands of endpoints, and what breaks when certificate lifetimes shorten?

There's a deadline behind those questions. Under CA/Browser Forum ballot SC-081v3, maximum TLS certificate lifetimes fell from 398 days to 200 in March 2026. They drop to 100 days in 2027, and to 47 days in 2029. Domain validation reuse is shrinking on the same schedule, from 398 days to 10, so revalidation becomes near-continuous.

It’s worth considering how that will affect your own inventory. A certificate that previously needed to be renewed once a year will need it roughly eight times a year at 47-day validity. An inventory of 500 certificates, for example, becomes close to 4,000 renewal events a year.

These are unglamorous problems that quietly consume large teams. 

HAProxy's SSL/TLS implementation is best in class. But certificates aren't a single load balancer problem, they're a fleet problem; managing them consistently across an entire fleet is the hard part. Centralized ACME support in HAProxy Fusion, for fleet-wide certificate automation, is coming soon, and we demoed it at the booth. Automating renewal from the control plane removes a whole category of expiry incident. That demo spread by word of mouth and drew people who needed exactly this.

Post-quantum TLS came up too, usually as a sequencing problem: the load balancer, the backend, and the clients are all on different timelines. The load balancer, at least, doesn't have to be the blocker. HAProxy Community Performance Packages and HAProxy Enterprise 3.2+ support hybrid post-quantum key exchange natively. Clients that aren't ready fall back to classical ECDHE. Our guide to enabling post-quantum cryptography and TLS termination walks through the configuration.

5. "App sec" and why securing traffic matters

AI wasn't the only thing the floor was selling. A large share of it was application security in the narrower sense: securing the application code itself, rather than the traffic that reaches it.

The two layers answer different halves of the same question. Code analysis tells you what an application should do. The traffic layer tells you what it does under real load, from real clients, including the requests nobody designed for. 

The two layers also work on different clocks. Fixing application code takes as long as it takes: a patch, a review, a release, a deployment window. The vulnerability stays reachable in the meantime. A WAF at the proxy layer can block the requests that would exploit the vulnerability; this doesn't fix the code but buys the time to fix it properly. That's a good reason for the traffic layer and the code layer to be part of the same conversation.

6. Trust compounds over 25 years

One topic came up again and again: we have F5, we're having some issues, we're opening conversations with other vendors, and we heard of HAProxy.

There’s a good reason why people gravitate to HAProxy under these circumstances. HAProxy has been in production for more than 25 years, upholding the world’s most demanding applications and inspiring a generation of tinkerers in their home labs. That history is why people arrive at the booth already knowing the name, and already trusting the solution. It's also why "how do I know?" has an easy answer here: check the source, or ask anyone who has run it.

It also means the migration path is well traveled rather than theoretical. DoubleVerify's move from F5 to HAProxy Enterprise is the story we pointed people to most often.

Building an ecosystem in 2026

Two miles from Mandalay Bay, we spent the same days at CTI (Cyber & Technology Innovation). It's a 250-person forum, convened by Major League Baseball rather than by a vendor or a media company.

CTI brings together technology and security leaders from MLB clubs, MLB's parent and sister companies, other sports leagues, and media and entertainment organizations. Those people run comparable infrastructure under comparable pressure: a season-shaped traffic curve, and live events that can't be rescheduled.

The keynote paired MLB's security leadership with a public-sector cybersecurity leader and one of the game's most recognizable managers. 

This event format is worth watching. Enterprise buyers with mature technical functions can build their own ecosystems, on their own terms, inviting peers directly instead of waiting for a vendor to broker the introduction.

If your organization runs something like this, we'd like to know.

Demos, Loady, and the next generation

Back at Black Hat, booth 4208 ran four demo stations and five live sessions on rotation. The lineup: multi-layered application security with Security Profiles in HAProxy Fusion, fleet-wide load balancer rate limiting, defending against HTTP protocol attacks, TLS at scale with ACME, and post-quantum TLS termination.

The swag verdict was unambiguous. Everyone loves Loady, our elephant mascot and the most reliable conversation-starter we own. After Loady, the biggest hits were the kids' T-shirts and onesies. A lot of today’s engineers got interested in this stuff young. Hopefully our giveaways for kids and families will help inspire the next generation. Our adult-sized T-shirts also earned a few laughs!

What's next?

See the security control plane in action: watch the HAProxy Fusion 2.0 on-demand webinar. 

Get a custom demo and consultation with our experts: request a demo.

Meet us at the next event: HAProxy Events page

This isn't a general hacker concern. The actors with the means to store encrypted traffic at scale (and eventually acquire the quantum computing resources to break it) are nation-states and large, well-resourced organizations. The other important detail: you can't tell it's happening. Passive traffic collection leaves no trace, and waiting isn't a viable posture.

In August 2024, NIST responded to this threat by finalizing its first post-quantum cryptography (PQC) standards: ML-KEM for key encapsulation, and ML-DSA, SLH-DSA, and FN-DSA for digital signatures. 

This post covers what happens during a TLS handshake, why quantum computers threaten the key exchange step specifically, and how HAProxy can protect your traffic with hybrid post-quantum cryptography right now.

How does the TLS handshake work?

Every TLS connection begins with a handshake, a brief negotiation that establishes which cipher suite to use, authenticates the server, and derives the symmetric keys that protect the session. The cipher suite is the combination of algorithms and key lengths governing the session. The vulnerability that post-quantum cryptography addresses lives in one specific step of this process: the key exchange.

Modern TLS stacks, whether running 1.2 or 1.3, use ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) for that key exchange. Both sides contribute a fresh random value; the shared secret is derived from both contributions and immediately discarded. The classical security of ECDHE rests on the hardness of the elliptic curve discrete logarithm problem, which is effectively unsolvable on classical hardware. It is not unsolvable for a quantum computer running Shor's Algorithm.

TLS 1.3 (shown below) improves on 1.2 in ways that matter for this discussion: it makes ECDHE mandatory by removing static RSA key exchange, reduces the handshake to a single round-trip, and adds support for hybrid post-quantum key exchange. It also makes Perfect Forward Secrecy mandatory by design — more on that, and its limits, shortly.

Hybrid PQC requires TLS 1.3 because the named groups extension that carries the post-quantum component isn't available in TLS 1.2.

You'll see references to "hybrid key exchange" throughout this post. It means combining a classical algorithm (ECDHE) with a post-quantum algorithm (ML-KEM, or Module Lattice Key Encapsulation Mechanism) and using both outputs to derive the shared secret. Neither algorithm alone is enough to reconstruct it. It's a fail-safe in either direction: if ML-KEM has an undiscovered flaw, ECDHE still holds. If ECDHE is broken by a quantum computer, ML-KEM still holds. The hybrid approach also maintains backward compatibility, so clients that don't support post-quantum curves will negotiate classical ECDHE automatically.

If you want a deeper look at the mechanics of TLS 1.3 and round-trip improvements, we covered that in our TLS 1.3 & 0-RTT blog post.

Why do quantum computers break TLS?

Modern TLS key exchange relies on two math problems that are easy to compute forward and nearly impossible to reverse on classical hardware.

RSA depends on integer factorization. Multiplying two primes together is trivial: 17 × 23 = 391. Working backward from 391 to find 17 and 23 is manageable. Doing that with 600+ digit numbers is effectively impossible for any classical computer. ECDHE depends on the elliptic curve discrete logarithm problem, a different but similarly hard-to-reverse operation.

A sufficiently powerful quantum computer running Shor's Algorithm changes this, and Shor's Algorithm can solve both integer factorization and discrete logarithm problems efficiently. That means RSA and ECDHE, the two key exchange mechanisms securing virtually all classical TLS deployments, become breakable.

Quantum computers powerful enough to do this don't exist yet. But the timeline is shorter than most assume; Google's cryptography migration timeline puts the window at years, not decades. And there's a threat that doesn't require waiting for them.

ML-KEM is built on the Module Learning With Errors (MLWE) problem: given a system of linear equations with small random errors deliberately introduced, recovering the original values is computationally intractable even for a quantum computer. It doesn't reduce to factorization or discrete logs, so Shor's Algorithm does not apply. NIST standardized ML-KEM in 2024 because lattice problems of this kind are believed to be hard for both classical and quantum computers. You may also see it referred to by its earlier name, CRYSTALS-Kyber, which is still common in documentation and tooling.

If you want an interactive look at how Shor's Algorithm transforms factoring into period finding, this demo is worth a few minutes.

Perfect Forward Secrecy (PFS) and its limits

Perfect Forward Secrecy (PFS) is a property of certain key exchange mechanisms. When PFS is in place, each TLS session uses a completely independent, ephemeral key. Ephemeral means the key is generated fresh for that session and discarded immediately after. It's never stored on disk, never reused.

The practical upside: if an attacker later compromises your server's private key, they can't decrypt past sessions. Each session's secret is gone once the session ends.

PFS in TLS comes from ephemeral Diffie-Hellman key exchanges, specifically ECDHE. Both sides contribute a fresh random value per session. Neither side's value is ever reused. TLS 1.3 mandates PFS by removing static key exchange options entirely, which is one of the reasons it's a meaningful improvement over TLS 1.2.

But PFS has a limit that quantum computing exposes.

Why Perfect Forward Secrecy doesn't fully solve the quantum threat

A well-resourced attacker doesn't need to break encryption today. The strategy is to record encrypted TLS traffic now and wait until a cryptographically-relevant quantum computer exists, then use Shor's Algorithm to break the classical key exchange retroactively, sometimes described as "harvest now, decrypt later." It's a practical threat for any traffic containing data with a long sensitive shelf life: medical records, government communications, intellectual property.

PFS doesn't change this calculus, because the threat it protects against (an attacker stealing a server's long-term private key) is a different threat model entirely.  What Shor's Algorithm targets is the ephemeral key exchange itself, by solving the discrete logarithm problem against the recorded handshake. That handshake was transmitted in plaintext and is straightforward to capture passively, without any access to the server. Forward secrecy was designed for a world where breaking the key exchange was computationally out of reach, and that assumption no longer holds.

Hybrid post-quantum key exchange addresses this directly. By combining ECDHE with ML-KEM, breaking the shared secret requires defeating both algorithms simultaneously, and Shor's Algorithm currently cannot be used against the lattice-based component.

Configuring hybrid post-quantum cryptography in HAProxy

HAProxy Enterprise 3.2+ and HAProxy Community 3.3+ support hybrid post-quantum cryptography natively. This works because both versions ship with AWS-LC as their cryptographic library, which includes support for post-quantum curves. See our Supercharging HAProxy Community with AWS-LC Performance Packages blog post for details on the AWS-LC integration, and the AWS-LC PQ documentation for the full list of supported curves.

Here's a working configuration that enables hybrid PQC. The PQC-specific addition is two lines: the curve priority lists for bind and server sides. Everything else in the configuration below is standard TLS hardening we'd recommend regardless of post-quantum requirements.

You can verify hybrid PQC is negotiating correctly with BoringSSL's bssl client, which ships with HAProxy Community and HAProxy Enterprise packages by default. The path varies by version (this example uses HAProxy Enterprise 3.2), so adjust accordingly:

Once this configuration is in place, your TLS handshake follows a path that classical and quantum computers can't break independently:

Quantum computers that can break RSA and ECDHE don't exist yet. But adversaries can and do collect encrypted traffic today against the day when they will. NIST finalized its first post-quantum cryptography standards in 2024, and the ecosystem is moving fast.

HAProxy with AWS-LC gives you hybrid PQC without waiting for clients to catch up. The fallback curve order handles compatibility automatically. 

PQC carries a slight CPU penalty once enabled, but for most workloads this trade-off is worth taking. We have benchmarked both standard TLS and PQC-enabled TLS, and will publish the results in a follow-up blog post.

What’s next?

Migrating key exchange now is step one of a two-phase migration. Digital signatures are step two.

Hybrid ML-KEM key exchange protects the key agreement step of the TLS handshake, but TLS also uses digital signatures to authenticate certificates. Those signatures still rely on RSA or ECDSA, which are equally vulnerable to Shor's algorithm.

The NIST PQC standard includes ML-DSA (CRYSTALS-Dilithium) and SLH-DSA for post-quantum digital signatures. Support in certificate authorities and TLS stacks is coming.

One note on scope: HAProxy secures the client-to-edge connection. Traffic from HAProxy to your backend applications travels over a separate connection, and if those backends don't yet support PQC, that leg stays on classical crypto. Enabling PQC at the edge is still the right first step because it's the most exposed connection for passive collection. But a complete migration requires applying the same approach to your backend connections.

FAQs

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.