At a glance

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

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

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

• HAProxy protection:

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

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

What is CVE-2026-49975?

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

Technical impact

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

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

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

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

• Default configurations of NGINX (before 1.29.8)

• Apache HTTPD (before mod_http2 v2.0.41)

• Microsoft IIS (Windows Server 2025

• Envoy (1.37.2 and older

• Cloudflare Pingora

Defending your infrastructure: Virtual patching vs. host reconfiguration

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

Option A: Manual server reconfiguration

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

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

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

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

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

Option B: “Virtual patching” with HAProxy

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

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

How HAProxy protects your infrastructure

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

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

Automatic protection with HAProxy

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

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

Optional: Immediate mitigation configuration

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

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

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

Conclusion

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

Next steps:

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

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

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

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

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

What’s new in HAProxy 3.4?

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

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

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

How to upgrade to HAProxy 3.4?

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

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

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

• Compile it from source. View the compilation instructions.

Flexibility

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

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

Dynamically add and delete backends

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

First, consider this HAProxy configuration:

We use the HAProxy Runtime API to perform the following:

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

• Enable the server and its health checks.

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

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

The corresponding HAProxy Runtime API commands are shown below:

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

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

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

QMux protocol

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

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

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

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

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

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

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

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

Set timeouts dynamically

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

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

Binary HTTP headers

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

• add-headers-bin

• set-headers-bin

• del-headers-bin

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

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

QUIC protocol

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

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

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

HTTP compression

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

The following example compresses responses:

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

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

do-log action

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

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

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

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

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

Tuning buffer size

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

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

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

Task scheduler

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

Stats page counters

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

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

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

Automatic CPU binding

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

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

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

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

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

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

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

The following examples illustrate common configurations.

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

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

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

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

HTTP/2 performance

New global directives help mitigate HTTP/2 protocol attacks:

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

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

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

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

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

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

Reusing idle server connections

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

HATerm

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

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

Learn more in the HATerm documentation.

Security and TLS

JSON Web Tokens

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

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

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

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

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

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

AES CBC converters

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

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

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

Enhanced ACME features

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

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

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

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

• delay instructs HAProxy to add a delay period.

• none instructs HAProxy to proceed with validation immediately.

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

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

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

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

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

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

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

TLS dummy certificate

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

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

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

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

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

TLS certificate compression

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

Decrypting TLS 

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

Reliability

HTTP/1 glitches

Two updates affect HTTP glitch detection:

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

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

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

Health check section

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

Better random algorithm

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

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

Fetching the HTTP version

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

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

Prometheus local update metric for stick tables

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

HTTP/2 error logs

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

Debugging

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

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

Observability with OpenTelemetry

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

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

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

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

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

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

New fetch methods in this release are as follows:

New converters in this release are as follows:

HAProxy 3.4 deprecates these features:

• The compression-direction directive is deprecated.

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

Breaking changes

HAProxy 3.4 has the following breaking changes:

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

Conclusion

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

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

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

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

• Compile it from source. View the compilation instructions.

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

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

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

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

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

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

Choosing the right routing approach

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

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

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

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

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

Read more:

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

• How PayPal hyperscaled Kubernetes routing

• Securing 80,000 transactions per second at Infobip

Building the active-active architecture

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

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

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

Subsecond data center failover demonstrated live

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

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

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

Not a single GET request was missed.

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

From the user's perspective, nothing happened.

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

Managing the solution at scale with HAProxy One

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

“It simplifies your life,” Ellsworth said.

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

Small team, big ROI

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

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

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

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

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

Request a demo.

FAQs

What is a data center failover?

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

How is data center failover different from an outage?

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

How do you test data center failover?

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

What's the biggest challenge with data center failover?

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

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

Issue details

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

Affected versions

Drupal 11

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

Drupal 10

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

Drupal 9 and 8

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

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

Recommended actions

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

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

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

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

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

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

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

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

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

2. The path to authoritative central control

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

A philosophy of building blocks, not band-aids

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

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

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

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

The foundational data plane of HAProxy 

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

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

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

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

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

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

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

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

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

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

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

Automating HAProxy with HAProxy Data Plane API

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

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

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

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

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

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

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

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

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

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

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

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

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

Summary

3. The approach that powers customer success

First-party authority, seamless integration

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

A consistent approach to product development

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

Real-world validation

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

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

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

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

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

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

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

4. Vision for the future

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

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

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

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

A modern application delivery platform, built to last

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

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

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

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

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

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

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

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

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

Automating TLS certificate management

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

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

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

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

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

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

Dynamic server provisioning for rapid autoscaling

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

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

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

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

Aligning software threads with CPU hardware

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

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

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

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

Key takeaways for your infrastructure

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

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

The high-performance HAProxy Enterprise WAF (patented) now has a unified multi-engine module for simpler configuration of both the Intelligent WAF Engine and optional Core Rule Set (CRS) compatibility mode, which supports OWASP CRS v4. The HAProxy Enterprise Bot Management Module, powered by the advanced Threat Detection Engine, now offers even more robust enforcement options with an enhanced CAPTCHA module that closes the door on sophisticated bypass techniques. This release further solidifies HAProxy Enterprise as a leading Web Application and API Protection (WAAP) solution.

Alongside this release, we are also announcing HAProxy ALOHA 18.0, which delivers OWASP CRS v4 support to the HAProxy ALOHA virtual or hardware load balancer.

HAProxy Enterprise 3.3 is a foundational component of the HAProxy One application delivery platform, in which the data plane, control plane, and secure edge network work together seamlessly to deliver ultra-low-latency application delivery and sovereign edge security.

New to HAProxy Enterprise?

HAProxy Enterprise load balancer provides high-performance load balancing for TCP, UDP, QUIC, and HTTP-based applications, high availability, an API/AI gateway, Kubernetes application routing, SSL processing, DDoS protection, bot management, global rate limiting, and a next-generation WAF. 

HAProxy Enterprise combines the performance, reliability, and flexibility of our open-source core (HAProxy — the most widely used software load balancer) with ultra-low-latency security layers and world-class support. HAProxy Enterprise benefits from full-lifecycle management, monitoring, and automation (provided by HAProxy Fusion), and next-generation security layers powered by threat intelligence from HAProxy Edge and enhanced by machine learning. 

Together, this flexible data plane, scalable control plane, and secure edge network form HAProxy One: the world’s fastest application delivery and security platform that is the G2 category leader in Load Balancing, API Management, Container Networking, DDoS Protection, and Web Application Firewall (WAF). 

To learn more, contact our sales team for a demonstration or request a free trial.

What's new in HAProxy Enterprise 3.3

When you are ready to start the upgrade procedure, go to the upgrade instructions for HAProxy Enterprise or the installation instructions for HAProxy ALOHA.

Unified HAProxy Enterprise WAF module

HAProxy Enterprise 3.3 introduces a unified multi-engine module for the HAProxy Enterprise WAF. This module consolidates both WAF engines — the unique and powerful Intelligent WAF Engine and the CRS compatibility mode — under a common configuration interface.

The HAProxy Enterprise WAF is patented and recognized for its exceptional balanced accuracy (98.48%), ultra-low latency, and 100% private and local processing. The unified module brings together the Intelligent WAF Engine, powered by threat intelligence from HAProxy Edge and enhanced by machine learning, and the CRS compatibility mode, both delivering unparalleled performance within a single, consistent configuration interface.

The practical benefit is a simpler administrative experience: less configuration overhead, fewer opportunities for misconfiguration, and faster time-to-deployment. For enterprise teams managing complex or large-scale fleets, this directly improves operational velocity and reduces total cost of ownership.

When managed through HAProxy Fusion's visual security policy builder – the Threat-Response Matrix – administrators can orchestrate unified WAF policies across multi-cloud deployments from a single pane of glass.

What sets HAProxy Enterprise WAF apart is the multi-engine architecture, where CRS works alongside the Intelligent WAF Engine to significantly boost accuracy and performance compared with standard CRS implementations. The result is a false positive rate of just 1.78% at paranoia level 2 (versus 28.36% for ModSecurity) and 15X lower latency.

HAProxy Enterprise 3.3 adds native support for CRS v4, which delivers improved detection accuracy, reduced false positives, and a more granular paranoia level system that gives security teams finer control over the trade-off between protection and permissiveness.

Crucially, HAProxy Enterprise 3.3 supports CRS v3 and v4 simultaneously — without requiring plugins — enabling teams to adopt the new ruleset entirely on their own terms.

With this release, administrators can: 

• load CRS v3 and v4 at the same time, applying each to different traffic segments; 

• set the paranoia level independently for each version, tailoring detection sensitivity to each application's risk profile; and

• switch between versions or roll back at any time if needed.

This multi-version approach removes the forced hard-cutover that has historically made WAF ruleset migrations risky. Teams can test CRS v4 against a subset of traffic while keeping CRS v3 in place for production workloads, gradually building confidence before completing the transition.

The result is access to the better accuracy and performance that CRS v4 offers — without the application disruption that has made ruleset upgrades a stressful proposition.

OWASP CRS v4 support is also available in HAProxy ALOHA 18.0, bringing the same flexible multi-version migration path to teams running the ALOHA hardware or virtual appliance.

Enhanced bot protection with LB-CAPTCHA

Building on the advanced Bot Management solution, and the Threat Detection Engine introduced in version 3.2, HAProxy Enterprise 3.3 extends the LB-CAPTCHA module with several capabilities designed to stop more sophisticated bots.

Token-based CAPTCHA callback verification

The most significant enhancement is a new token-based verification mechanism that protects the CAPTCHA callback process itself. When a user completes a CAPTCHA challenge, HAProxy generates a time-sensitive token from request headers during the initial GET request. On the subsequent POST request, the token is verified. Because automated bots typically modify their headers between requests, they produce a mismatched token and are blocked immediately — before they can reach the verification server.

This protection is enabled by default, applying to all CAPTCHA deployments without additional configuration. For environments requiring stricter security, the new callback-token function allows administrators to customize token generation using advanced criteria such as full HTTP or SSL client fingerprints.

Multiple CAPTCHA support

HAProxy Enterprise 3.3 introduces support for multiple CAPTCHAs within the same application. Administrators can now apply different CAPTCHA providers or configurations to different resources — for example, one CAPTCHA for a login endpoint and another for a checkout flow — giving security teams finer-grained, per-resource control over bot protection.

Custom HTML injection

A new custom-html-file-lf option enables dynamic HTML injection in CAPTCHA responses. Administrators can inject changing values on a per-request basis, allowing the rendered output to vary based on attributes such as the User-Agent string. This capability is particularly valuable in high-security deployments where static CAPTCHA pages may be more susceptible to scripted analysis.

Building on the HAProxy One platform

HAProxy Enterprise 3.3 continues a consistent trajectory of security advancement within the HAProxy One platform. HAProxy Enterprise 2.9 introduced the next-generation HAProxy Enterprise WAF, with the Intelligent WAF Engine delivering industry-leading balanced accuracy of 98.48%. HAProxy Enterprise 3.2 introduced the Threat Detection Engine to the Bot Management Module, bringing SaaS-level behavioral detection to your own infrastructure — including air-gapped environments. HAProxy Fusion 2.0 provides the centralized security control plane to orchestrate WAF, bot management, and more across large-scale, multi-cloud deployments from a single intuitive interface.

Together, these releases establish HAProxy One as a top-tier WAAP platform that delivers the sophisticated protection of a cloud SaaS solution with the uncompromised control of a localized, sovereign data plane and control plane.

Breaking change: HAProxy Enterprise Data Plane API 3.3 updated crt_load endpoint structure

HAProxy Enterprise 3.3 releases alongside an updated version of the HAProxy Enterprise Data Plane API that includes a structural improvement to the crt_load endpoints. These endpoints are now correctly nested under their parent crt_store resource, aligning the API structure with the HAProxy configuration model, in which crt-load directives exist within a crt-store section.

The updated endpoint paths are as follows:

All crt_load operations now require the {crt_store} path parameter to identify the parent crt-store section. Clients using the previous endpoint paths should update their API calls to include the crt_store name in the path before upgrading to HAProxy Enterprise 3.3.

Deprecation notice: HAProxy Enterprise Data Plane API 3.3 endpoints

With the release of HAProxy Enterprise Data Plane API 3.3, two endpoint groups are being formally deprecated and scheduled for removal in v3.4.0. This notice is intended to give teams sufficient time to plan and complete their migrations.

/services/git endpoints — The Git-based configuration management endpoints are deprecated as of v3.3.0. Teams currently using these endpoints for configuration workflows should transition to alternative configuration management approaches ahead of the v3.4.0 release.

/services/aloha endpoints — The HAProxy ALOHA service management endpoints are also deprecated as of v3.3.0. Users relying on these endpoints should evaluate and adopt alternative service management workflows before upgrading to v3.4.0.

Both endpoint groups remain fully functional in v3.3.0, giving teams a stable migration window. They will be removed entirely in v3.4.0.

Users who depend on either of these endpoint groups are encouraged to begin planning their migration now. If you have questions about suitable alternatives or need guidance on your migration path, please contact our support team.

Deprecation notice: HAProxy Enterprise 3.3 master-worker configuration keyword

The master-worker keyword in haproxy.cfg is deprecated as of HAProxy Enterprise 3.3 and will be removed in version 3.5. Users currently enabling master-worker mode via this configuration directive should migrate to the equivalent command-line flags before upgrading to 3.5.

Migration path: Replace master-worker in your configuration file with the -W flag (or -Ws for silent mode) passed directly to the HAProxy binary in your startup script.

The master-worker keyword remains fully functional in 3.3, giving teams a stable migration window ahead of the 3.5 removal.

Upgrade to HAProxy Enterprise 3.3 or HAProxy ALOHA 18.0

When you are ready to upgrade, follow the links below.

​Try HAProxy Enterprise or HAProxy ALOHA with a free trial

The world’s leading platforms and cloud providers trust HAProxy Technologies to simplify, scale, and secure modern applications, APIs, and AI services in any environment. HAProxy Enterprise 3.3 and HAProxy ALOHA 18.0 continue our commitment to delivering industry-leading application delivery and security without compromise. Whether you're running HAProxy Enterprise as a software data plane or HAProxy ALOHA as a hardware or virtual appliance, these releases give you the tools to adopt the latest WAF standards and manage your security posture with greater simplicity — all within the HAProxy One platform.

To see for yourself, request a free trial: 

• HAProxy Enterprise free trial 

• HAProxy ALOHA free trial

As a result of the scale involved and the agility developers expected, what began as a routing and load balancing challenge became an infrastructure automation challenge.The HAProxy One platform was the answer, with HAProxy Enterprise (the data plane) providing flexible and high-performance routing, and HAProxy Fusion (the control plane) discovering backends and automating configuration at scale.

Testing at PayPal is even trickier than one might expect. Developers need to test custom app versions against a backdrop of 3,000+ live applications. If a dev has a custom version of App A deployed, traffic needs to find it. If that version doesn't exist, traffic must fall back to the live version automatically.

This process is pretty straightforward with just one app. With a group of apps — all from different teams, at different stages, in different availability zones — it gets exponentially complicated.

Each test environment is essentially its own routing context. Virtual services group related apps together so traffic stays within the right environment. When an app isn't in a given group, traffic has to fall back intelligently instead of simply failing.

The routing requirements get more specific from there. PayPal needed the following:

The source IP issue in particular was a sticking point. Standard Kubernetes Service objects surface the node IP rather than the actual client IP, making it hard to trace traffic accurately. PayPal needed full visibility in both directions.

Building on the Map API

The architectural move that made this work at scale was treating routing rules as data, not configuration. This made it easier for developers to deploy new virtual services using PayPal's internal Genesis API layer, which orchestrates the full environment lifecycle.

In HAProxy Fusion Control Plane, the Map API stores routing rules in memory-resident maps. When PayPal needs to add a new test environment, a single API call updates the routing rules instantly — no config file rewrite, no service interruption. With 6 to 10 new environments spinning up per minute across 60,000 containers, this is the only architecture that keeps up. Changes take effect in milliseconds, and the system never falls behind its own workload.

Genesis calls the IPAM API to reserve a VIP, then calls the Map API to set up routing rules. Frontend configuration updates land in 10 to 15 seconds end-to-end — the full Genesis API sequence from IPAM reservation to routing rules in place.

HAProxy Enterprise load balancer's native support for header-based routing, TLS termination at the VIP, and source IP preservation handles the remaining requirements from PayPal's spec.

Service discovery does the backend work

The other half of the equation is backends. With 60,000+ containers across multiple clusters, manually managing backend pools isn't realistic. HAProxy Fusion's Kubernetes service discovery watches the cluster for new Service objects and automatically adds matching pods to the backend pool.

Instead of manually managing backend pools and configuration files, PayPal gets unified orchestration, observability, and dynamic service discovery from a single control plane. When a developer deploys an app, HAProxy Fusion discovers the new pods and brings them into rotation without any manual config changes.

PayPal runs four Kubernetes clusters. With service discovery supporting up to 12,000 Service objects per cluster, that covers 48,000 service objects across a single HAProxy Fusion deployment. Their four HAProxy Enterprise clusters are all managed through a single HAProxy Fusion control plane.

As Srivignessh Pacham, the senior software engineer who led this work, put it: "During deployment, you don't have to touch the HAProxy Enterprise cluster at all. HAProxy Fusion discovers those matching services and automatically adds them to the backends."

Scalability testing results

Before going to production, the Genesis team ran load and performance tests well beyond their daily requirements. The results:

That last number is worth pausing on. The supported limit was 12,000 backends per HAProxy Fusion cluster. They pushed it to nearly double that and the system held. For a team planning ahead to production workloads, that headroom matters.

HAProxy Fusion’s Request Explorer also proved its value during testing. When something went wrong — an SSL/TLS handshake failure, a 500 error — the team could pinpoint exactly where in the request path the issue occurred. The Genesis API also lets developers run basic container introspection commands (top, ps) without navigating RBAC directly, routing them straight to the right container. With 10,000 distinct environments active at any time, reducing friction on every debugging touchpoint is essential.

Brief architectural overview

Each HAProxy Enterprise cluster is an active/standby pair. Genesis selects which cluster handles a given request. A single HAProxy Fusion control plane manages all four HAProxy Enterprise clusters, providing centralized monitoring and configuration. 

The sequence for a new test environment:

1. Genesis API selects the target cluster

2. IPAM API reserves a Virtual IP

3. Map API updates routing rules in memory

4. Service discovery finds the Kubernetes pods and populates the backends

The developer goes from "code deployed" to "environment ready" in seconds.

PayPal's setup is a solid reference architecture for any team dealing with high-frequency and dynamic application deployment at scale. Map API-driven frontend routing paired with automated Kubernetes service discovery removes the manual overhead that makes environments like this hard to operate — and turns 30,000 daily config updates into just another Tuesday.

Watch the full presentation on PayPal Genesis from HAProxyConf 2025 for the complete walkthrough, including scale test data and architecture diagrams, or schedule a demo of HAProxy One.

Connecting it all was a single application delivery platform. HAProxy One provides Kubernetes routing, AI traffic management, sovereign security infrastructure, and unified mesh connectivity, all from one place. Here's what happened.

Watch our on-demand webinar: Life after Ingress NGINX: how to unify Kubernetes traffic in one stack.

Three conversations the ecosystem needed to have

Three themes surfaced in nearly every conversation: the urgency of replacing Ingress NGINX, the challenge of connecting and securing fragmented multi-cloud estates, and — as AI agents generate unprecedented telemetry — what it actually means to own your observability data. Our three sessions addressed each of them directly.

One piece of that story was the official announcement of HAProxy Unified Gateway 1.0, an open-source Kubernetes Gateway API controller. Conversations across previous KubeCons had made the demand clear, and community beta testing helped shape the 1.0 release. For Zlatko and the engineering team, there was real satisfaction in it: whereas the existing HAProxy Kubernetes Ingress Controller took many iterations to fully expose all of HAProxy's powerful capabilities, HAProxy Unified Gateway delivered them from day one. Enterprise multi-cluster support is coming to HAProxy Fusion later this year. 

Our third session again featured Jakub as a panelist in a CNCF observability roundtable, covering AI agent behavior and observability as a business capability. Jakub made a point that resonated: "One of the problems of having so much observability data has been that a human just can't read it, but AI can." On data sovereignty, a theme that ran through the whole event, Jakub remarked: "Owning your own data is paramount." More on that below.

"Obviously, everyone is recommending HAProxy"

Many in the audience for Jakub and Zlatko's demo theatre session came to see us afterwards. What they said was striking.

Multiple people said, unprompted, some version of the same thing: "We need to migrate from Ingress NGINX, and obviously everyone is recommending HAProxy." That shift in language — obviously — matters. Not "we heard HAProxy is an option" or "we're evaluating a few tools." Obviously. It reflects a market that has reached a conclusion.

The same theme surfaced independently elsewhere on the floor. A leading cloud infrastructure platform told us that AI factories are rapidly becoming one of their top use cases and reached for the same language we'd been hearing all week: HAProxy as the default proxy for AI inference scaling.

Somebody asked me whether HAProxy is modern enough to take advantage of this moment, given that it's been around for a quarter century now. The answer came easily: it's been modern for 25 years. The properties that make HAProxy the right ingress layer for AI workloads — zero-downtime reconfiguration, stateful connection handling, high-throughput routing under dynamic load — aren't recent additions. They're the reason the internet runs on HAProxy in the first place. AI workloads need powerful, modern traffic management. HAProxy solved the problem years ago.

Connect and secure everything

Baptiste's keynote title captured two essential questions that came up all week. 

1. How do I connect everything in a way I can actually manage? 

2. How do I secure it without handing my traffic to a third party? 

In practice, they're two sides of the same problem. They both reflect a need for greater control over complex infrastructure. In both cases, the answer is HAProxy One.

The security story produced its own kind of reaction. Most visitors assumed that an enterprise Web Application Firewall (WAF) means either a cloud service processing their traffic or an appliance with a license that costs as much as a small engineering team. We'd show them something different: the HAProxy Enterprise WAF solution is entirely self-hosted, touches no external service, does not transmit data, and is available with HAProxy Enterprise at no additional cost.

Then we'd show the benchmark results: the highest balanced accuracy of any WAF tested in an open-source benchmark, outperforming both well-known cloud services and commercial appliance solutions, a result further demonstrated by Infobip's zero false positives. Then we'd show the Roblox proof point: 100 million daily users, no measurable increase in CPU utilization, no measurable latency impact.

At that point, most people would ask us to say it again.

Owning your own data

Sovereign infrastructure came up in many of these conversations, and it connected directly to what Jakub had been discussing in the observability roundtable earlier in the week. Attendees frequently arrived assuming that our control plane (HAProxy Fusion) was a SaaS product and that our intelligent security layers were feeding data back to us. When we explained that the control plane is fully self-hosted and the security layers are entirely private, the reaction was often the same: relief.

European regulation — the Cyber Resilience Act, DORA — is turning data sovereignty from a preference into a hard requirement for many organizations. But the shift runs deeper than compliance. As Jakub put it in the roundtable, customers are actively choosing to take back ownership of their data after a decade of pushing everything to SaaS platforms. HAProxy's architecture meets that requirement by design, which was a major factor driving HAProxy’s leadership in the G2 Spring 2026 Grid^® and Index Reports.

Our biggest KubeCon yet

The HAProxy booth was hard to miss, positioned right alongside the booths for Microsoft Azure, Google Cloud, Uber, and NVIDIA. Standing next to the hyperscalers is not just good for the photos. It signals where HAProxy Technologies sits in this market: at the foundations of modern applications and AI.

Demo stations kept our solutions engineers busy from the first morning to the final close, and the queues were proof of real interest rather than free-swag tourism — though we had plenty of that too. We distributed thousands of T-shirts, baby onesies, and Loady plushies! 

Takeaways from KubeCon Amsterdam 2026

The first takeaway is one that has been building for a long time: HAProxy is the standard for traffic management – any app, any API, and any AI service. When practitioners are telling us "obviously everyone is recommending HAProxy," that reflects the earned recognition of 25 years of reliable performance.

The second is that sovereign infrastructure is the dominant concern for the European market right now. Organizations are actively choosing self-hosted control planes and security over SaaS alternatives, driven by regulation, risk appetite, and hard lessons from a decade of pushing data to external services. HAProxy's architecture is perfectly positioned for this shift. 

The third takeaway is about the depth of trust that has grown between HAProxy and its community. Many conversations at our booth weren't first encounters, they were catch-ups with friends. People were sharing stories of when “HAProxy saved my life”, before bringing us their next problem, already trusting that we could help them solve it. That trust runs in both directions. The conversations practitioners bring to events like this one — their problems, their feedback, their honest assessments of what they need — will continue to shape what we build.

Ready to migrate from Ingress NGINX? Use our migration toolkit.

See HAProxy One in action. Request a demo.

Whatever you’re building in 2026, HAProxy was made for this. Join us and seize the moment.

New to HAProxy Unified Gateway?

HAProxy Unified Gateway is a free, open-source project maintained by HAProxy Technologies that enables Kubernetes-native traffic management covering Gateway API specifications 1.3, 1.4, and 1.5.

Organizations are moving more workloads to Kubernetes, which requires routing methods that handle diverse applications and organizational complexity. The Gateway API standard provides a solution through role-based access control, enabling a clear separation of concerns among infrastructure providers, cluster operators, and application developers.

HAProxy Unified Gateway provides flexible protocol support, role-based access control, and a future path for unified Ingress support coming later in 2026. It brings exceptional performance and efficiency to Kubernetes traffic management because it is built on HAProxy, the world’s fastest software load balancer. By adopting HAProxy Unified Gateway, teams have the freedom to scale exceptionally well with class-leading performance and efficiency on any infrastructure.

What's new in HAProxy Unified Gateway 1.0

The 1.0 release focuses on operational simplicity, expanded routing capabilities, and deep integration with HAProxy configuration features.

Scaling Kubernetes routing (and more) with the HAProxy One platform

As your infrastructure grows, Kubernetes traffic management becomes just one piece of a much larger puzzle. To truly simplify, scale, and secure modern applications in any environment, organizations require a unified approach.

This is where HAProxy One comes in.

While HAProxy Unified Gateway provides developers and cluster operators with the flexibility of the Gateway API, enterprise teams managing mission-critical workloads often require advanced security, global observability, and centralized management. To meet these needs, organizations can seamlessly extend their architecture with our HAProxy One enterprise platform, which includes the following:

• HAProxy Enterprise: Upgrading to our enterprise data plane adds multi-layered security — including an integrated web application firewall (WAF), bot management, and advanced threat intelligence — without sacrificing our signature ultra-low latency.

• HAProxy Fusion Control Plane: HAProxy Fusion provides centralized management, observability, and automation across your entire deployment. Looking ahead, Gateway API support is coming to HAProxy Fusion, which will empower platform engineering teams to manage both traditional infrastructure and Kubernetes-native routing from a single, authoritative control plane.

Core technology built on HAProxy 3.2 LTS

HAProxy Unified Gateway 1.0 is built on the stable and powerful HAProxy 3.2 LTS core. This foundation ensures that your Kubernetes traffic management benefits from the extensive performance enhancements, security updates, and reliability improvements introduced in the 3.2 long-term support release. It provides a highly efficient data plane that minimizes resource consumption while reliably routing high volumes of traffic.

Comprehensive HAProxy configuration support

To give you more control over your traffic routing, this release introduces three new Custom Resource Definitions (CRDs) — Global, Defaults, and Backend — that let you manage HAProxy configuration natively within Kubernetes. The Global CRD lets you override HAProxy's global section, adjusting connection limits, TLS cipher suites, DH parameters, and process-level tuning. The Defaults CRD lets you customize the timeout and connection-handling values that every frontend and backend in the cluster inherits. The Backend CRD lets you configure load balancing behaviour, health checks, and server options for individual services. 

Frontends are generated automatically from your Gateway and Route resources — that's the Gateway API model — so there is no Frontend CRD. Instead, your frontend configuration is expressed declaratively through the Gateway spec. 

In the beta release, operators who needed to override Global or Defaults settings had to inject auxiliary configuration files via ConfigMap volume mounts, a workaround that sat outside Kubernetes' resource model and required modifying the controller Deployment to wire up. With these CRDs, the same overrides are expressed as standard Kubernetes objects, applied with kubectl apply, and picked up by the controller automatically.

Expanded route and listener support

HAProxy Unified Gateway 1.0 expands its routing capabilities to cover the full range of production traffic patterns. It supports HTTPRoute for HTTP and HTTPS traffic with TLS termination, and TLSRoute for TLS passthrough — where HAProxy reads the SNI hostname from the TLS ClientHello to route the connection without decrypting it. 

Because both listener types attach to the same Gateway definition, platform teams can establish port exposure and TLS policy once, and application teams can add or change routes independently — without modifying the underlying infrastructure.

Enhanced dynamic scaling

Managing dynamic environments is simpler with improved scaling mechanisms in version 1.0. In the beta release, every pod scale event — whether triggered by a Horizontal Pod Autoscaler or a manual kubectl scale — could require a full HAProxy reload to update the backend server pool. HAProxy Unified Gateway 1.0 eliminates this by registering a watch against the Kubernetes Endpoints API for every Service referenced by a route. When pod counts change, the controller detects the updated IP addresses and reconciles server entries in the running HAProxy process directly via the Runtime API, without triggering a reload. 

The result is that active connections are never dropped during scale-out, and scale-in events drain gracefully — connections to departing pods are allowed to complete before those servers are removed from the pool.

New operational features for metrics and session persistence

Observability and traffic consistency are critical for production workloads. This release addsbuilt-in metrics (with a Prometheus-compatible endpoint), allowing operators to monitor gateway performance and application health directly. It also introduces session persistence, ensuring that users maintain a continuous connection to the same backend pod when required by stateful applications. These additions provide the visibility and reliability needed to confidently run mission-critical services in Kubernetes.

Simplified installation and lifecycle management

To help you deploy and manage the gateway with ease, we have introduced support for Helm charts. This streamlines the installation process and enables the automatic deployment and upgrading of Custom Resource Definitions. By standardizing on Helm, infrastructure teams can integrate HAProxy Unified Gateway into their existing continuous integration and delivery pipelines quickly and reliably.

Configuration example

In this example, a platform team is integrating HAProxy Unified Gateway into their GitOps-based delivery pipeline, which uses Flux and ArgoCD with Helm chart manifests stored in version control. Rather than managing a sequence of raw YAML files and re-applying them at upgrade time, they adopt the official HAProxy Unified Gateway Helm chart, which handles CRD installation, namespace creation, RBAC, and controller deployment in a single, repeatable operation. A values.yaml file checked into their repo tracks the configuration.

Step 1 — Add the HAProxy Helm chart repository

The Helm chart version (specified with --version) and the HAProxy Unified Gateway application version are independent. The chart's appVersion field tracks the HAProxy Unified Gateway release and is updated automatically by HAProxy Technologies whenever a new version of HAProxy Unified Gateway is published to Docker Hub.

To upgrade the chart, run helm upgrade with the new chart version:

The Helm chart automatically applies any updated CRD schemas before rolling out the new controller Deployment, ensuring that CRDs stay in sync with the controller version throughout the upgrade lifecycle.

Summary

The helm install command replaces the multi-step kubectl sequence from the on-premises installation guide. With crds.install: true, the chart installs the Backend, HugConf, and HugGate CRDs as part of the release and tracks them in the Helm release metadata. The gatewayClass.create: true flag creates the haproxy GatewayClass automatically, so the cluster is ready to accept Gateway resources immediately after installation. The values.yaml serves as a declarative record of the deployment's configuration, which can be committed to version control and reconciled by GitOps tooling on every change.

Ready to upgrade or try?

HAProxy Unified Gateway remains a free, open-source product dedicated to the Kubernetes community and the adoption of the Gateway API standard.

You can find the Docker image for HAProxy Unified Gateway on Docker Hub and the Helm Charts on GitHub. We encourage you to participate and contribute to the community project on GitHub.