Our new downloadable HAProxy packages, compiled using the AWS-LC TLS library, provide the simplest way to get the latest and best-performing version of HAProxy for your flavor of Linux. HAProxy’s class-leading SSL/TLS processing is even better with support for ACME DNS-01 challenges, automatic SNI, Encrypted Client Hello, Linux Kernel TLS, and more. Persistent stats over reloads enabling continuous, uninterrupted metrics for dashboards and alerting systems. Improvements to default settings and CPU/memory management make HAProxy 3.3 the fastest and most efficient HAProxy yet. Experimental support for QUIC on the backend provides expanded interoperability and helps ensure future-proof compatibility with the QUIC protocol.

In this blog post, we’ll explore all the latest changes in detail. As always, enterprise customers can expect to find these features included in the next version of HAProxy Enterprise.

Register for our webinar HAProxy 3.3: Feature Roundup and listen to our experts as we examine new features and updates and participate in the live Q&A.

New to HAProxy?

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 get HAProxy 3.3

You can install HAProxy version 3.3 in any of the following ways:

• Install the new HAProxy packages for Ubuntu / Debian (version 3.3 available here soon).

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

  • (Note that Docker containers built with the HAProxy performance packages with AWS-LC will be available later.)

• Compile it from source. View the compilation instructions.

Performance packages

Get started with the performance packages here.

Security and TLS

ACME

HAProxy 3.3 extends the ACME implementation from version 3.2 by adding support for DNS-01 type validation challenges alongside the existing HTTP-01. A validation challenge is the method that ACME providers, such as Let's Encrypt, utilize to verify that you own the domain for which you're requesting a TLS certificate.

HAProxy supports this via the HAProxy Data Plane API version 3.3 (coming soon), which handles the communication between HAProxy and the DNS provider. During the DNS-01 challenge, the ACME provider sends a secret phrase that must be added as a DNS TXT record, establishing ownership of the domain. The HTTP-01 challenge accomplishes the same thing by adding the secret phrase to a file on the web server. In both scenarios, HAProxy and the HAProxy Data Plane API seamlessly automate the entire process.

Once the validation is complete, the ACME provider issues a TLS certificate. New in this version, the HAProxy Data Plane API will automatically store the certificate on the load balancer's filesystem, eliminating manual management. However, you should use this functionality only with single load balancer deployments. For multiple load balancer deployments or clusters, you'll need manual synchronization of the certificates, though HAProxy Fusion offers cluster-wide certificate management capabilities out of the box.

SNI

Configuring server-side TLS is now simpler as HAProxy can automatically set an SNI value from the host HTTP header and forward it to the backend server. Previously, this required manual configuration using sni req.hdr(host) on the server line. You can disable this automatic behavior by setting no-sni-auto on the server line, or explicitly re-enable it with sni-auto. Similarly, the check-sni-auto and no-check-sni-auto arguments allow explicit control of the automatic SNI value sent in health checks.

Also, you'll get a warning now if you try to use the strict-sni and default-crt arguments together on a bind directive in a frontend. This relates to setting default TLS certificates in your frontend: When you set a bind directive's crt argument to a directory instead of a single certificate file, HAProxy selects a certificate from that directory that has a CN or SAN field matching the SNI value the client sent. The default-sni argument lets you fall back to a default certificate if no other certificates match. Meanwhile, the strict-sni argument requires the SNI to match a certificate. The two don't make sense to use together and so are mutually exclusive.

Certificates with passphrases

A new global directive, ssl-passphrase-cmd, enables HAProxy to unlock TLS certificates that have a private key protected by a passphrase. The directive specifies a script that returns the passphrase when invoked with the key. HAProxy optimizes the process by trying all previously retrieved passphrases before re-invoking the script.

Encrypted Client Hello

A new, experimental bind argument, ech, enables HAProxy to use TLS ECH (Encrypted Client Hello). This new feature encrypts the ClientHello message sent to the load balancer, protecting sensitive fields including the SNI field, so they remain private and only decryptable by the target server. Using this argument requires the global directive expose-experimental-directives. Additionally, ECH requires clients to retrieve the public key from DNS, so first add your public key to your DNS configuration.

Kernel TLS

HAProxy 3.3 adds support for Kernel TLS, wherein the Linux kernel takes over handling the symmetric cryptography part of the TLS processing. It's beneficial because it allows HAProxy to offload cryptographic work to the kernel after it's performed the initial TLS handshake. The kernel handles further decryption and encryption without copying the data to HAProxy's userland process. Then data are encrypted/decrypted on the fly during the transfer from userland to the kernel. That in itself saves resources, particularly on high-speed links of 100 Gbps and above.

Even greater benefits come with end-to-end TLS, in which HAProxy manages TLS connections between itself and the client, and also between itself and the backend server. In that case, you can enable Kernel TLS on both ends. Then, optionally, enable kernel-based TCP splicing to transfer the data directly from the client socket to the server socket entirely at the kernel level without ever passing the data to the userland software, saving two memory copies!

You must compile HAProxy with flags for Kernel TLS and splicing, although both are enabled in the linux-glibc build target, which users commonly use. You'll need to run HAProxy with OpenSSL 3.x or the latest AWS-LC library. Set expose-experimental-directives in the global section. Add the ktls on argument to your bind directive and, if using end-to-end TLS, to your server directives. Then, to enable splicing, add option splice-auto to the frontend.

Preprocessor conditions

New preprocessor conditions help you to add sections to your configuration only when the statement is true.

OAuth authentication

HAProxy has supported validating JWTs (JSON Web Tokens) since version 2.5, which are necessary for OAuth 2.0 authentication. As part of the validation, HAProxy will, via the jwt_verify fetch method, check the signature embedded in the JWT against a public key that you got from the OAuth identity provider. However, providers often don't provide the keys directly, but embed them inside X.509 certificates. It had been a manual step to extract the key from the certificate. Now, with the new jwt_verify_cert fetch method, you can download the certificate and HAProxy will do the work of extracting the key from it, facilitating automation. 

To use a certificate with jwt_verify_cert, first declare it with a load directive in a crt-store section and set its jwt argument to on. The jwt argument is new in this version.

Other security changes

This version has a few other security-related changes:

• You'll now get a warning at startup if you're running HAProxy as root and your configuration is missing the global directive user, which sets a Linux user account that HAProxy should run as. HAProxy runs with superuser privileges during initialization so that it can perform necessary tasks, such as binding to privileged ports, but afterwards, it's best if it can drop those privileges and become another user. The warning will nudge users towards adopting this security best practice. You could even set the user directive to root, but at least then it'd be explicit.

• New bind and server arguments named tcp-md5sig adds support for Protection of BGP Sessions via the TCP MD5 Signature Option, which many routers require when placing a TCP proxy like HAProxy between them.

Observability

Persistent stats

You can now store frontend, backend, and server statistics in Linux's shared memory so that they can be preserved after reloading the configuration. These are the statistics you see on the Stats page and when calling the Runtime API command show stat. The feature is experimental, but the steps are:

1. Add the expose-experimental-directives and shm-stats-file global directives.

2. Add GUIDs to your frontends, backends, and servers. The GUIDs must be unique within your configuration.

3. Reload HAProxy to see that the stats were preserved. Restarting it will lose the statistics.

Example configuration:

The new acme and ssl trace sources let you monitor ACME and SSL events. In this example configuration, we start tracing ACME events, which will be sent to standard out:

• The default load balancing algorithm is now random instead of roundrobin, when not otherwise set with the balance directive in a backend. This has demonstrated superior performance and improved fairness between uneven servers, but please read more about this change in this discussion. Note that the random algorithm works out of the box as a Power-of-Two algorithm, which allows it to randomly draw two servers from the list and then choose the least loaded one from those two.

• HAProxy's cpu-policy now defaults to performance, meaning that on systems with a heterogenous mix of efficiency and performance core types, the load balancer will run on only the performance cores. For more information about cpu-policy, see tuning the load balancer’s automatic CPU binding. Also, HAProxy will automatically use all available cores and NUMA nodes on NUMA systems and the maximum number of threads is no longer limited to 64, which matters for machines that have more than 64 cores, particularly on non-NUMA systems. The increased processing capacity benefits CPU-intensive use cases such as TLS, Lua, and regex.

• Frontend, backend, and server-related event counters are now stored per thread group, which reduces bottlenecks when accessing the counters.

• Backends with mode http now set option abortonclose by default. This setting tries to stop processing a request before it's been sent to a server if the client aborted on their end, such as by closing the tab or refreshing. Also, you can now set option abortonclose in a frontend, which wasn't allowed before, and HAProxy will avoid computing the TLS handshake on connections that are already closed.

• HAProxy saves resources by no longer allocating memory for a default-server directive unless you declare one in your configuration. Also, after parsing the directive, HAProxy releases the memory associated with it.

• When using a use-server directive or track argument in a backend, startup will be faster now that HAProxy uses a more efficient algorithm for finding the server.

• You can now choose a different TCP congestion algorithm by setting it with the new cc argument on a bind or server line.

• This version relaxes the amount of locking between stick tables and peers by batching the updates and delaying work, leading to a smoother traffic flow and better overall performance.

• Some multi-threaded tasks that caused a lot of contention on servers with many CPUs, such as stick table expirations and resolvers connections, were changed to be single threaded.

• HAProxy's internal HTTP client, which it uses for tasks such as sending requests to ACME servers, had yielded control of the thread in between sending the HTTP headers and sending the HTTP body. That isn't necessary if HAProxy has the headers and body ready to send. In this release, HAProxy will send both, if possible.

• In this version, the way that HAProxy connects to DNS nameservers was changed. Previously, if an outage caused by a main route to the nameservers being down might cause the packets to use an alternative route and interface, but then not revert to the main route once it became available again,  HAProxy will now correctly revert to using the main route. Instead of using the connect() and send() functions, HAProxy now performs a bind on the wildcard address for the datagram AF_INET* client socket, then uses sendto() instead of send().

• Multithreaded applications may experience performance hits when multiple threads modify data, even if unrelated, in the same cache line, which may invalidate the cache line for other threads and cause a cache eviction. Updates to this version include some initial work towards optimizing HAProxy's memory allocation functions such that they align some objects and memory pools along cache line boundaries (64-byte chunks). Allocating memory aligned to the cache line boundaries helps keep data grouped by locality which prevents multiple threads thrashing the cache when the data is unaligned. This results in less contention, less locking, and fewer cache evictions.

• In this version, the mechanisms reusing and purging server-side idle connections saw improvements. Connections created when http-reuse is set to never or when using Basic Authentication can now be purged, preventing resource leaks, and some related features, such as deleting a server via the HAProxy Runtime API, will work more reliably, as the servers' idle connections are now better managed.

Flexibility

HTTP/3

You can now connect to backend servers with HTTP/3 over QUIC. After ensuring that your backend web server supports HTTP/3 and has it enabled, configure HAProxy to use the protocol. Because it's an experimental feature, add the expose-experimental-directives global directive. Then, update your servers to use quic4@ before the address and set the TLS arguments.

• tune.quic.be.cc.cubic-min-losses

• tune.quic.be.cc.hystart

• tune.quic.be.cc.max-frame-loss

• tune.quic.be.cc.max-win-size

• tune.quic.be.cc.reorder-ratio

• tune.quic.be.max-idle-timeout

• tune.quic.be.sec.glitches-threshold

• tune.quic.be.stream.data-ratio

• tune.quic.be.stream.max-concurrent

• tune.quic.be.stream.rxbuf

• tune.quic.be.tx.pacing

• tune.quic.be.tx.udp-gso

• tune.quic.listen

• tune.quic.mem.tx-max

The global directives that were prefixed with tune.quic.frontend still exist, but are deprecated in favor of the directives prefixed with tune.quic.fe. A few other QUIC directives were also deprecated, as the naming is consolidated.

Also in this version, the no-quic global directive has been renamed tune.quic.listen, which you can set to on or off to enable and disable the QUIC protocol.

Fetch methods

New fetch methods in this release are:

Converters

New converters in this release are:

Also, the aes_gcm_dec and aes_gcm_enc converters now accept an optional AAD argument that's sometimes required for authentication.

Runtime API

The HAProxy Runtime API has these changes:

• The add ssl crt-list command will no longer verify that the certificate's path matches its name in memory. That's because when using crt-store and crt-list together, you might assign aliases to your certificates, which wouldn't work with the previous path-based name validation. It's up to you to ensure that the certificate you're adding to the crt-list has the correct path, if not an alias.

• The show dev command, which displays platform and environment information, now reports the thread-to-CPU bindings.

• The show info command, which displays process information, now reports the number of added and removed lines in map and ACL files, to better detect scripts that continuously add entries, but don't remove entries as expected.

• When calling the show stat command with the typed argument, it now shows next to each metric the letter V for volatile or P for persistent. These appear after the already existing origin, nature, and scope letters in the output. This is part of HAProxy's new support for persisting metrics across reloads.

Usability

• You can get the HAProxy version in different formats. Pass the command-line arguments -vq for version, -vqs for the short version, or -vqb for the branch.

• If you've set the expose-experimental-directives global directive, but all of the experimental features you were using are no longer experimental, you'll get a reminder to remove the directive. That should help users in avoiding having experimental features enabled unintentionally.

• The global directive dns-accept-family that was introduced in the last version now defaults to the value auto. This directive lets you disable IPv4 or IPv6 DNS resolution. A value of auto will enable IPv4 DNS resolution and check for IPv6 connectivity at startup, then again every 30 seconds to determine whether to enable IPv6 resolution.

• Setting the global directive nbthreads to a total number of threads on which HAProxy should run while also declaring a thread-groups directive with a range of threads that exceeds that number will now emit a warning, and the missing threads will be removed. If a thread group is left with no threads at all, it causes a startup error.

• For users who compile HAProxy statically, an error can arise if they then try to use the user and group global directives, due to a known limitation in  libc. HAProxy will now emit a warning at startup if it detects this. In this case, use the uid and gid directives instead.

• Use the shell script haproxy-dump-certs to easily dump certificates from the HAProxy stats or master socket to the filesystem. Although, for those using the Data Plane API to enable ACME providers like Let's Encrypt, the API will save the certificates for you.

• The directive tune.disable-fast-forward is no longer experimental, so you don't need to set expose-experimental-directives to use it. This directive was introduced in version 2.8 and disables data fast-forwarding.

• For debugging, you may want to prevent all workers from being killed when a segfault occurs. You can use the global directive master-worker no-exit-on-failure.

• The default number of reloads defined by mworker-max-reloads is now 50.

• To build the halog utility, run make install-admin instead of make install. This change will help to ensure that users build halog with the correct options.

Modernization of subsystems

All applets, including the DNS, http-client, Lua, logs, peers, and Prometheus applets which were updated with this release, now maintain their own buffers rather than share buffers with the stream, which is used for socket reads and writes. Each applet having its own buffers requires less locking and improves synchronization, which reduces contention across the applets, improving the applets' scalability.

Deprecated features

These features are now deprecated, meaning they will be removed in a future version: 

• The backend directives dispatch and option transparent are deprecated and will emit a warning to replace them if used.

• Global directives prefixed with tune.quic.frontend are deprecated. Use the same directives prefixed with tune.quic.fe instead.

• The master-worker global directive has been deprecated. Use the command-line arguments -W or -Ws instead.

Breaking changes

This version has the following breaking changes:

• The minimum, default Linux kernel version, the one corresponding to the build target linux-glibc, has been updated to 4.17, which is a version older than all of the currently maintained LTS distros. This version was needed to support the new Kernel TLS feature.

• The program section, which allows you to start and run an external program as a child process, was deprecated in version 3.1 and is now removed.

• Using the same name for more than one frontend, backend, listen, defaults, or log-forward section is no longer allowed. Duplicated names, which have emitted a warning since version 3.1, will now emit an error at startup.

• Using the same name for more than one server in a backend isn't allowed.

• When configuring email alerts, you must enable the Lua implementation. If you add a mailers configuration section, but forget to load the Lua file, you'll get an warning.

• The backend directive http-send-name-header, which lets you send the name of the server HAProxy is connecting to as an HTTP request header, had always let you decide which HTTP header to use for that purpose. But now, it won't allow you to choose the headers connection, content-length, host, or transfer-encoding. Overwriting those headers would only cause an invalid request.

• When declaring an ACL, you can set the match type via the -m flag to explicitly compare the input value as a boolean, string, integer, etc. Specifying more than one match type after this flag is no longer allowed. Previously, HAProxy had silently used the last match type. Also, HAProxy will emit a warning when the match type is ambiguous, such as in path_beg -m reg. Is it matching the beginning of the path or using a regular expression?

• This version renames the no-quic global directive to tune.quic.listen, which lets you enable or disable the QUIC transport protocol on all frontend listeners.

Conclusion

HAProxy 3.3 is a feature-rich release that continues to make application delivery simpler, more scalable, and more secure. This release improves SSL/TLS processing and automation, observability, performance, flexibility, and usability, benefiting organizations of all sizes with lower operational costs, increased operational efficiency, and more reliable services.

Ready to upgrade or make the move to HAProxy? Now’s the best time to get started.

Additional contributors: Nick Ramirez, Iwan Price-Evans

This news has understandably caused a wave of anxiety. Ingress NGINX is one of the most popular controllers, and with the community now racing to find stable, supported, and future-proof alternatives, we've been inundated with questions.

Our message is simple: We are here to help.

Here at HAProxy, we have a clear path to help Ingress NGINX users migrate to a more powerful, reliable, and fully-supported solution. Whether you need an immediate fix or a long-term strategic upgrade, we have you covered.

Immediate choice: HAProxy Ingress Controller

For teams facing a tight migration deadline, the HAProxy Kubernetes Ingress Controller is the easiest, most immediate, and most direct replacement. You get a stable, production-ready solution right now for the smoothest transition possible.

This is the most direct path if you need to migrate on a timeline and are looking for an immediate, production-ready replacement.

The HAProxy Ingress Controller was developed as a major alternative to the NGINX Ingress Controller. Over time, its annotation system has been built out to provide equivalent functionality for the most critical, high-usage features that most users rely on:

• nginx.ingress.kubernetes.io/load-balance -> haproxy.org/load-balance

• nginx.ingress.kubernetes.io/backend-protocol -> haproxy.org/backend-protocol

• nginx.ingress.kubernetes.io/proxy-connect-timeout -> haproxy.org/proxy-connect-timeout

• nginx.ingress.kubernetes.io/cors-allow-origin -> haproxy.org/cors-allow-origin

• nginx.ingress.kubernetes.io/affinity -> haproxy.org/affinity

• ...and so on for things like rate limiting, timeouts, and cookies.

It's not a 100% drop-in replacement because it intentionally handles complex/unsafe things (like snippets) differently. Most of the time, you can find/replace the annotation prefixes.

We are committed to being transparent about where configurations differ and will provide clear, documented alternatives for NGINX-specific features.

Why HAProxy Ingress Controller is an upgrade, not just a replacement

The HAProxy Ingress Controller is built on the same HAProxy core that has been battle-tested for 20+ years, powering many of the world's largest websites. It's not just a replacement; it's a significant upgrade.

• Superior Performance: In our public, reproducible benchmarks, the HAProxy Ingress Controller consistently handles more than double the request throughput of Ingress NGINX while consuming significantly less CPU.

• Advanced Load Balancing: This is our core strength. You get immediate access to more sophisticated algorithms like "least connections" and "source IP hash," giving you far more precise control over your traffic distribution.

• Better Observability: Get a richer set of native Prometheus metrics out-of-the-box, without needing extra sidecars or exporters.

• Zero-Downtime Reloads: HAProxy is famous for its ability to apply configuration changes with zero dropped connections - a critical operational win.

• Robust Protocol Support: It offers first-class, reliable support for Layer 4 load balancing (e.g., for database connections, gRPC, or real-time streaming) in addition to its powerful Layer 7 (HTTP/S) capabilities.

This is all available as a free, open-source project with everything you need to make the switch.

Enterprise power when you need it

Future Proof: The HAProxy Unified Gateway

The Kubernetes community’s official long-term recommendation is to move toward the new Gateway API. We are all-in on this transition.

This week, we announced the beta of the HAProxy Unified Gateway. This is our next-generation controller, built from the ground up to provide a single, unified way to manage both Kubernetes Gateway API (available now) and Ingress resources (available in 2026). With support for both resource types, users will be able to:

1. Adopt HAProxy Unified Gateway.

2. Use it in "Ingress mode" for an easy migration from Ingress Controller.

3. Enable Gateway API resources on that same controller, migrating from Ingress to Gateway API resources at their own pace.

This is the best part: making the change to the HAProxy Kubernetes Ingress Controller now sets you up for future success.

It's simple to migrate from HAProxy Kubernetes Ingress Controller to HAProxy Unified Gateway because they share the same core HAProxy technology and an identical configuration philosophy. By migrating to the HAProxy Ingress Controller today, you solve your immediate Ingress NGINX problem with a superior controller and place your team on the clearest, most proven path to the future of Kubernetes networking.

Common Migration Questions

• Will I need to rewrite all my Ingress resources?

  • Mostly no. For many resources, you will only need to update the ingressClassName. Our migration guides will clearly document the mapping for any annotations that differ.

• What about nginx.conf snippets or custom ConfigMaps?

  • This is a key security improvement. The Ingress NGINX retirement announcement specifically cited snippets as "insurmountable technical debt." We provide a safer, structured way to apply custom logic without allowing arbitrary configuration injection. 

  • Our migration guides will show you how to convert common snippet-based patterns to this more secure model. Most of the time, you won't need a snippet at all, because the feature you want already has a dedicated annotation.

• Is the open-source HAProxy Ingress Controller really free?

  • Yes! The HAProxy Ingress Controller is, and will always remain, a free and open-source project.

Start Your Migration Today

The Ingress NGINX retirement isn't happening overnight, but waiting until March 2026 means competing for support when everyone else is migrating. Start your evaluation now, and you'll have time to migrate carefully rather than urgently.

1. Get the Quick Start Guide: Get HAProxy Ingress Controller running in a test namespace in 15 minutes.
   HAProxy Kubernetes Ingress Controller Documentation

2. Join our Slack: Connect with our dedicated migration support team and the wider community.
   HAProxy Slack Community #ingress channel

3. Talk to an Expert: If you're running a complex environment, our enterprise team can provide a free consultation to map out your migration.
   Find out more and get a trial

The continuous shift toward containerization means businesses are migrating more complex, mission-critical workloads to Kubernetes. This trend necessitates traffic management solutions that support diverse protocols (such as TCP, UDP, HTTP, and gRPC) and sophisticated organizational architectures, while delivering exceptional performance and efficiency.

To address these modern cloud-native requirements, HAProxy Technologies today announced the public beta of the new HAProxy Unified Gateway for Kubernetes at KubeCon + CloudNativeCon North America 2025, where the company is a Diamond sponsor. HAProxy Unified Gateway is a free, open-source product dedicated to providing unified, high-performance, Kubernetes-native application routing for both Gateway API and Ingress – with a powerful enterprise implementation coming in 2026, integrated directly into the groundbreaking HAProxy Fusion Control Plane.

HAProxy Unified Gateway provides flexible protocol support, role-based access control, and a low-risk, gradual migration path for organizations moving from Ingress to Gateway API. Combined with HAProxy’s legendary performance and reliability, these key features support the needs of modern applications and evolving organizations.

Built on HAProxy’s 20+ years of open-source innovation, HAProxy Unified Gateway is designed to be the most dependable and scalable solution for cloud-native application delivery within the Kubernetes community.

Quick start

You can get the Docker image for HAProxy Unified Gateway’s beta release on Docker Hub, and contribute to the community project on GitHub.

In the GitHub project, you can find an example of how to deploy HAProxy Unified Gateway as well as examples of how to use various features. 

If you want to learn how to set up HAProxy Unified Gateway with a GatewayClass, a new Gateway, and an HTTPRoute, you can see a step-by-step example with configuration in this article.

Why Kubernetes users need more than Ingress

For years, the Kubernetes Ingress standard has served a foundational role, but it is fundamentally unsuited to the demands of today’s complex, high-scale environments. The core limitations of Ingress controllers include:

• Protocol constraints: Ingress typically lacks flexible protocol support, often restricting traffic to HTTP/S unless you use a workaround like vendor-specific ConfigMaps or port mapping. This inflexibility limits the types of applications – such as those relying on TCP or UDP – that can be easily migrated and managed behind a standard Ingress controller, slowing innovation and modernization.

• Operational risk: The standard uses a single Ingress object for all configuration. This lack of “separation of concerns” or robust role-based access control (RBAC) forces organizations to either create operational bottlenecks by restricting management to one team or risk errors and conflicts by allowing multiple teams to modify the same resource. This design limits scalability and undermines the core Platform Engineering goal of enabling teams to operate safely with autonomy.

HAProxy Unified Gateway is engineered to leverage the modern Gateway API standard immediately, and relieve pressure on organizations with substantial Ingress deployments by providing unified support for both Ingress and Gateway API.

Simple adoption of the latest Kubernetes Gateway API standard

The core use case of HAProxy Unified Gateway lies in its support for the latest Kubernetes Gateway API, delivering the role-based access, flexibility, and portability required for cloud-native ecosystems.

HAProxy Unified Gateway launches with crucial support for TCP and HTTP/S (including TLS termination) via its Gateway API implementation, a level of flexible protocol support that was challenging under the old Ingress standard. With future releases, we plan to make HAProxy Unified Gateway progressively conformant with the Gateway API specification, which includes supporting GRPCRoute and  more. This flexibility empowers the community to quickly onboard a wider variety of application workloads, including legacy or specialized Layer 4 (L4) applications, which will accelerate modernization initiatives.

Additionally, the upcoming enterprise implementation via HAProxy Fusion and HAProxy Enterprise will support UDP for applications that prioritize real-time communication.

Role-based access control

The Gateway API’s role-oriented design is another significant benefit, resolving the complexity of the Ingress standard. HAProxy Unified Gateway implements RBAC through the Gateway API, which enables a clear separation of concerns among Cluster Operators, Infrastructure Providers, and Application Developers.

This design allows teams to safely share network infrastructure without direct coordination, centralizing control over the underlying Gateway while distributing flexibility to application teams to manage their own routing rules. This directly reduces operational complexity and lowers the risk of configuration errors and conflicts.

Low-risk migration from Ingress to Gateway API

HAProxy Unified Gateway is designed to solve the difficult choice faced by organizations migrating from Ingress to Gateway API (the "massive cut-over" versus the complex "gradual migration"). Our roadmap includes the future integration of both Ingress and Gateway API standards in a single HAProxy Unified Gateway instance (coming in 2026). This unification will provide a low-risk, gradual migration path with consistent management and centralized observability, eliminating the need to manage separate products from different vendors.

Unrivaled performance and efficiency

HAProxy Unified Gateway is built on the proven HAProxy core, widely recognized as the world’s fastest software load balancer. This foundation ensures HAProxy Unified Gateway brings industry-leading throughput, latency, and resource efficiency to Kubernetes traffic management using the Gateway API.

Performance as a cost lever

Low performance and efficiency significantly increase the cost of scalability in cloud-native deployments. An inefficient Gateway – like any inefficient component – directly increases resource consumption and, therefore, cloud costs. 

However, the indirect consequences for the resilience of a Kubernetes cluster are perhaps even greater. A poorly performing Gateway, requiring more instances, results in more calls to the Kubernetes API, which can lead to synchronization problems and bring down an entire cluster – something to be avoided at all costs.

HAProxy Unified Gateway is cost-effective and resilient, delivering the exceptional performance and efficiency HAProxy is known for. The HAProxy core is proven to scale well, reaching over 2 million HTTPS requests per second on a single AWS Graviton2 instance. HAProxy is used by some of the world’s largest platforms to handle hundreds of billions of requests a day with low latency. 

How is this possible? HAProxy uses a high-performance event-driven architecture; advanced multi-threading with thread groups and automatic CPU binding; and a task scheduler that balances high throughput with low latency. These core architectural choices translate directly into resource savings, enabling users to handle large-scale traffic with fewer (and smaller) machines.

This fundamental performance ensures HAProxy Unified Gateway can manage bigger and more demanding Kubernetes applications while reducing the total cost of ownership for cloud infrastructure.

Operational simplicity and reliability

HAProxy Unified Gateway is engineered to make Kubernetes networking simple and reliable, leveraging more than two decades of open-source expertise.

Streamlined deployment

To simplify implementation and management, HAProxy Unified Gateway deploys efficiently in a single Application Stack. This design minimizes the number of moving parts and reduces points of failure compared with products requiring multi-pod deployments.

Battle-tested reliability

HAProxy Unified Gateway’s reliability is underwritten by the HAProxy open-source core, which has been in continuous development and production use for 20+ years. The core is known for being extremely robust, built with extensive internal checks that prevent service outages and other failures. This foundation of reliability, trusted by the world’s leading platforms and public sector organizations, ensures dependability for the most critical traffic management needs.

HAProxy Unified Gateway is and always will remain a free, open-source product dedicated to the Kubernetes community and the adoption of the Gateway API standard. We encourage contribution and participation through our community channels.

For organizations whose requirements extend beyond a single Kubernetes cluster – such as global governance, multiple gateway classes and multi-cluster management, or centralized security – HAProxy Unified Gateway provides a seamless evolution path to a powerful enterprise solution.

The enterprise implementation of a unified Ingress/Gateway API capability will be introduced in 2026, integrated in HAProxy One – the world’s fastest application delivery and security platform. HAProxy One consists of HAProxy Enterprise (a flexible data plane), HAProxy Fusion (a scalable control plane), and HAProxy Edge (a secure edge network). 

The enterprise implementation in HAProxy One will provide a natural extension of the open-source product, providing critical centralized capabilities without requiring users to completely rewrite their foundational traffic management layer. By migrating their Gateway API configuration seamlessly from the open-source HAProxy Unified Gateway to HAProxy One, users will gain the following benefits:

1. Universal traffic management: The ability to consolidate cloud-native traffic management (Gateway API and Ingress) with other methods – north-south and east-west – across any environment, including on-premises, multi-cloud, and multiple Kubernetes clusters (supporting Kubernetes federation initiatives).

2. Intelligent multi-layered security: Industry-leading edge security, including DDoS protection, bot management, global rate limiting, and a robust Web Application Firewall (WAF).

3. Centralized control plane: HAProxy Fusion provides centralized management, observability, and automation for all HAProxy Enterprise instances, along with high-performance service discovery, supporting the massive scale of large Kubernetes clusters.

This strategy ensures that the core, high-performance, Kubernetes-standard routing functionality remains free and open-source, while providing an enterprise upgrade path that delivers the platform consolidation and advanced security needed for more complex global deployments.

Example: deploying a Gateway and an HTTPRoute using HAProxy Unified Gateway

It’s simple to get started with HAProxy Unified Gateway. You can easily configure it to route traffic through Kubernetes. In this example, we will:

1. Define a GatewayClass

2. Deploy a Gateway

3. Deploy an HTTPRoute

Step 1: Define a GatewayClass

First, you need to define a GatewayClass that your Gateway resources will use.

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: haproxy
spec:
  controllerName: gate.haproxy.org/hug

The GatewayClass is a similar construct to the Ingress class. The GatewayClass needs a name and a controller. The controllerName indicates that this GatewayClass belongs to HAProxy Unified Gateway (abbreviated here to “hug”). Every Gateway that uses this GatewayClass will also belong to the controller. 

Step 2: Deploy a Gateway

After you have deployed the GatewayClass, you need to deploy a Gateway.

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: hug-gateway
spec:
  gatewayClassName: haproxy
  listeners:
  - name: http
    port: 31080
    protocol: HTTP
    allowedRoutes:
      kinds:
      - group: gateway.networking.k8s.io
        kind: HTTPRoute
    hostname: "*.haproxy.local"

The Gateway needs a name, it needs to be connected to our gatewayClassName, and it needs to contain at least one listener. In HAProxy terms, a listener is a Frontend that defines the port to listen to and the type of traffic it accepts.

Step 3: Deploy an HTTPRoute

After you have deployed the Gateway, you can deploy the HTTPRoute.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: route-hello-world-exact
spec:
  parentRefs:
  - name: hug-gateway
    sectionName: http
  hostnames:
  - "exact.haproxy.local"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: hello-world
      port: 8888

The HTTPRoute needs a name, a Gateway, and routing rules. You can use parentRefs to show that this particular HTTPRoute is connected to our Gateway. Each rule also needs to specify at least one service to which this route will point traffic. 

After you have deployed the HTTPRoute, you can safely check if the service is reachable through the controller.

Try HAProxy Unified Gateway today and share feedback on the beta release

The beta release of HAProxy Unified Gateway marks a pivotal moment in cloud-native traffic management. By adopting the Kubernetes Gateway API standard, HAProxy Unified Gateway eliminates the complexity and limitations of legacy Ingress resources while leveraging HAProxy’s legendary performance and two decades of experience.

HAProxy Unified Gateway delivers unified, high-performance, Kubernetes-native application routing backed by an incredible open-source community and provides a low-risk pathway toward modernizing Kubernetes networking.

The HAProxy Unified Gateway beta is now available for download on Docker Hub. We encourage the community to try the beta, explore the documentation, and actively contribute to the project to help shape the final v1.0 release (and beyond).

With this release, we’re introducing HTTPS health checks to Global Server Load Balancing (GSLB), new partitioning for larger firmware updates, enhanced web application firewall (WAF) functionality, and our new Threat Detection Engine (TDE). These features bring HAProxy ALOHA and HAProxy Enterprise closer together, expand scalability for future upgrades, and provide stronger protections for modern applications.

New to HAProxy ALOHA?

HAProxy ALOHA provides high-performance load balancing for TCP, UDP, QUIC, and HTTP-based applications; SSL/TLS processing; PacketShield DDoS protection; bot management; and a next-generation WAF.

HAProxy ALOHA combines the performance, reliability, and flexibility of our open-source core (HAProxy — the most widely used software load balancer) with a convenient hardware or virtual appliance, an intuitive GUI, and world-class support.

HAProxy ALOHA benefits from next-generation security layers powered by threat intelligence from HAProxy Edge and enhanced by machine learning.

What’s new

HAProxy ALOHA 17.5 includes exclusive new features — plus many core features from HAProxy 3.2 (community version) and HAProxy Enterprise 3.2. You can see what's new in our HAProxy 3.2 and HAProxy Enterprise 3.2 announcements. 

Key highlights unique to HAProxy ALOHA 17.5 include:

• Global Server Load Balancing (GSLB) enhanced with HTTPS health checks – Customers can now offload health checks, secured via SSL/TLS, to HAProxy ALOHA. Easily view and maintain server health across thousands of remote DNS zones by monitoring for health check responses, unexpected error codes, and server recovery updates. 

• New partitioning for firmware updates – HAProxy ALOHA users can now install much larger firmware files up to 1GB in size. This paves the way for future HAProxy ALOHA modules, database integrations, and general feature enhancements.

For a complete list of HAProxy ALOHA 17.5 feature updates and enhancements, see our release notes.

New features incorporated from HAProxy Enterprise

Additionally, HAProxy ALOHA 17.5 adds the following features and enhancements from HAProxy 3.2 and HAProxy Enterprise 3.2: 

• New Threat Detection Engine (TDE) – Integrated with the HAProxy Enterprise Bot Management Module, TDE provides sophisticated detection, classification, and industry-standard labeling of application DDoS, brute force, web scraper, and vulnerability scanner threats without compromising performance or customer privacy. 

• Custom WAF Profiles – Customers can now create, customize, and apply a unique WAF ruleset for each WAF Profile, applying them selectively across different applications or locations. 

• New AWS-LC integration – The AWS-LC library replaces OpenSSL and provides the best available performance at any scale, especially on modern multi-core systems, with robust QUIC support.

Ready to upgrade?

To start the upgrade process, visit the installation instructions for HAProxy ALOHA 17.5.

Secure GSLB health checks deliver deeper observability

Two supplemental monitoring plugins offered some useful workarounds, but were less resilient than desired and required administrators to set up child processes across numerous DNS zones. These active processes could be resource intensive under certain conditions. We wanted to maximize GSLB reliability, scalability, performance, and simplicity for these complex deployments without needing workarounds. Our goal was to give GSLB users deeper observability everywhere on par with HAProxy Enterprise's functionality. 

HAProxy ALOHA 17.5 introduces encrypted and performant GSLB health checks for distributed infrastructure. Customers can enable secure GSLB health checks over TCP/HTTP using the new ssl keyword parameter that users add to their existing http-check directive. This piece of the configuration is very simple and offers a seamless UX, provided HAProxy ALOHA also has GSLB configured across relevant DNS zones. 

The GSLB code itself remains largely unchanged. Users just need to permit HAProxy to accept the clear health check from the GSLB server before triggering the HTTPS portion of the health check. 

This upgrade directly mitigates risk associated with potentially unsecured connections between a GSLB server (often running in a public cloud) and private, on-premises data centers.

• It's highly resilient

• It's transparent from the client's perspective 

• Encryption is neither enforced nor skipped on the client side, itself

• DNS zone names remain readable 

Overall, the mechanisms driving this latest update to GSLB should feel familiar to existing HAProxy ALOHA users. HTTPS health checks offer greater control over your security posture without revealing too much of your monitoring logic to potential bad actors. Your GSLB server(s) will concurrently run HAProxy alongside the DNS daemon to support these functions. DNS queries are handled over UDP/TCP with the GSLB daemon to obtain the IP address of the closest reachable datacenter.

Improved firmware update partitioning

Firmware updates have long been a staple of HAProxy ALOHA, enabling new features and boosting lower-level optimization across hardware appliances. While useful, file management within HAProxy ALOHA has been somewhat limited — with individual file uploads capped at 32MB. We wanted more flexibility to enhance future versions of HAProxy ALOHA while empowering users to implement new infrastructure components. 

HAProxy ALOHA 17.5 now allows users to install and run individual firmware files up to 1GB in size. This filesystem change also enables users to readily upload their data-hapee bot management rules and MaxMind integrations — delivering geolocation-supported fraud detection, traffic analysis, geo-targeting, improved compliance, and more. This opens the door for continual HAProxy Enterprise module integrations and helps bridge the gap between both products. 

This native file support greatly simplifies firmware handling for HAProxy ALOHA users. The SCP protocol is no longer required to transfer files smaller than 64MB, and external tools are no longer needed to access /tmp or /app folders on the system. However, this file manager behavior depends on the size of its internal buffers, which we've increased for this release. 

Users can manage everything with much less friction than in previous versions. This setup offers improved transparency by simplifying file management natively.

Upgrade to HAProxy ALOHA 17.5

When you are ready to upgrade to HAProxy ALOHA 17.5, follow the links below:

Conclusion

HAProxy ALOHA 17.5 further enhances the performance and security of HAProxy ALOHA, while paving the way for additional improvements and features. This latest release is also an important step towards greater feature parity with HAProxy Enterprise — unlocking deeper support for HAProxy Enterprise modules both now and in the future.

Interested in learning more about HAProxy ALOHA and taking it for a test drive? Request a quote or free trial today.

HAProxy Enterprise 3.2 is a pivotal release that reinforces the product’s identity as both the world’s fastest software load balancer and a sophisticated edge security layer. This release brings next-generation security intelligence, extends its industry-leading performance, and expands the native routing and integration capabilities in HAProxy Enterprise.

The headlining addition in HAProxy Enterprise 3.2 is the introduction of the Threat Detection Engine (TDE) within the Bot Management Module. The TDE provides sophisticated detection, classification, and industry-standard labeling of application DDoS, brute force, web scraper, and vulnerability scanner threats without compromising latency or customer privacy. Crucially, the TDE is engineered to run anywhere — even in highly controlled or air-gapped environments — without requiring any external connection or sending customer data to a third party. This design gives customers maximum control over their infrastructure, simplifies data compliance, and removes vulnerable external dependencies.

HAProxy Enterprise 3.2 is a foundational component of the HAProxy One platform, in which the data plane, control plane, and secure edge network work together seamlessly. HAProxy Fusion 1.4, coming later this year, carries forward our security innovation momentum, bringing the Security Control Plane announced earlier this year at HAProxyConf 2025. Together, the groundbreaking Threat Detection Engine and Security Control Plane (featuring the Threat-Response Matrix for intuitive, visual policy building) will offer a unique combination of next-generation security intelligence and next-generation security user experience (UX).

New to HAProxy Enterprise?

HAProxy Enterprise 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 API Management, Container Networking, DDoS Protection, Web Application Firewall (WAF), and Load Balancing.

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

What’s new?

HAProxy Enterprise 3.2 incorporates all features and enhancements previously announced in the community version of HAProxy 3.2, which extend performance, flexibility, and observability. These include automatic CPU binding, which optimizes performance on modern multi-core systems (with a mix of performance and efficiency cores), and improvements to the Runtime API and Prometheus exporter — making monitoring and traffic inspection simpler.

The additional enhancements within HAProxy Enterprise 3.2 affect four key areas.

Ready to upgrade?

When you are ready to start the upgrade procedure, go to the upgrade instructions for HAproxy Enterprise.

Next-generation security and intelligence

The new Threat Detection Engine: sophistication without the security tax

Businesses today face persistent threats from sophisticated bots executing application layer DDoS attacks, content scraping for unlawful use or LLM training, and vulnerability scanners that precede malicious attacks. Historically, most security solutions employ brute-force methods leading to high resource usage (and therefore high costs in cloud or on-premises deployments), or apply overly zealous rules that generate disruptive false positives, or are only available as SaaS/cloud products that run outside your network.

Accurate out-of-the-box

The engine achieves its accuracy through novel and proprietary techniques that combine multiple signals, including reputational and behavioral signals, directly within HAProxy Enterprise. Our team’s deep expertise in security, data science, and machine learning yields highly precise and actionable threat classifications with minimal configuration or tuning required out-of-the-box. 

The threat detection algorithms are derived from our machine learning models, which are trained externally using anonymized traffic data collected from HAProxy Edge. This pre-training mechanism provides the benefit of global threat intelligence without ever requiring customer data or live external connections, resulting in reduced risk and improved operational efficiency due to a low rate of false positives.

Dynamic adaptability and flexibility

The Threat Detection Engine provides dynamic detection of application DDoS attacks, taking into account both real-time and historical traffic data to identify anomalies; this is essential because the threshold for what constitutes an attack varies significantly between different applications. This capability allows the engine to adapt its protection automatically without tuning the configuration manually, which leads to lower implementation costs.

You have complete control over when and how HAProxy Enterprise responds to threats identified by the TDE, including combining the TDE’s threat labels with other signals generated by HAProxy Enterprise and its various modules, to determine whether to trigger a response. For example, while you may trigger a response to all vulnerability scanners, you may choose to only trigger a response to web scrapers if they also match specific geo-locations.

Furthermore, you can easily customize the response to any threat type using HAProxy Enterprise’s flexible toolkit, which includes blocking, denying, rate limiting, CAPTCHA challenges, tarpitting, and more. This dynamic nature allows for tailored and precise enforcement.

Incredibly efficient and performant

The design of the TDE directly addresses the performance cost often imposed by sophisticated security processing. It maintains ultra-low latency while significantly reducing memory and CPU consumption compared to typical methods. The TDE specifically gains a huge latency advantage over solutions that rely on an additional network hop (such as for an external connection to a security scanner), ensuring that security processing does not degrade the user experience (UX) for legitimate traffic or inflate infrastructure costs. This focus on performance ensures that the TDE maintains the high-speed integrity expected of the HAProxy One platform.

Private and secure: the compliance advantage

One of the most compelling characteristics of the TDE is its security and privacy model. All the intelligent threat detection processing occurs locally on an HAProxy Enterprise node. Despite leveraging algorithms derived from advanced machine learning, the TDE does not involve third-party or off-site processing of any customer or user data, either synchronously or asynchronously, and requires no external connection to function. 

This architectural choice is critical for organizations facing stringent compliance requirements. By eliminating vulnerable external dependencies and third-party data processing (with its stringent requirements), the TDE simplifies compliance and makes the solution viable for highly regulated or air-gapped environments. This design successfully achieves SaaS/cloud-level security intelligence while maintaining strict operational control and data privacy on-premises.

Threat Detection Engine (TDE) value matrix

Customizable protection with new WAF Profiles

The HAProxy Enterprise Web Application Firewall (WAF), powered by the Intelligent WAF Engine, previously offered a default mode providing the highest accuracy and performance, and an optional OWASP CRS compatibility mode for industry-standard transparency. These modes are effective for customers who do not need significant customization. However, we wanted to give you more power and flexibility by simplifying WAF rule customization even further. 

HAProxy Enterprise 3.2 introduces support for customizable WAF Profiles. You can now create, customize, and apply a unique WAF ruleset for each WAF Profile, applying them selectively across different applications or locations. This granular control is essential for tailoring security across diverse application portfolios. 

By fine-tuning WAF security based on the unique traffic patterns and security requirements of individual applications, you can minimize false positives, reduce alert fatigue, and ensure an improved UX for your legitimate users. Additionally, WAF Profiles are completely transparent — including the base ruleset and every custom rule — with support for extensive logging to help you understand exactly why specific WAF rules were triggered.

Secure bot mitigation with an enhanced native CAPTCHA Module

CAPTCHA challenges have become an essential weapon in the fight to mitigate unwanted bot traffic. HAProxy Enterprise has featured a native CAPTCHA Module since version 3.0, providing simple configuration and flexible integration. It supports Google reCAPTCHA v2 and v3, reCAPTCHA Enterprise, hCaptcha, Friendly Captcha (frCaptcha), Turnstile, and more — including custom providers — which enables multiple CAPTCHA types (beyond the “I'm not a robot” checkbox). It also allows for multiple CAPTCHA challenges during a session if anomalous behavior is detected.

We wanted to build on this simplicity and flexibility, making the module even more robust and secure.

The enhanced native CAPTCHA Module in HAProxy Enterprise 3.2 ensures continuity and a seamless UX in the event that an external CAPTCHA verification server is unreachable; in this condition, the CAPTCHA Module can act like the challenge is solved and set a valid CAPTCHA cookie that will expire after a set time. Critically, security is enhanced by computing a 100% unique CAPTCHA key, eliminating the small risk of sophisticated attackers exploiting key reuse. This comprehensive, resilient, secure, and cost-efficient native solution can fully replace the need for expensive external services such as Google reCAPTCHA Enterprise.

Unified security management (a look ahead to HAProxy Fusion 1.4)

The new security capabilities introduced in HAProxy Enterprise 3.2 are part of a broader vision to deliver a modern security platform through HAProxy One — a vision that also includes unified security management. The advanced controls, customization options for WAF Profiles, and the detailed threat data generated by the TDE will be fully complemented by the Security Control Plane coming soon in HAProxy Fusion 1.4. 

This update to the authoritative control plane for HAProxy Enterprise is expected to release in November 2025 and will allow customers to manage centralized security policies, apply customized Security Profiles, and configure policies intuitively using a new visual policy builder called the Threat-Response Matrix.

Performance and scalability

AWS-LC: consistently higher TLS performance

Secure HTTPS connections, negotiated via the SSL/TLS protocol, rely heavily on the performance and features of the underlying TLS library. Previously, HAProxy used OpenSSL by default; however, version 1.1.1 – which was well-regarded – reached end-of-life in 2023. Although we had an extended support license to continue using it in HAProxy Enterprise, this was not a long-term solution. Meanwhile, OpenSSL version 3.0 LTS introduced significant performance regressions that subsequent versions have not adequately resolved.

Our benchmarks, published in May 2025 in our article The State of SSL Stacks, reported massive performance degradation when running HAProxy built with OpenSSL 3+, particularly when multithreaded on systems with 16 threads or more, limiting HAProxy's expected HTTPS performance. 

The need to process secure connections efficiently is paramount, as excessive processing time can constrain scalability, limit the total number of simultaneous connections, and inflate the resource cost of meeting high traffic demands.

In HAProxy Enterprise 3.2, we have strategically replaced the default OpenSSL library with AWS-LC. AWS-LC is a general-purpose TLS library maintained by the AWS Cryptography team, based on code from Google BoringSSL and the OpenSSL project.

The benefits of this transition are substantial, as demonstrated in our latest benchmarks comparing HAProxy Enterprise 3.0 built with OpenSSL 1.1.1 and HAProxy Enterprise 3.2 built with AWS-LC.

• We tested each system using two public key encryption algorithms: RSA 2048-bit keys and ECDSA 256-bit keys.

• We tested each system in AWS on the same instance types, starting at 8 threads and scaling up to 64 threads at increments of 8 threads.

• To stress-test the systems with the worst-case scenario for server-side capacity, we disabled TLS-reuse so that every connection would trigger a key exchange. Note that this scenario only tests the capacity of the systems to process new connections and TLS handshakes, and is not equivalent to a measure of requests-per-second, which would measure much higher.

The biggest benefits are realized as systems scale up with more threads.

• With RSA, HAProxy Enterprise 3.2 had 34% higher performance at 16 cores, which increased to 54% at 64 cores.

• With ECDSA, HAProxy Enterprise 3.2 had 55% higher performance at 16 cores, which increased to a staggering 156% at 64 cores – more than twice as performant.

These TLS performance improvements make HAProxy Enterprise even more scalable for high-traffic applications compared with previous versions built with OpenSSL 1.1.1, which was the best-performing TLS library from OpenSSL. Furthermore, AWS-LC includes robust support for the QUIC protocol, which simplifies the modernization of application infrastructure with efficient, modern transport protocols.

The adoption of AWS-LC is a critical engineering step that safeguards the platform's core performance identity, ensuring that performance remains uncompromised even as advanced security features are added.

Open source performance enhancement from HAProxy 3.2

Beyond the AWS-LC shift, HAProxy Enterprise 3.2 benefits from performance accelerators inherited from the community version. QUIC protocol support is now faster, more reliable on lossy networks, and more resource-efficient. Additionally, automatic CPU binding simplifies management and squeezes more performance out of large-scale, multi-core systems by ensuring optimal resource utilization, which enabled Criteo to reduce CPU usage by 20% with the same level of network traffic.

Global routing and resilience

Simplifying geo-distribution: native RHI and enhanced GSLB

Routing external traffic across multiple autonomous data centers relies heavily on technologies like Border Gateway Protocol (BGP) for path announcement and Global Server Load Balancing (GSLB) for data center selection. HAProxy Enterprise has supported Route Health Injection (RHI) over BGP for a while, but this previously required multiple configuration files and the use of an external process. We wanted to give you a simpler way to manage RHI configuration, with improved observability.

HAProxy Enterprise 3.2 introduces a native RHI Module. This native module calculates and announces BGP routes directly within the HAProxy process itself. You can also make RHI conditional, for example, only announcing a route if a minimum number of healthy servers are detected at a specific location. The result is a simple native configuration and native logs that dramatically increase observability and simplify troubleshooting for geo-routing issues.

Here's an example that shows the RHI Module's syntax:

Unified traffic management: UDP ACLs and session persistence

Since the introduction of the HAProxy Enterprise UDP Module in version 2.9, HAProxy Enterprise has offered reliable, high-performance UDP proxying and load balancing. But we wanted to add more advanced functionality.

In HAProxy Enterprise 3.2, the HAProxy Enterprise UDP Module now supports ACLs and basic fetches based on attributes such as source IP and destination IP. This enables more advanced routing logic for UDP traffic. In the example below, we set up split-brain DNS:

Operational modernization and integration

Last but not least, this release reduces integration complexity by standardizing crucial services into native, easy-to-manage HAProxy configurations.

Modern identity: native Open ID Connect (OIDC) SSO

Enabling Single Sign-On (SSO) at the proxy layer offloads security risk and complexity from application servers. HAProxy Enterprise has supported SSO integration for some time, but this has had limited protocol support (SAML, Kerberos, or ADFSPIP) and relied on HAProxy’s Stream Processing Offload Engine (SPOE) to integrate with an external SSO process. We wanted to give you more flexibility, along with the simplicity of native HAProxy configuration. 

HAProxy Enterprise 3.2 introduces modernized SSO with a new native Open ID Connect (OIDC) Module, along with enhancements to the SAML Module. The native modules run inside the HAProxy Enterprise process, eliminating the need for SPOE, and use standard HAProxy configuration syntax, resulting in simpler implementation. In addition, native support for the OIDC standard allows seamless integration with a vast array of modern third-party SSO providers — including Google, Apple, Facebook, Okta, Microsoft Active Directory, and Microsoft Entra ID (formerly Azure Active Directory).

By standardizing complex identity management into simple native modules, HAProxy Enterprise 3.2 reduces risk, lowers implementation costs, enables more rapid innovation, and improves operational efficiency across the platform.

Simplified observability: Global Profiling Engine (GPE) configuration

The Global Profiling Engine (GPE) aggregates HAProxy stick table data, enabling real-time, cluster-wide tracking of users — a key observability feature. To help customers take advantage of GPE’s powerful capabilities, we wanted to make it easier to configure GPE to listen on multiple ports, where previously this required a new configuration line for every port.

In HAProxy Enterprise 3.2, GPE configuration is streamlined, allowing you to configure the engine to listen to all ports using a simple one-line configuration option. This reduced configuration debt is a major benefit for large-scale deployments, resulting in lower implementation costs and significantly improved operational efficiency.

Conclusion

HAProxy Enterprise 3.2 is a landmark release that strategically positions the HAProxy One platform as an intelligent edge security solution. By integrating the highly efficient, private, and exceptionally accurate Threat Detection Engine, HAProxy Enterprise now provides next-generation security intelligence without negatively impacting performance or compliance, unlike many SaaS/cloud-based solutions. This security sophistication is built upon a foundation of unrivaled performance, which is guaranteed by the architectural shift to the AWS-LC TLS library, unlocking critical scalability.

HAProxy One's commitment to operational excellence is further demonstrated through the standardization of complex functions — including RHI, OIDC, and CAPTCHA — into powerful native HAProxy modules. 

HAProxy Enterprise 3.2 reinforces its status as the fastest, most flexible, and most reliable software load balancer, and significantly advances its position as a modern and sophisticated edge security layer.

Upgrade to HAProxy Enterprise 3.2

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

​Try HAProxy Enterprise 3.2

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. As part of the HAProxy One platform, HAProxy Enterprise’s no-compromise approach to secure application delivery empowers organizations to deliver multi-cloud load balancing as a service (LBaaS), web app and API protection, API/AI gateways, Kubernetes networking, application delivery network (ADN), and end-to-end observability.

There has never been a better time to start using HAProxy Enterprise. Request a free trial of HAProxy Enterprise and see for yourself.

If you're using an affected version of the HAProxy Kubernetes Ingress Controller, you should upgrade to a fixed version as soon as possible. A workaround is available for those who cannot upgrade immediately.

Vulnerability details

• CVE Identifier: CVE-2025-59303

• CVSSv3 Score: 6.4

• Description:

  • A security vulnerability has been identified in HAProxy Kubernetes Ingress Controller, where the config-snippets feature can be misused. Users with Kubernetes permissions to create or modify Ingress or Service objects can inject specific HAProxy configurations. These configurations can then be used to access sensitive Kubernetes service account tokens from the ingress controller's environment.

  • Successfully exploiting this vulnerability allows an attacker to obtain the ingress controller's token secret. This secret can then be used to access any data available to the ingress controller, leading to privilege escalation within the Kubernetes cluster. This risk is particularly high in multi-tenant or hosted environments where end-users may be untrusted.

Affected versions and remediation

HAProxy Technologies released new versions of the HAProxy Kubernetes Ingress Controller on Wednesday, October 8, 2025. These releases patch the vulnerability described above in CVE-2025-59303.

This fix introduces the preloaded libblock_secrets.so library to intercept and block the HAProxy process from accessing sensitive Kubernetes secret paths.

Upgrade instructions

Users of affected products should upgrade immediately by pulling the latest image version for their respective release track.

Mitigation and workaround details

Disabling the config-snippets feature can mitigate the vulnerability for users who cannot upgrade immediately. This will prevent users from injecting arbitrary HAProxy configuration.

You can disable this feature by starting the Ingress Controller with the following flag:

--disable-config-snippets

Please note that this will disable all custom configuration snippets throughout your environment.

Future improvements

Starting with version 3.2 of the HAProxy Kubernetes Ingress Controller, the config-snippets feature will be disabled by default and will become an opt-in capability. We encourage users to migrate towards using CRDs and custom annotations, which provide administrators with granular control over configurable parameters.

Support

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

This vulnerability impacts configurations using JSON parsing function on all current versions of HAProxy, including HAProxy Community Edition, HAProxy Enterprise, HAProxy ALOHA appliances, and HAProxy Kubernetes Ingress Controller.

We strongly recommend that you upgrade to the latest version if you use the following JSON parsing functions: json_query(), jwt_header_query(), jwt_payload_query(). There is no workaround available other than updating HAProxy.

Vulnerability details

• CVE Identifier: CVE-2025-11230

• CVSSv3 Score: 7.5 (HIGH)

• Description: 

  • A flaw was discovered in how the mjson library, used by HAProxy, processes extremely large numbers. This is identified in CVE 2023-30421.

  • When HAProxy encounters requests containing these large numbers (e.g., 1e1000000000000000) in certain JSON parsing contexts (specifically json_query, jwt_header_query, or jwt_payload_query sample fetch methods), it can process for approximately one second before aborting.

  • This Inefficient Algorithm Complexity (CWE-407) weakness can be used to continuously send requests to HAProxy which can cause the watchdog to terminate the process, leading to denial of service to networks running HAProxy.

Affected versions and remediation

HAProxy Technologies has released new versions of affected products which fix the issue by privately forking a more efficient method into the mjson library. The issue has also been flagged to the maintainer of the mjson library.

There is no configuration-based remediation, as this issue can appear in any application-specific areas that have JSON requests enabled, aside from removing the rules involving these converters. The only solution is to update to a fixed version.

Upgrade instructions

Users of affected products should upgrade immediately by pulling the latest image version for their respective release track. Instructions for each impacted product are linked below (customer login required):

• Upgrade HAProxy Enterprise

• Upgrade HAProxy Enterprise with HAProxy Fusion

• Upgrade HAProxy ALOHA

• Upgrade HAProxy Enteprise Kubernetes Ingress Controller

• Upgrade HAProxy Kubernetes Ingress Controller (community version)

Support

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

Though it wasn’t our first time attending Black Hat USA (we’re no strangers to the neon lights and desert heat), our anticipation was high when we landed at LAS. We couldn’t wait to get to the show, connect with security professionals, learn more about where the industry is headed, and put our own solutions to the test.

And this year’s conference didn’t disappoint.

Inside the Mandalay Bay Resort, the show floor mirrored the Las Vegas Strip: packed with towering booths, vibrant designs, and lights illuminating every corner of the conference hall. Every aisle was brimming with energy, lively conversations, and the latest in security tech.

Here are the key takeaways from the event.

All about model context protocol (MCP) and agentic workflows

The main question attendees had wondered was, “How can we integrate these technologies without opening new vulnerabilities?” This year, the conversation shifted, narrowing in focus to two concepts: model context protocol (MCP) and agentic workflows.

The model context protocol is a standardized communication layer that connects AI applications with databases, tools, and templates, enabling faster, more contextual responses. As a universal, open standard, MCP reduces fragmentation and streamlines integration between LLMs and services. MCP allows AI models and agents to share context, enabling agentic workflows wherein multiple AI agents autonomously perform tasks on behalf of a user or a system.

So, how do you manage and secure these complex, multi-agent systems? This is where HAProxy One comes in, operating as an MCP gateway that acts as the network edge for managing AI traffic for MCP servers.

HAProxy is already familiar with MCP. In our HAProxyConf 2025 panel, “Navigating rapid change in IT: Trends and transformations,” we explored how the adoption of MCP is impacting modern infrastructure. The general sentiment was that while MCP traffic is relatively new, the core infrastructure requirements remain largely unchanged. In other words, many of the capabilities that keep traditional APIs fast, resilient, and secure—such as rate limiting and authentication—are still key components for MCP traffic management.

This means that the foundational load balancing and security principles that HAProxy One embodies still apply to MCP traffic and agentic workflows. Acting as a defensive bulwark in front of your AI infrastructure, HAProxy One provides observability, authorization, and A/B testing; prevents requests from overwhelming MCP servers; and facilitates rapid response delivery—while providing your entire infrastructure with next-gen security features.

The fundamentals still matter

Even as technology evolves, the basic requirements for app delivery remain the same—including scalable and reliable security. Our conversations with attendees always circled back to the fundamental layers, such as web application firewall (WAF), bot management, and DDoS protection.

From defending against the OWASP Top 10, to stopping malicious bots and unwanted crawlers, these tools offer frontline protection against malicious threats. And while some vendors offer solutions to these problems, HAProxy Technologies stands out from the rest with its authoritative approach:

• Authoritative across the data plane, control plane, and global edge network.  HAProxy One combines a flexible data plane (HAProxy Enterprise or HAProxy ALOHA), a scalable control plane (HAProxy Fusion), and a secure edge network (HAProxy Edge). Together, these components enable multi-cloud load balancing as a service (LBaaS), web app and API protection, API/AI gateways, Kubernetes networking, application delivery network (ADN), and end-to-end observability.

• Unified multi-layered security and modern app delivery. HAProxy One consolidates application delivery, traffic management, and advanced security layers into one powerful solution. Simplify complex infrastructure, reduce costs, and enforce consistent protection and observability for every application at the edge.

• Ultra-low latency. Threat detection happens in microseconds, ensuring security policies are enforced near-instantly while keeping your application fast and responsive.

• Industry-leading WAF accuracy—without compromise. HAProxy Enterprise WAF achieves a 99.61% true-positive rate, 97.45% true-negative rate, and 98.48% balanced accuracy—virtually eliminating false positives and false negatives.

• Powered by threat intelligence, enhanced by machine learning. Our data science team uses the threat intelligence data provided by HAProxy Edge to train our security models with machine learning, resulting in extremely accurate and efficient detection algorithms for bots and other threats—without relying on static lists and regex-based attack signatures. We use these algorithms to power the security layers in HAProxy One—without sending customer data or live traffic offsite—so you get highly accurate detection with zero privacy concerns.

At the center of HAProxy One is HAProxy Fusion, the unified control plane that gives teams a single, clear view of traffic patterns, security threats, load balancer performance, and server health. With the new Security Control Plane (coming soon), HAProxy Fusion orchestrates HAProxy Enterprise’s multi-layered security capabilities, including the HAProxy Enterprise Bot Management Module, HAProxy Enterprise WAF, CAPTCHA Module, and flexible building blocks such as the Global Profiling Engine (GPE), ACLs, allow-lists and deny-lists, and GeoIP. 

• Centralized security policy provides consistent full-spectrum protection across a distributed edge.

• Security profiles make it simple to deploy security policies to clusters of HAProxy Enterprise nodes.

• Threat-response matrix is an intuitive visual policy builder that enables administrators to combine signals and responses, leveraging all of HAProxy Enterprise’s multi-layered security capabilities.

And, just like with MCP and agentic workflows, the lesson is the same: the fundamentals still matter. Whether you’re protecting against a distributed denial-of-service attack (DDoS) or blocking malicious bots, HAProxy’s 20-plus-year history of performance, reliability, and flexibility ensures your applications stay fast and highly available, even as your infrastructure evolves.

Beyond security: memorable connections and HAProxy goodies

Those who said “hello” took away HAProxy T-shirts, hats, frisbees, and Loady elephant plushies, ensuring attendees’ suitcases were packed even tighter on the way out of Las Vegas than on the way in. If you missed us at Black Hat, don’t worry—you can pick up some swag at one of our upcoming events.

Want to win a $100 Amazon gift card with your new HAProxy swag? Enter our contest for a chance to win—more details here.

CVE-2025-53770 affects on-premises Microsoft SharePoint Servers, allowing unauthorized attackers to execute code over a network. CVE-2025-53771 affects Microsoft Office SharePoint, allowing authorized attackers to perform spoofing over a network. Microsoft has released emergency patches for the vulnerabilities.

However, users of HAProxy Enterprise WAF were protected automatically.

About the SharePoint vulnerabilities

On July 20, The Washington Posted reported that “unknown attackers exploited a ‘significant vulnerability’ in Microsoft’s SharePoint collaboration software, hitting targets around the world”.

Hackers exploited a major security flaw in widely used Microsoft server software to launch a global attack on government agencies and businesses in the past few days, breaching U.S. federal and state agencies, universities, energy companies and an Asian telecommunications company, according to state officials and private researchers.

What’s also alarming, researchers said, is that the hackers have gained access to keys that may allow them to regain entry even after a system is patched.

“So pushing out a patch on Monday or Tuesday doesn’t help anybody who’s been compromised in the past 72 hours,” said one researcher, who spoke on the condition of anonymity because a federal investigation is ongoing.

According to Slashdot:

The vulnerabilities allow hackers to steal private digital keys from SharePoint servers without requiring credentials, enabling them to plant malware and access stored files and data. Eye Security, which first identified the attacks on Saturday, found dozens of actively exploited servers and warned that SharePoint's integration with Outlook, Teams, and OneDrive could enable further network compromise. Researcher Silas Cutler at cybersecurity firm Censys estimated more than 10,000 companies with SharePoint servers were at risk, with the largest concentrations in the United States, Netherlands, United Kingdom, and Canada.

Automatic protection with HAProxy Enterprise WAF

Zero-day attacks targeting previously unknown vulnerabilities are notoriously difficult to protect against. Fortunately, customers using HAProxy Enterprise to load-balance SharePoint services were protected automatically against exploits for these vulnerabilities because of the unique way the HAProxy Enterprise WAF works.

Users do not need to apply special configuration or update WAF rules to enable protection. As long as customers use the HAProxy Enterprise WAF and have Enforcement Mode enabled, their SharePoint services are protected. 

The exploits trigger multiple rules in the HAProxy Enterprise WAF, generating a high enough threat score for the WAF to block the requests completely, as shown in the WAF logs available in HAProxy Fusion’s observability suite. HAProxy Fusion Control Plane provides the centralized management, observability, and automation required to manage WAF deployments at scale across multi-cluster and multi-cloud environments.

About the HAProxy Enterprise WAF

How is this automatic protection possible? Short answer: the HAProxy Enterprise WAF is built different.

The incoming NIS2 and DORA regulations in the EU will require affected organizations to use security tools such as a web application firewall (WAF) to protect their assets and infrastructure. A WAF is an essential part of a multi-layered security strategy, and is designed to detect and block malicious requests, such as those exploiting the SharePoint vulnerabilities. However, organizations using a typical WAF would not be able to block this exploit without updating their WAF rules to detect the new attack signature. What’s worse, when this vulnerability was disclosed, there was no existing attack signature.

​​Traditional WAFs have historically relied on static lists and regex-based attack signatures to identify and block malicious traffic. Unfortunately, these measures are only capable of detecting threats for which a signature already exists. This leaves organizations vulnerable to emerging, polymorphic, or previously unseen attacks — commonly called zero-day attacks. 

The next-gen HAProxy Enterprise WAF is powered by our Intelligent WAF Engine. This engine moves beyond the constraints of static signatures by employing a non-signature-based detection system. Its advanced threat detection is powered by threat intelligence data from over 70 billion daily requests on HAProxy Edge, and enhanced by machine learning. Our data science team trains our security models and enables them to reliably detect unfamiliar attacks and anomalous behavior.

This proactive, adaptive protection enables HAProxy Enterprise WAF to identify and block emerging and elusive threats without requiring users to manually create, maintain, or update complex lists of rules. This architectural shift towards a more intelligent and anticipatory security posture offers better protection and improved operational efficiency.

Recently at HAProxyConf 2025, Juraj Ban, Principal Security Architect at Infobip, praised HAProxy Enterprise WAF: “The engine is powerful and fast. We don't have any latency issues any more. We don't have any false positives, and when we set up a new application we don’t need to fine-tune the WAF rules. We don't have complaints from our customers — that is the most important thing!”

HAProxy Technologies was named a Leader in the G2 Summer 2025 Grid® Report for the Web Application Firewall category, with a Satisfaction Score of 94.

Want automatic protection for your applications?

If you’re an HAProxy Enterprise customer, you already have access to HAProxy Enterprise WAF. Follow the instructions to enable the HAProxy Enterprise WAF.

If you’re not yet using HAProxy Enterprise, request a free trial to experience:

• Advanced multi-layered security

• Unrivalled observability

• Powerful suite of add-ons

• Authoritative expert support

• Infrastructure efficiency and cost saving

The trial includes all features of the full HAProxy Enterprise license with no performance limitations. Our experts will guide you through the trial process, with the option to easily upgrade to the full license with no traffic interruptions at the end of the trial period.

And if you want to learn more about our security solutions in-person, you can visit us at Booth #6028 at BlackHat USA, August 6-7, in Las Vegas.

Three years later, we joined HAProxy’s global community in San Francisco for HAProxyConf 2025, and we couldn’t be more proud of what we have achieved together. We built upon the foundations laid in 2022, and have gone further, faster, than we ever imagined. HAProxy Fusion is playing a leading role in our customers’ success stories, and along with HAProxy Enterprise is driving real-world innovation in security, cloud-native orchestration, and performance optimization at scale.

Taking these success stories and the latest announcements from HAProxy Technologies all together, we see a concept we’ve pursued internally made real. We call it the modern security platform. There’s a lot to unpack, so let’s get into it.

HAProxyConf is a unique event sponsored by HAProxy Technologies, bringing together HAProxy’s global community of open source users and developers, our customers and partners, and our enterprise engineers and leadership team. Presentations include real-world use cases from customers, announcements from our product teams, and technical deep-dives from HAProxy experts. The event also features workshops and plenty of networking opportunities.

HAProxyConf 2025 took place June 4-5 in the Mission Bay Conference Center in San Francisco, with pre-conference workshops at the nearby Luma Hotel. The event attracted hundreds of attendees, with the sold-out workshops proving a particular draw as HAProxy’s experts helped eager fans go from novice to expert.

People came from all over the world to learn, connect, share their stories, and cross lightsabers with our duelling Loady. The food, the custom T-shirt press, and the ever-popular Loady plushies kept the smiles and good times flowing throughout the two-day event.

HAProxy has always prioritized performance, reliability, and flexibility. HAProxy Enterprise adds advanced multi-layered security, administration, and unparalleled customer support. But we knew we wanted to give our customers even more.

When we launched HAProxy Fusion in 2022, we explained that our vision was to make HAProxy even more simple, scalable, and secure — leading to a unified application delivery and security platform that we call HAProxy One. HAProxy Fusion’s part in this vision is to provide centralized management, observability, and automation for multi-cluster, multi-cloud, and multi-team HAProxy Enterprise deployments. HAProxyConf 2025 was the perfect occasion to check in on our progress and reveal the next stage of our vision.

Some catching up

Before we get into what’s new in 2025, it’s important to note some developments in the intervening years.

• First, in May 2024, we launched HAProxy Enterprise 2.9 that included the new HAProxy Enterprise WAF and HAProxy Enterprise Bot Management Module. This release brought next-gen security performance to the HAProxy One platform, with exceptional accuracy, ultra-low latency, and effective out-of-the-box protection.

• Second, we saw the Kubernetes landscape evolve with the shift from the Ingress API to the newer Gateway API, alongside rapid customer adoption of service discovery in HAProxy Fusion to automate Kubernetes application routing. Both trends highlighted the need for modern, flexible approaches to Kubernetes networking, and the spread of user preferences across Kubernetes-native methods and HAProxy-native methods.

• Third, OpenSSL 3.0+ significantly degraded the performance of multi-threaded applications (such as HAProxy) compared with previous versions. This prompted the HAProxy core development team to evaluate alternative SSL libraries for integration with HAProxy.

Our goals

So, we went into HAProxyConf 2025 with a few product goals:

1. Fulfil the promise of HAProxy Fusion with advanced security that just works — in the simplest way possible

2. Modernize our solution for Kubernetes application routing for both open source and enterprise users, providing Kubernetes-native and HAProxy-native methods.

3. Maintain and extend HAProxy’s legendary performance in HTTPS traffic management, using the most advanced SSL libraries available.

These goals coalesce in a singular concept we’ve been pursuing internally, that we call the modern security platform: capable of stopping complex, unpredictable, novel, and expensive attacks; adaptable to any context including multi-app, multi-environment, and multi-form-factor deployment; delivering cost-efficient performance and efficiency; and accessible to IT/DevOps generalists (not just the security experts!).

Did we deliver on these ambitions? Let’s recap the main announcements from our product and engineering teams at HAProxyConf 2025.

From next-gen security performance to next-gen security UX

In a keynote presentation by Andjelko Iharos, VP of Architecture, and Baptiste Assmann, Director of Product, HAProxy Technologies revealed the future of secure application delivery. This involves enhancements to both the data plane (HAProxy Enterprise) and the control plane (HAProxy Fusion), working together in harmony to make advanced security simple and accessible.

• Exceptional accuracy is achieved by leveraging the company’s deep expertise in security, data science, and machine learning, and our authority on the data plane.

• Dynamic adaptability takes into account real-time traffic data to identify anomalies and adapt to each application automatically.

• Performance efficiency minimizes memory and CPU usage while ensuring ultra-low latency.

HAProxy Fusion's new Security Control Plane enables orchestration of the multi-layered security capabilities in HAProxy Enterprise.

• Centralized security policy provides consistent full-spectrum protection across a distributed edge.

• Security Profiles make it simple to deploy security policies to clusters of HAProxy Enterprise nodes.

• Threat-Response Matrix is an intuitive visual policy builder that enables administrators to combine signals and responses, leveraging all of HAProxy Enterprise’s multi-layered security capabilities.

In a presentation covering our Kubernetes solution, HAProxy Technologies engineers Zlatko Bratkovic, Hélène Durand, and Dario Tranchitella unveiled the HAProxy Unified Kubernetes Gateway, which will unify Ingress and Gateway API-based traffic management in a single component.

From OpenSSL to aws-lc

In a presentation covering the evolution of SSL/TLS support in HAProxy, William Lallemand announced that HAProxy and HAProxy Enterprise will now include a modern SSL library from AWS (aws-lc), which provides the highest available SSL/TLS performance with HAProxy’s multi-threaded architecture, and important features for modern application delivery, such as full support for the QUIC transport layer. Lallemand also announced support for the ACME protocol (introduced in HAProxy 3.2), which enables SSL/TLS automation with certificate authorities such as Let's Encrypt and ZeroSSL.

Taken together, these announcements show how HAProxy Fusion is evolving to fulfil its initial promise of a simpler, more scalable, and more secure approach to HAProxy, and that the HAProxy One platform is increasingly well positioned to meet the needs of secure, cloud-native, and performance-critical use cases.

This progress takes the concept of the modern security platform from idea to tangible reality.

• It just works

• It adapts to you

• It’s incredibly cost-efficient

Well done, team!

What were people talking about?

As always at HAProxyConf, our own product and engineering leaders are joined by speakers from the world’s leading platforms and cloud providers, who present their real-world use cases with HAProxy One or the community version of HAProxy.

This year, the standout themes were security, cloud-native orchestration, and performance optimization in complex, large-scale environments, with notable success stories enabled by HAProxy Fusion.

Next-gen security performance

Roblox and Infobip’s presentations showed the next-gen security performance that’s only possible with HAProxy Enterprise WAF.

Ben Meidell, Sr. Site Reliability Engineer at Roblox, showed how the immersive gaming and creation platform uses hundreds of HAProxy instances to manage and secure millions of requests per second. Commenting on the performance impact of HAProxy Enterprise WAF, Meidell said, “One of the big points about scaling up a web application firewall is the potential impact. We have been extremely impressed with the performance of HAProxy Enterprise WAF. When we first activated it, CPU increase was so negligible that I wondered if I’d made a mistake somewhere. But then I saw all the violations it was catching and realized just how effective it was.”

Cloud-native orchestration

Several presentations showed how customers use HAProxy One to simplify management and observability in complex cloud-native scenarios such as a cloud mesh and service mesh, large-scale dynamic Kubernetes backends, and load balancing as a service (LBaaS).

From PayPal, Sidd Mukkamala, Sr. MTS, Network Engineering, and Kalai Manoharan, MTS 2 Network Engineering, introduced Project Meridian powered by HAProxy One, which established a cloud mesh for applications running in multiple public clouds — without requiring external Internet routing for inter-app communication. “We have a presence in GCP, Azure, and AWS,” said Mukkamala. “Our business units are spread across all three cloud providers. This hybrid multi-cloud infrastructure provides global reach and resiliency, but it introduces a layer of complexity. … Our hybrid multi-cloud connectivity fabric provides a simple and unified solution for the business units to talk between themselves.”

Manoharan added: “The Meridian Orchestrator uses HAProxy Fusion as a core component, which helps to manage all these [HAProxy Enterprise] clusters to onboard new frontends or onboard new services, and update Map files. All the operational observability is taken care of by HAProxy Fusion. A great advantage with the HAProxy Fusion Control Plane is all these logs can be looked at as a single plane of glass.” The result was a 24% latency reduction on application calls compared with the public CDN path.

Dartmouth College, an Ivy League research university established in 1769, uses HAProxy One to enable load balancing as a service (LBaaS), which provides the various schools and departments the means to create and deploy their own load balancers on-demand. Curt Barthel, Infrastructure Engineer, said in his presentation: “One of the highlights is the separation of the control plane and data plane with an API-first model. Kubernetes service discovery is important for us as well.”

Clover uses HAProxy One to go beyond blue-green deployment and embrace “rainbow deployment” with service mesh for more flexibility and control. HAProxy provides weight-based routing, enabling developers to gradually shift traffic from older to newer application releases. Anirudh Ramesh, Senior SRE, and Dilpreet Singh, Senior Cloud Engineer, commented: “So why did we choose HAProxy Fusion Control Plane for this? It supports multi-cluster management for not just north-to-south traffic, but also for east-to-west. It gives us real-time configuration updates. It has a REST API interface. It also provides console integration for dynamic backend server pools. And Kubernetes integration, because we use Kubernetes for our microservices.”

Criteo’s Basha Mougamadou, Site Reliability Engineer, showed how to use one of HAProxy’s newest features — automatic CPU binding — to optimize performance in large multi-core systems. “Our aim is to always get the best of the system resources,” said Mougamadou. “Therefore, we started to test a recent feature introduced in HAProxy 3.2 to control CPU policy in an automatic way. If we look at the context switching, we observed a 20% gain!”

But wait, isn’t all this just “conference vibes”? Do people really love HAProxy that much?

A few years ago (back in 2022, coincidentally) we started tracking what people say about HAProxy in user reviews on G2. It’s a great way to identify our strengths and the areas where we can improve. Back in 2022, HAProxy featured in only nine G2 Grid® Reports; but that was then, and this is now.

Last month, in the G2 Summer 2025 Grid® Reports, HAProxy featured in 68 reports and was named a Leader in seven categories: Load Balancing, DDoS Protection, Web Application Firewall (WAF), Web Security, API Management, Container Networking, and DevOps. Many recent user reviews mention HAProxy Fusion and the incredible value it adds — which makes our product team (quietly) happy. Read the summary here.

It’s an astonishing display of growth and momentum for our products and community — one that sums up the journey HAProxy Technologies has taken in the previous three years, since that last HAProxyConf in Paris in 2022.

Takeaways

So what are our takeaways (apart from some wonderful Loady toys for the kids)? What can we learn about the current state of HAProxy and how you can benefit?

What’s next?

We barely had time to catch our breath before jumping into API Days Munich, July 2-3, and then we’re off to BlackHat USA, August 2-5. Be sure to visit our booth if you’ll be in Las Vegas.

We will publish the recorded sessions from HAProxyConf 2025 on our website soon. If you couldn’t make it to this event, the session recordings are the next-best thing.

If you want to get your hands on the new Threat Detection Engine and Security Control Plane, look out for HAProxy Enterprise 3.2 and HAProxy Fusion 1.4 coming later this year. We can’t wait for your feedback and impressions.

And after that? Well, we’ll continue working on bringing our vision to life — which means:

• Providing a unified application delivery and security platform consisting of a flexible data plane, scalable control plane, and secure edge network

• Helping you to simplify, scale, and secure modern applications, APIs, and AI services in any environment

• Never compromising on the fundamentals:

  • engineering excellence that prioritizes performance and reliability

  • “unparalleled” support — to use our customer’s words

  • open-source community and culture

If you want to keep up with what’s happening, subscribe to our blog, join our regular webinars, or ask us for a demo of what HAProxy can do for you.