New to HAProxy Enterprise?

HAProxy Enterprise provides high-performance load balancing, can serve as an API gateway, and provides Kubernetes routing and ingress, TLS offloading, 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.

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

What’s new?

HAProxy Enterprise 3.0 includes new enterprise features plus all the features from the community version of HAProxy 3.0. For the full list of features, read the release notes for HAProxy Enterprise 3.0.

HAProxy Enterprise 3.0 support will be available soon in the upcoming HAProxy Fusion 1.3.2 release.

New in HAProxy Enterprise 3.0 are the following important features:

• Strengthened HAProxy Enterprise WAF robustness and security precision. The next-generation HAProxy Enterprise WAF powered by our Intelligent WAF Engine is now even better at detecting disguised threats with new features such as base64 decoding and the ability to process requests without Content-Type.

• A more dynamic and performant Global Profiling Engine. The Global Profiling Engine has been upgraded with dynamic peer support, enabling load balancers to connect to it without explicitly being added to the GPE configuration file. The ability to learn peers dynamically results in a lower memory footprint due to peer and session reuse.

• Improved HTTPS performance and reliability. We’ve improved HTTPS performance as a result of redistributing and defaulting to OpenSSL 1.1.1.

• New logging capabilities and simplified configuration with the HAProxy Enterprise UDP Module. The HAProxy Enterprise UDP Module now provides logging capabilities for enhanced observability, along with simplified configuration with support for the default-server directive.

• A new CAPTCHA module. The new CAPTCHA module supports more providers and enables simpler configuration management. The supported modes include reCAPTCHA v2, reCAPTCHA v3, reCAPTCHA Enterprise, hCaptcha, Friendly Captcha (frCaptcha), and Turnstile.

• A new SAML module. The new SAML single sign-on module is now embedded in HAProxy Enterprise as a native module and is easier to configure.

We announced the release of HAProxy 3.0 in May 2024, which included improved simplicity, reliability, security, and flexibility. The features from HAProxy 3.0 are now available in HAProxy Enterprise 3.0.

Some of these biggest community features include:

• crt-store feature. Separates certificate storage from frontend use, simplifying and scaling SSL/TLS certificate management.

• Enhanced HTTP/2 stack. Adds the option to limit and track glitchy HTTP/2 connections. HAProxy’s ability to handle the HTTP/2 CONTINUATION Flood demonstrates its resilience with this type of connection.

• Persistent stats after reloads. Stats are preserved using the Runtime API command dump stats-file and the stats-file directive, provided proxy objects have assigned GUIDs.

• Machine-readable logs. Supports JSON and CBOR formats for easier log management and system interoperability.

• Improved stick table performance. Lock contention reduced by sharing data across smaller, individual tables with separate locks.

• Differentiated Services field support. Allows classification and traffic prioritization by setting the DS field on both frontend and backend connections via set-fc-tos and set-bc-tos actions.

• Virtual ACL and map files. Enables in-memory ACL and map file representations using the virt@ prefix, avoiding filesystem searches.

We outline every community feature in detail in, “Reviewing Every New Feature in HAProxy 3.0”.

Ready to upgrade?

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

In the last release, we introduced the next-generation HAProxy Enterprise WAF, powered by the Intelligent WAF Engine. This unique engine delivers exceptional accuracy, zero-day threat detection, ultra-low latency, and simple management. Now, in HAProxy Enterprise 3.0, we’ve further enhanced its robustness and security precision.

With the addition of new features, the Intelligent WAF Engine is even more capable of detecting obfuscated threats. These updates strengthen the already powerful HAProxy Enterprise WAF, providing enhanced security against sophisticated attacks and improved accuracy in identifying disguised attacks.

We’ve previously discussed the incredible accuracy of the HAProxy Enterprise WAF, which achieved a true-positive rate of 99.61%, comfortably beating the category average. With the release of HAProxy Enterprise 3.0, the true-positive rate has climbed to 99.84%, tested using open source WAF benchmark data. False-negatives that were already virtually eliminated are now approaching zero.

Additionally, the HAProxy Enterprise WAF continues to deliver a robust true-negative rate of 97.124%, resulting in a balanced accuracy of 98.48%. With the false-positive rate remaining low at 2.876%, these metrics underscore the consistent and reliable performance of the HAProxy Enterprise WAF.

What’s new in the HAProxy Enterprise WAF?

The new capabilities of the HAProxy Enterprise WAF include:

• Support for base64 decoding to better identify threats that use base64 encoding to obfuscate malicious payloads.

• The ability to parse requests without a Content-Type to inspect malformed requests and minimize false positives.

• Support for atomic ruleset updates through the Runtime API, eliminating the need for external tools and reducing complexity and the likelihood of error-prone updates.

• Prometheus exporter metrics that make monitoring more efficient, including the total number of HTTP requests processed and blocked by an HAProxy Enterprise WAF instance.

With HAProxy Enterprise 3.0, the HAProxy Enterprise WAF delivers superior detection of deceptive threats and reliability, surpassing other vendor solutions that struggle with complex, evasive attacks.

For organizations seeking a solid web application firewall, HAProxy Enterprise WAF offers a robust defense that enhances your infrastructure’s security.

The Global Profiling Engine helps customers maintain a unified view of client activity across an HAProxy Enterprise cluster. By collecting and analyzing stick table data from all nodes, the Global Profiling Engine offers real-time insight into current and historical client behavior. This data is then shared across the load balancers, enabling informed decision-making such as rate limiting to manage traffic effectively.

In HAProxy Enterprise 3.0, we upgraded the Global Profiling Engine, which now offers dynamic peer support and a much lower memory footprint. This upgrade brings enhanced scalability and improved performance to clients.

What is dynamic peer support in the Global Profiling Engine?

With dynamic peers, load balancers can now connect to the Global Profiling Engine without explicitly being added to the configuration. This means that when new nodes are added or removed from a cluster, they can seamlessly connect or disconnect to the Global Profiling Engine, with all data and configuration automatically shared between them.

Dynamic peer support ensures that each node in a cluster can instantly synchronize data about client behavior and traffic patterns, without the need for administrators to manually configure and manage peer support. This makes it easier to enforce rate limiting policies at a global level and enables customers to make real-time, informed decisions as their system scales, offering cluster-wide data tracking and aggregation—now more dynamic and efficient than ever.

Dynamic peer support also brings customers better memory management due to peer reuse and session reuse. Using the same resources multiple times minimizes memory allocation, resulting in a much lower memory footprint.

Ultimately, the upgraded Global Profiling Engine is a more resource-efficient and scalable solution—and we hope customers take advantage of its dynamic capabilities.

Enhanced TLS performance with OpenSSL optimization

HAProxy Enterprise allows customers to encrypt traffic between the load balancer, clients, and backend servers using TLS.

With the release of HAProxy Enterprise 3.0, TLS performance has been optimized by switching from OpenSSL 3.X to OpenSSL 1.1.1 as the default for relevant operating systems. While this may be a notable change for some customers, the OpenSSL optimization will ultimately bring better performance and reliability for their systems.

Customers love the HAProxy Enterprise UDP Module because it delivers fast, reliable UDP proxying and load balancing. By unifying UDP, TCP, and HTTP load balancing under a single solution, HAProxy Enterprise simplifies infrastructure management and eliminates the need for multiple products from other vendors.

Now with the release of HAProxy Enterprise 3.0, there’s more to love about the UDP module. When load balancing UDP traffic, customers now have access to logging capabilities for enhanced observability, along with support for the default-server directive, making configuration easier than before.

Basic logging can be enabled by specifying the log keyword and its arguments in the udp-lb section. Currently, the log output format contains the source and destination addresses, bytes received and sent, the instance name, and the server—and we plan to expand capabilities further in the future.

To learn more about configuring logging for UDP load balancing, visit our documentation.

Previously, configuring UDP load balancing in HAProxy Enterprise required manually specifying each server, which required more time and effort, especially when managing a large number of servers. But now, with the default-server directive, customers can specify these settings once and apply them uniformly across multiple servers. The end result is a more streamlined and simpler configuration process. 

Our documentation outlines how to take advantage of this new directive to improve your workflow.

This enhancement, along with logging capabilities, further strengthens the HAProxy Enterprise UDP Module, which already delivers best-in-class UDP performance compared to other software load balancers. With these updates, customers gain not only a highly performant and scalable UDP proxying and load balancing solution but also one that offers enhanced observability and simplified configuration management.

New CAPTCHA and SAML modules

HAProxy Enterprise 3.0 brings two new native modules to customers:

• The CAPTCHA Module

• The SAML Module

Both of these modules, while having different functions, simplify HAProxy Enterprise configuration for customers.

New CAPTCHA Module

This release introduces a new CAPTCHA module that simplifies configuration while extending support to more CAPTCHA providers, including Google reCAPTCHA Enterprise, the biggest one.

Some of the supported modes include:

• reCAPTCHA v2

• reCAPTCHA v3

• reCAPTCHA Enterprise

• hCaptcha

• Friendly Captcha (frCaptcha)

• Turnstile

Similar to the previous implementation, the new CAPTCHA module presents a challenge page to clients to determine if the user is a human. The only difference this time is that the new CAPTCHA module is now embedded in HAProxy Enterprise as a native module. This results in a module that supports more CAPTCHA providers beyond Google reCAPTCHA, can easily integrate with other providers not listed above, and is much simpler to configure.

The previous reCAPTCHA module required customers to configure the module through an extra configuration file and to add more to hapee-lb.cfg. With the new CAPTCHA module, a new section is added to the hapee-lb.cfg where all the settings go—a much simpler, streamlined process to verify that clients are humans.

In HAProxy Enterprise 3.0, implementing a CAPTCHA solution is simpler than ever, making it easier to integrate CAPTCHA verification into your HAProxy Enterprise setup without compromising security.

New SAML Module

This release also includes a new Security Assertion Markup Language (SAML) module, which provides single sign-on to any web application behind HAProxy Enterprise.

Previously, SAML was supported through an SPOE Agent, but with HAProxy Enterprise 3.0, the SAML module is now running in HAProxy Enterprise, greatly simplifying configuration. With the new SAML module, customers no longer have to configure the module in a separate SPOA configuration and can instead merge the configuration into hapee-lb.cfg.

Upgrade to HAProxy Enterprise 3.0

When you are ready to upgrade to HAProxy Enterprise 3.0, follow the link below.

Try HAProxy Enterprise 3.0

The world’s leading companies and cloud providers trust HAProxy Technologies to protect their applications and APIs. High-performing teams delivering mission-critical applications and APIs need the most secure, reliable, and efficient application delivery engine available. HAProxy Enterprise’s no-compromise approach to secure application delivery empowers organizations to deliver next-level enterprise scale and innovation.

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

Our own measurements, collected by HAProxy Edge and filtered to traffic for haproxy.com, show a few interesting figures:

• Nearly 1% of our total traffic comes from AI crawlers

• Close to 90% of that traffic is from Bytespider, by Bytedance (the parent company of TikTok)

What does AI traffic mean for us – and you?

While we are primarily a technology company, we also consider ourselves to be a content company; we invest in original, human-authored content — such as documentation or blogs that provide helpful information to our users and wider audience.

Content-scraping bots existed long before LLMs started crawling the web for generative AI applications, and they have usually been considered undesirable visitors on content-heavy websites. Many businesses would not consent to the scraping and possible re-use of their content, in full or in part, by a third party. 

However, AI crawlers used by LLMs come with unique risks and opportunities.

1. On one hand, an LLM might re-use the original content in full, or with some modification, or remixed with other content at the level of an LLM token (roughly the level of a single word). It is unlikely that a user will know where the original content came from. In cases where an LLM “hallucinates”, a user might receive inaccurate information, for example when requesting code or configuration instructions.

2. On the other hand, with many users turning to AI chatbots as an alternative to traditional search engines, this is becoming an important channel for discovery and awareness. Businesses might want their brand or product information to be supplied by chatbots in response to user queries. For example, if a user asks for a list of relevant products, a business might want their product to be included in the list, along with features and benefits.

While we don’t limit AI crawlers on our website right now, we will have to make a decision whether to continue to allow them or not. Other businesses running content-heavy public websites will likely find themselves having to make the same decision: to protect the value of their content, or to allow the dissemination of information about their brand and products via these new channels.

What can you do to protect your content from AI crawlers?

If bots and the risk of content replication pose a threat to your business, you need a strategy to mitigate this risk and a technology solution that enables you to implement it.

A common method of disallowing bots is to use the robots.txt file on your website domain. However, some AI crawlers (including Bytespider) don’t identify themselves transparently; they try to pretend to be real users and ignore instructions in robots.txt. It is for this reason that we — like the Fortune.com article — describe the crawling as “aggressive”. It is not only a matter of scale but also the way it is being done. 

Therefore, any technical solution for managing AI crawlers and scrapers must be capable of accurately identifying such bots, even when they are designed to be hard to distinguish from humans.

HAProxy Enterprise customers already benefit from the HAProxy Enterprise Bot Management Module, announced in version 2.9. This technology combines a simple and efficient method for identifying and classifying bots with HAProxy’s legendary flexibility, to support a range of bot management strategies — such as blocking, rate limiting, or challenging via CAPTCHA. 

Our guide, How to Reliably Block AI Crawlers Using HAProxy Enterprise, shows you how to identify and block these bots (either individually or as a category) using a few lines of configuration on HAProxy Enterprise. Other providers, such as our friends at Cloudflare, recently provided a similar solution.

Where does our data come from, and how do we use it to improve bot management?

Our traffic statistics from HAProxy Edge show that the scale of AI crawler traffic is significant and growing fast. Let’s talk about where our data comes from and how we use it.

HAProxy Edge provides a globally distributed application delivery network (ADN) that provides fully managed application services, accelerated content delivery, and a secure partition between external traffic and your network.

By analyzing the traffic connecting to websites and applications hosted on HAProxy Edge (which includes haproxy.com), we can build a picture of global traffic trends. We can also filter these traffic metrics to show AI crawlers. Our bot management technology performs rapid identification and classification of bots (and humans), including identification of known AI crawlers such as:

• Bytespider (TikTok)

• OpenAI search bot and ChatGPT variants

• PerplexityBot

• Google AI crawler

• ClaudeBot

• Others

Our data science team uses the threat intelligence data provided by HAProxy Edge to train our security models with the use of 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 Edge itself and HAProxy Enterprise and HAProxy Fusion. This includes the HAProxy Enterprise WAF (powered by the Intelligent WAF Engine) and the HAProxy Enterprise Bot Management Module.

For businesses looking for fully managed application services, HAProxy Edge provides bot management and other security features, backed by HAProxy Technologies’ authority on all aspects of the load balancing and traffic control stack. Contact us if you’d like a demo or a trial.

New to HAProxy Fusion?

HAProxy Fusion provides full-lifecycle management, monitoring, and automation of multi-cluster, multi-cloud, and multi-team HAProxy Enterprise deployments. HAProxy Fusion combines a high-performance control plane with a modern GUI and API (with 100% coverage), enterprise administration, a comprehensive observability suite, and infrastructure integrations including AWS, Kubernetes, Consul, and Prometheus. HAProxy Fusion and HAProxy Enterprise benefit from 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.

What's new?

HAProxy Fusion 1.3 is packed with major quality-of-life improvements. For the complete list of features, please view the HAProxy Fusion 1.3 release notes (customer login required). Key additions include:

• A new, customizable Security dashboard complete with bot management and WAF monitoring statistics

• An enhanced Access Logs dashboard with support for creating custom views into all your observability data

• More powerful service discovery integration with Kubernetes and Consul, including support for filtering based on labels (AKA "tags") for services and namespaces

• Improved configuration management, including a new fast backends feature for near-instant configuration generation from service discovery registries, with minimal overhead

• A more powerful and searchable Request Explorer interface with added security details

• Line-by-line or by-key .map file editing, letting you make edits with high concurrency of changes

• An upgraded method for sending access logs from HAProxy Enterprise to HAProxy Fusion or your syslog servers

This only scratches the surface of what HAProxy Fusion 1.3 brings to the table. We'll dive into the above features to explain how they make it even easier to use HAProxy Fusion to manage large-scale deployments.

When you're ready to start the upgrade process, please carefully read our HAProxy Fusion upgrade documentation (customer login required). We've also backported multiple features to HAProxy Fusion 1.2, for teams that are unable to upgrade to the new version right away.

HAProxy Enterprise 2.9 constituted a major leap forward for multi-layered security in HAProxy, introducing the new HAProxy Enterprise WAF and HAProxy Enterprise Bot Management Module. Now, HAProxy Fusion 1.3 upgrades the monitoring capabilities for these layers to truly empower teams with the data needed for threat response. It also boosts transparency into how HAProxy Enterprise clusters operate. 

HAProxy Fusion 1.3 adds a customizable Security dashboard to the Dashboards picker under "Overview." You can now view a variety of contextual information for HAProxy Enterprise WAF and HAProxy Enterprise Bot Management Module, neatly organized by pane. You can drap, drop, resize, and remove these individual dashboard sections according to your preferences. That includes creating a unified view for both security layers (example shown below), or a focused view centered solely on the metrics you care about:

New Access Logs dashboard brings customization and granularity

Active HAProxy Enterprise nodes track numerous performance metrics such as total requests, average requests, bandwidth in and out, and others. As its name suggests, the new Access Logs dashboard in HAProxy Fusion 1.3 can draw from your access logs—viewable in Request Explorer—to display much broader data than before. HTTP methods, IP addresses, and GeoIP metrics are just a few examples. 

New tools also make it easier to view the contextual data you care about. Users can choose a date (or date range) by zooming or dragging in the chart—or by using the calendar for historical data. These controls are identical to those present within the Native Statistics dashboard since HAProxy Fusion 1.2.

Finally, these HAProxy Enterprise statistics are now reviewable for longer periods of time. You can preserve basic metrics for months without worrying about storage requirements, as the quantity and complexity of collected stats are relatively low. HAProxy Fusion 1.3 gives you more control over your data.

HAProxy Fusion 1.2 first added service discovery for Kubernetes (K8s) and Consul environments. You can use this to automatically identify backend services (such as Kubernetes pods) and configure external routing and load balancing in your HAProxy Enterprise nodes. 

HAProxy Fusion 1.3 builds on this foundation by bolstering Kubernetes infrastructure integration with new-and-improved service discovery features. You can now do the following in HAProxy Fusion 1.3: 

• Define which K8s services are load balanced using labels on namespaces and services. This makes HAProxy Fusion service-aware within large-scale Kubernetes environments through Kubernetes-native configuration, and only pulls in the services you want.

• Use the new fast backends feature to generate configuration for a very large number of Kubernetes or Consul services, with minimal overhead.

The optional fast backends transformer is an important addition for organizations that host numerous services in Kubernetes and thus scale out frequently. We've revamped the configuration code to reduce human error and slash configuration upload time—based on service discovery information—from minutes to mere seconds. 

Service discovery data can change (and become obsolete) every few seconds, so restoring earlier versions isn't very useful. However, we've maintained a reviewable historical record of previous runs for HAProxy Fusion users.

You'll see this configuration populate in the newly added read-only portion of the editor. It lives alongside other sections delivered to your load balancers and available for use in configuration—such as HAProxy variables populated by HAProxy Fusion or other logging settings. While you can see all portions of your configuration in one unified view, this setup mitigates human error and helps simplify the complex task of managing Kubernetes.

Request Explorer interface displays richer data

Request Explorer has historically enabled users to retroactively view client access logs, and understand the request-response flow within HAProxy Enterprise. While these access logs provided useful request details, we've expanded this feature in HAProxy Fusion 1.3 by adding a dedicated dashboard page to help you review the following (and much more): 

• Top 10 request paths

• Response codes

• GeoIP countries

• Protocols used

Since logs feed data to Request Explorer, it's also possible to search by structured data using the familiar ctrl + f keybinding. We may continue to expand upon this overall feature list in future versions of HAProxy Fusion.

A new Security tab helps you drill down deeper

Request Explorer's expanded view is a great place to centrally inspect a wide range of HAProxy Enterprise cluster operational data, which is why we've expanded it to encompass security data. Teams use HAProxy Fusion to manage multi-layered security features such as HAProxy Enterprise WAF and HAProxy Enterprise Bot Management Module, so we've compiled data from both into a dedicated tab.

Map files gain flexibility with fewer reloads

Many HAProxy Enterprise users use .map files to define key-value pairs, enabling features such as dynamic rate limiting and blue-green deployments. They also support Layer 7 routing and many other creative functions. However, the process of updating those files hasn't been very user-friendly. 

For example, .map files previously allowed for conflicting changes. HAProxy Fusion also required a complete file re-upload to apply miniscule edits. This was resource-intensive and error-prone for customers with massive files.

HAProxy Fusion 1.3 brings some important enhancements to boost .map file usability: 

• Line-by-line and by-key editing are now supported through additional specialized API endpoints.

• Changes to .map files submitted to HAProxy Fusion through the new editing API endpoints are applied to your HAProxy Enterprise nodes dynamically through Runtime API. These changes skip HAProxy reloads, yet your file is still uploaded to the filesystem for persistence. 

• After users edit them, HAProxy Fusion can send multiple independent .map files to your load balancers in one transaction, with built-in error handling and reduced latency while applying multiple .map file changes.

If you want to track the file changes you've made, a new real-time changelog appears in the upper right (pictured above). HAProxy Fusion users can also use the API to make and apply .map file changes.

Conclusion

HAProxy Fusion 1.3 represents a mighty leap forward for HAProxy Fusion. New monitoring dashboards, high-performance service discovery, and .map file editing changes bring numerous usability improvements for HAProxy Fusion users. 

If you want to see HAProxy Fusion 1.3 in action, contact our sales team for a demonstration or watch our introductory webinar.

Standardized logging formats have become essential for teams relying on integration to aggregate logs from heterogeneous technologies and tools within their organizations. HAProxy users can now address this need more effectively using standardized logging formats.

With the release of HAProxy 3.0, we introduced new JSON and CBOR encoding options. Users can now format log lines as JSON or CBOR, making them easier to parse. Furthermore, when formatting log lines as CBOR, users also have the option to specify binary (+bin) to reduce bandwidth.

Additionally, log format expressions were sometimes ambiguous about data type. Now, you can explicitly define data types for log format expression fields to improve consistency between logs.

These updates simplify log management and ensure better interoperability across systems. Furthermore, applications handling these structured logs benefit from enhanced performance, no longer needing to manually extract and format data from default logs.

Why did we add new encoding options to HAProxy?

HAProxy users have long wanted HAProxy logs to be in a standardized format to simplify the extraction of data, improve application performance, and ensure compatibility with existing logging facilities.

While default HAProxy logs are not standardized (often requiring custom parsers to extract relevant information), their design was intentional to accommodate earlier logging practices. In earlier versions of HAProxy, other structured formats such as JSON were not common yet, and HAProxy logs were primarily read directly by administrators with minimal need for parsing. As a result, HAProxy logs were designed to be less verbose and maintain backward compatibility.

However, logging needs have evolved. Users frequently manipulate the log format to make the output compliant with other systems. If users wanted HAProxy logs in a JSON or CBOR format, they had to convert them manually or use middleware to convert HAProxy logs to the desired format.

Furthermore, emitting structured logs with HAProxy was often difficult and problematic:

• Quoting issues. The %{+Q} format often failed to quote string values consistently. For example, some string values (e.g., %tsc) were not quoted while others were. Also, numeric values leveraging sample expressions (e.g., %[expression]) were inconsistently quoted.

• Hexadecimal representation. The %{+X} format, hexadecimal representation for integers, was not consistently applied across different log format aliases

• Inconsistent null values. Null values were represented inconsistently, often as empty strings, sometimes as "-", and other times as -1. This inconsistency required treating everything as a string and manually adding quotes, rather than relying on %{+Q}, to ensure valid encoding (e.g., avoiding invalid encoding in JSON like {"foo":} or {"foo":-}).

• String handling for numerical values. Some numerical values, such as %ms (padded output) or %rc / %B (leading characters), had to be handled as strings (for historical reasons).

HAProxy users had to spend additional effort creating custom parsers and handling log format issues manually. This resulted in increased complexity and inconsistencies in logging when trying to create JSON outputs, making it more difficult to achieve accurate and reliable log outputs.

The new JSON and CBOR encoding options address these issues by providing structured data logging options out-of-the-box.

• JSON (JavaScript Object Notation) is a standard text-based format for storing and transporting data.

• CBOR (Concise Binary Object Representation) is a binary data format often preferred for optimizing network bandwidth. Without specifying binary, CBOR is a hexadecimal format for interoperability purposes and can be more verbose than JSON and HAProxy’s default log format.

Together, these two encoding options give HAProxy users two widely used log formats, enabling better performance and integration with other systems and teams. The new log format encoders in HAProxy 3.0 provide a more standardized approach to logging, eliminating the need for custom parsers, middleware for conversions, and extensive log format adjustments. Users should find their logging setups are easier to maintain.

The advantages of HAProxy 3.0’s new encoding options

With HAProxy 3.0, users no longer require alternative solutions to convert HAProxy logs to JSON or CBOR. This native support simplifies the immense amount of logs generated by modern applications and microservices, making it easier for teams to operationalize and make sense of their data.

While alternatives like Syslog remain a standard, their lack of descriptiveness can make them less suitable for modern logging needs. JSON and CBOR offer more structure and interoperability. Even though these formats can be more verbose, the benefit of multi-team log consistency is a fair trade-off.

Encoding logs in JSON means you don’t need to manually craft a log yourself by “hacking” the log format. This makes logs encoded in JSON less error-prone and more consistent because manual adjustments are minimized. Furthermore, JSON-structured logs are easier to read and parse than default HAProxy logs, ultimately resulting in easier debugging and archiving experiences.

CBOR support in HAProxy 3.0 introduces a method for structuring logging that was previously unattainable through manual adjustments—it was never as simple as “hacking” the log format as it was for JSON. CBOR support improves interoperability with existing tools and products and reduces bandwidth usage by transmitting pure binary payload over the wire, provided the ring/syslog endpoint supports it.

JSON equivalent of "option httplog"

When enabling option httplog, HAProxy implicitly sets the proxy log-format directive to the default  HTTP access log formatted string, which can be accessed through the global environment variable named HAPROXY_HTTP_LOG_FMT.

Setting option httplog is equivalent to setting log-format to ${HAPROXY_HTTP_LOG_FMT} on an HTTP proxy:

To generate JSON structured logs instead, we can create our own log format string based on HAPROXY_HTTP_LOG_FMT:

CBOR (plain text) equivalent of “option httplog”

Let’s do the same thing for CBOR logs.

To generate CBOR (plain text) structured logs, we can create our own log-format string that enables the CBOR encoding option by setting %{+cbor}o:

Conclusion

The addition of JSON and CBOR encoding in HAProxy 3.0 streamlines log management and improves interoperability between systems. With these standardized formats, HAProxy reduces the complexity of log extraction and formatting, making it simpler for teams to maintain consistency across their infrastructure.

The 2+ days event will take place in the Mission Bay Conference Center, where DevOps, networking, and security professionals, open source developers, community enthusiasts, and business leaders come together to discuss all things HAProxy! Presenters will share how they are addressing today's biggest application delivery and security challenges, how to get started or do more with HAProxy, and how they are using HAProxy to solve real-world problems while making a difference in their organizations. 

HAProxy is, first and foremost, a passionate community of open-source developers, who helped HAProxy reach version 3.0—a milestone release—earlier this year. We welcome everyone involved in the HAProxy project to join us and help encourage the next generation to get involved in building the future of HAProxy.

In addition to the main event, workshops will be held at the nearby Luma Hotel on June 3.

Got a great story, lesson, or innovation to share? From multi-layered security to infrastructure automation, and from API / AI gateways to Kubernetes, we want to hear from you! Submit your talk and become a part of HAProxyConf 2025's exciting lineup.

When is the conference?

HAProxyConf 2025 will happen from June 4 to 5, with pre-conference workshops on June 3.

Where will the conference be?

HAProxyConf 2025 will take place in San Francisco, California.

The main conference will be held at the Mission Bay Conference Center, and the workshops will be held at the nearby Luma Hotel.

Check the Call for Papers webpage to get the full details and submit your talk.

Looking for inspiration? Check out previous conference videos!

HAProxy Data Plane API 3.0 is now available! The latest version is hosted on our GitHub releases page.

This release follows the recent HAProxy 3.0 release and incorporates its changes, along with some improvements and changes specific to the API.

HAProxy Data Plane 3.0 adds multiple breaking changes. We'll cover the impacts of these changes in detail to highlight how your implementation and usage of Data Plane API may be affected. Despite some initial growing pains, v3 provides a stronger foundation for future development as we continue to modernize and simplify the API to meet users' needs. We recommend reading carefully through this upcoming section. 

This release also makes key improvements to the API, which we'll also expand upon later: 

• Users can now fetch a parent resource with all children embedded. 

• We've added a PUT operation on index-based resources. 

• Timeouts are now handled with your preferred time suffix. 

• The API's state data is removed from the configuration file. User-defined settings are now the configuration's sole focus. 

• Support has been added for every new keyword introduced in HAProxy 3.0. 

But that only scratches the surface. We're excited to show you the core functionality updates we've made in v3 and why they matter.

Breaking changes

This version introduces breaking changes described in this section.

Removed _version and data wrapper fields in responses

Each time the Data Plane API changes the load balancer configuration it increments the version of the file. This enables optimistic locking of the configuration to prevent a user from unintentionally overwriting another user's changes. In the initial design, each API endpoint returned JSON data with _version and data fields as top keys in the response object. Later, we also added a Configuration-Version HTTP header, making the configuration version available in both the wrapped response and the header. 

In v3, we've removed the redundant _version and data fields from the response and moved the JSON previously under data to the top—making it easier to parse. This simplifies the process of changing an existing resource. Users can leverage this flat structure to fetch the resource, change a few fields, and send back the same object without needing to unpack it from the data field.

Renamed the defaults resource

In the early stages of the Data Plane API, we intended to generate and manage only one defaults section within the HAProxy configuration by using the /v2/services/haproxy/configuration/defaults endpoint. This decision to manage just one was based on the fact that support for assigning defaults sections names—by which you could indicate which to inherit settings from—didn't originally exist. Assigning a name to a defaults section, although valid syntactically, had no functional meaning in HAProxy.

However, HAProxy 2.4 introduced keywords to the frontend and backend sections, giving meaning to these names and allowing users to create multiple, named defaults that frontends and backends could then inherit settings from. Since the defaults resource initially returned an object instead of a list, we introduced a new resource called named_defaults to maintain backward compatibility. This resource returned a list of defaults resources that names and could be referenced in backends and frontends sections. We kept the original defaults resource for backward compatibility as an object.

With v3 of the API, we're migrating named_defaults to simply defaults, breaking the old defaults behavior. The defaults resource now returns a list versus an object.

Moved child resources as nested resources

In v2, some resources represent lines within a section of HAProxy configuration, effectively making them child resources of the parent section resource. For example, the acl resource can be a child of a frontend or backend, and a server resource can be a child of a backend parent. 

You could previously fetch or update these resources in the API by identifying them with their index, which was the case for the acl resource. You could do the same by name for other resources, such as the servers resource. You'd then specify their parents using the parent_type and parent_name query-string parameters.

This process was unfortunately confusing, so we've redesigned child resources as nested resources in the URL. Because a child resource cannot simultaneously exist in multiple parent resources, it makes sense to include this in the parent resource's URL. This also boosts compatibility with many external tools. For example, you can build role-based access control (RBAC) rules more easily atop the new URL hierarchy without relying on query-string parameters.

Here's how the two implementations compare:

• In v2, you'd see /services/haproxy/configuration/acls?parent_type=frontend&parent_name=my-example-frontend

• In v3, you'll instead see /services/haproxy/configuration/frontends/my-example-frontend/acls

Removed explicit index field on index-based child resources

In v2 of the API, all index-based resources—which represent configuration lines that can be repeated within a section and are distinguished by the order of appearance—had an index field indicating the position of that specific resource. For example, acl resources get an index to indicate their order within the configuration.

We've removed that index field in v3, as we found it redundant and complicated to maintain when positions change. You can infer the ordering from the actual position in the returned list.

Removed support for HAProxy in multi-process mode

HAProxy previously had a feature that allowed it to run in multi-process mode. This mode has since been deprecated and removed following the introduction of multi-thread mode. In v2 of the API, we supported all keywords related to multi-process mode. Additionally, we supported multiple runtime APIs (one for each process mode), so all /runtime resources worked with multiple process support.

We've removed this support altogether in v3 alongside the following fields from the respective sections:

• Backend resource: bind_process

• Bind resource: process

• Defaults resource: bind_process

• Frontend resource: bind_process

• Global resource: nbproc

In addition to removing these fields, /runtime endpoints have changed.

The stats resource at /v2/services/haproxy/stats/native used to return an array of arrays. The top-level array held per-process stats, with each array element containing an array of stat lines for each object (server, backend, frontend). Now that multi-process mode support is ending, /v3/services/haproxy/stats/native returns an object with a single stats array for the server, backend, or frontend object you've requested. Similarly, we removed one layer of arrays that returned process information on a per-process basis. This change affected /v2/services/haproxy/runtime/stick_table such that the process field is removed from responses that previously indicated from which process the stick table information was being fetched.

In addition to this, the query string parameter process was removed from both /v2/services/haproxy/runtime/stick_tables and /v2/services/haproxy/runtime/stick_table_entries resources.

Reorganized global resource fields

One thing we set out to do with v3 was reorganize the global resource fields. The global resource is our largest if you measure by the number of fields, and it primarily had a flat structure. To improve readability of this resource on the API, we reorganized the fields into nested objects.

While making this change, we tried to adhere to HAProxy's field naming conventions and followed documentation hints when deciding how best to structure the revised fields. We tried to maintain only one level of nested objects to avoid unnecessary complexity. Some fields remain in the root level of the object, and some options are split into debug_options and performance_options as specified in the Configuration Manual.

We've also added an ssl_options nested object to cover all SSL directives. Other objects like tune_ssl_options, tune_vars_options, and tune_zlib_options are all derived from tune.*.* options. Plus, the tune_options object covers other tuning global directives and acts as a catch-all. Meanwhile, http_client_options and fifty_one_degrees_options are similarly derived from the manual's dot notation.

For the full and detailed specification of fields, please see the global model specification within our GitHub project.

Removed deprecated fields and resources

As a major version release, Data Plane API 3.0 gave us the chance to clean up keywords previously marked as deprecated. Here's more information about the keywords we've removed in v3:

Global section

• Removed the deprecated tune_ssl_default_dh_param field that can now be found in tune_ssl_options as default_dh_param

Backend section

• Removed the deprecated http-check field. You can now specify multiple http_check resources on /v3/services/haproxy/configuration/backends/{parent_name}/http_checks.

• Removed the http-keep-alive, http-server-close, and httpclose fields as they're mutually exclusive and configurable using the http_connection_mode field

HTTP request/response rules and TCP Request Rule resource

• Removed the deprecated track_sc<stick_counter> field. In v2 we only supported 0, 1, and 2 stick counter indexes by hard-coding them in the field names. We've now added the track_sc_stick_counter field (specifying the stick counter index) which can exceed 2 if configured using the tune.stick_counters keyword in the global section. It defaults to 3 and debuted in HAProxy 2.8.

Service discovery resources

• Removed the deprecated service-whitelist and service-blacklist fields, which we've replaced with service_allowlist and service_denylist, respectively

Further API Improvements

Fetching a parent resource with all children embedded

While we've found that our granular approach to creating resources on the API is helpful, we're aware it can also add complexity. As a result, we've added an extra query string parameter full_section on all the section resources such as frontend and backend resources. This lets you fetch, create, or replace a complete section with all of its child resources.

This query string parameter works on both PUT and POST endpoints, so you can now edit or create the whole parent section with just one API call.

Added a PUT operation to index based resources

Previously, change automation on a list of index-based resources was complex for several reasons. First, you had to reconcile all index fields in each resource. This made it difficult to locate a resource if something was deleted and added, as its index could have changed. Second, large lists with multiple changes forced you to make numerous API calls.

With v3, we added a PUT operation to the list endpoints, letting you automatically replace the entire list of resources.

Handle timeout options with preferred units

We handle timeout options as integers in the API, since we want to represent numeric values as numbers wherever possible. However, since HAProxy supports strings by accepting time unit suffixes, we recalculated the submitted values to the default unit in v2 (usually milliseconds) and stored them as integers in the configuration file. This was challenging for those who still use and read the raw configuration file, as it changed their preferred inputs and made the file less readable.

In v3, we've introduced a new option in the Data Plane API configuration file called preffered_time_suffix where you can specify one of the options: nearest, none, ms, s, m, h, and d. Data Plane API will then honor your preferred time suffix, which is nearest by default, and calculate it to the smallest possible value with the corresponding suffix. When using none, your timeout keywords in the configuration file are written without the suffix while using the default value for the respective keyword.

For further info, we've added some documentation to our Open API specification by annotating such fields with x-duration: true and x-default-unit to indicate the standard time unit for that specific field.

Keep Data Plane API config file unchanged

Since Data Plane API lacks its own storage, it previously used its configuration file to store state—notably for service discovery and user configurations. This proved problematic when using Data Plane API with automation software like Ansible, Puppet, and others.

Data Plane API will no longer write to its own configuration file from v3 onward. We've introduced dataplane_storage_dir, where Data Plane API's state will be stored in specific JSON files for each feature. We chose JSON for easier readability and debugging.

Upon startup, state data will automatically migrate from the configuration file into JSON files located at /etc/haproxy/dataplane. For information on where the data goes, view our brief Data Plane API internal storage Readme on GitHub.

Added support for all new keywords added in HAProxy 3.0

Following the latest release of HAProxy, we're extending the configuration keyword support to include many new features in the load balancer. These keywords impact security, persistence, streaming, directives, and more. 

To view and understand the complete collection of keywords now available in HAProxy 3.0, check out our Reviewing Every New Feature in HAProxy 3.0 blog post.

Contributions

As always, we'd like to extend a massive thank you to everyone who helped accelerate Data Plane API's development and make v3 possible: 

Data Plane API 3.0 constitutes a major step forward in functionality and maintainability for Data Plane API. We're excited to bring you even more features and enhancements soon in response to your feedback. 

For more information including installation and upgrade instructions, visit our Data Plane API documentation. You can also view our Data Plane API releases section on GitHub for updated release notes and a changelog.

Imagine you have an employee whose certificate and key were stolen by an adversary. If you are using TLS client authentication, that adversary can connect to your infrastructure and maintain illegal access. And even after you revoke that certificate, that adversary will remain connected until they themselves close that connection. 

For many vendors, the only fix for this is to clear all existing connections and force everyone to re-connect. This is extremely disruptive and can lead to lost revenue since it also kills legitimate connections. 

Luckily, HAProxy Enterprise lets you immediately drop connections and remove the client if their certificate is revoked. Meanwhile, other customers and users aren't affected. Any subsequent attempt to reconnect using that revoked certificate will fail.

Introduction to client authentication

You can use a certificate authority (CA) to generate a client certificate and key. That certificate and key function is like a virtual ID badge—serving as authentication for that client while enabling the server to verify that the client is authorized to access a given resource. 

Since TLS exists at OSI Layer 6, you can use TLS client authentication to secure and authenticate for a variety of applications. One of the most common use cases is securing HTTP traffic. However, you can use TLS authentication to add a layer of security to other protocols, such as SSH. 

The mTLS authentication configuration for either of these protocols can be identical from an HAProxy perspective, which is why we've used a generic example below using a random port. You can use this same configuration with HTTP—just remember to keep the frontend and backend in mode tcp for that configuration, too:

1. This module currently only works with mode tcp and not http mode.

2. If you're sending more than one certificate authority (CA) you MUST have a CRL list for each.

3. If you update the file using the CLI, the global option tune.bufsize needs to be larger than the size of that file (the default is 16Kb).

Understanding the configuration

For those new to the HAProxy Enterprise configuration file, the code sample above might seem complex. Let's break down each section and its key components to highlight their importance.

global

Generally appearing at the top of the configuration file, the global section defines process-level directives such as the maximum number of concurrent connections, where to store logs, and which user and group the process should run under. Here's why each line from our sample matters: 

• The log line helps if you need to troubleshoot.

• stats socket is where you'll post your changes, also called the Runtime API.

• module-path is the path where all the modules reside by default.

• module-load references the module we need.

defaults

The defaults section contains common settings which will be inherited by frontend,backend and listen sections after it. It helps shorten longer configurations by reducing duplicated lines. Our sample configuration contains some generic values that are helpful to define. 

For example, client, server, and connection timeout values default to infinite if not set explicitly. Choosing a value for each helps avoid keeping open connections that were silently closed or discarded by one endpoint.

frontend

The frontend section defines which IP addresses and ports clients can connect to. This helps expose applications or websites to the internet. Our sample configuration contains many important lines that impact SSL/TLS enablement and certificate management. 

First, you must be in mode tcp since mode http won't work effectively at the time of this writing but should exist in the future. 

Second, we've set up a bind on the randomly chosen port 76. Make sure you modify this to be the port that your application uses. This particular line also contains some important pieces that influence SSL and certificate-related behaviors:  

• Together, the ssl and crt portions enable SSL in HAProxy Enterprise while specifying what certificate to present to the client in the server hello. 

• ca-file specifies which certificate authority to present. This file can contain more than one CA if needed, but requires a CRL for each in this instance. 

• verify required states that the client's certificate must be valid or the connection will be rejected.

• crl-file refers to your certificate revocation list.

• Lastly, filter sslcrl enables the ssl-crl module.

backend

The backend section defines a server pool to which HAProxy Enterprise will route requests. You can normally add as many backend sections as you need to your configuration, but our example contains a generic configuration for the purposes of this walkthrough. 

With this overall configuration, you can now configure your client software to send a certificate. HAProxy Enterprise will validate this certificate and accept it if it's valid. If you'd like to set up your own test certificates, this blog post from Didier Stevens (unaffiliated with HAProxy Technologies) outlines some great how-to steps. The creation of these files is outside the scope of this blog, however.

Using the CLI to view and revoke

First, we recommend viewing your current CRL file. This is also helpful to run before and after your updates if you want to validate the changes. Run the following command:

Here's a sample output from our earlier configuration:

To verify that the certificate is valid and usable with your certificate authority, you can use OpenSSL to check the client certificate:

Lastly, you can then use openssl to open a connection to your frontend and use the client certificate. Also confirm that www.host.com resolves properly to the IP address that your frontend is listening on:

Intelligent certificate management is essential in cases where certificates and keys are lost, stolen, or intentionally abused to launch cyber attacks. HAProxy Enterprise makes this complex process even easier and more flexible—letting you enable SSL, define certificate-related behaviors, and leverage certificate revocation lists to bolster infrastructure security. 

HAProxy Enterprise removes the burden, frustration, and revenue loss that can result from dropping all existing client connections to counteract suspicious behavior. Harness real-time revocation to keep your systems safe and your customers happy. To learn more, check out our HAProxy Enterprise SSL-CRL documentation or our HAProxy and Let's Encrypt: Improved Support in acme.sh blog post.

The issue in the HTTP/2 multiplexer allows remote attackers to trigger under very rare conditions an endless loop in HAProxy which can result in a crash.

If you are using an affected version of our product, you should upgrade to the fixed version as soon as possible or apply the workaround until you can upgrade.

Workaround

If you are not able to update right away, you can disable the zero-copy forwarding system to mitigate the issue. Add the following configuration directive in your HAProxy’s global section:

global
  …
  tune.h2.zero-copy-fwd-send off

Affected Versions & Remediation

Users of the affected products should upgrade to the fixed version as soon as possible by following the instructions below.

• Update HAProxy Enterprise

  • Update HAProxy Enterprise as a Docker container

• Update HAProxy ALOHA

• Update HAProxy Kubernetes Ingress Controller

• Update HAProxy Enterprise Kubernetes Ingress Controller

Amazon AMIs and Azure VHDs are available.

Support

If you are a customer and have questions about upgrading to the latest version, please get in touch with the HAProxy support team.

HAProxy Enterprise can be used to uniquely identify every request as part of a greater tracing strategy. Since HAProxy Enterprise sits before your applications, it’s the logical starting point to create a unique ID that can be traced as the request moves through your network.

To accomplish this, we’ll need a unique identifier (what we will refer to as a correlation ID) added to three places within your system—the request, the load balancer logs, and the response back to the client. We’ll also add a JA3 fingerprint to our logs to identify the requestor more accurately than an IP address.

Let’s get started.

Step one: Adding a correlation ID to the system

First, we will add the correlation ID to the system in the request, log, and response to ensure the unique identifier is carried throughout the entire journey in the backend. This setup makes it easier to trace its path through your network.

Add to the request to your backend so that your backend can process it:

Next, we want to add the same ID to the response back to the client:

Client fingerprints in JA3 format are often useful for managing bots, but in this circumstance, we are logging client fingerprints to correlate requests more accurately.

First, ensure you have the Fingerprint module installed (refer to our documentation). Use the following command:

Now, we will configure HAProxy Enterprise to log both the correlation ID and the client fingerprint together. This setup helps identify the type of client software and allows the backend application to track the processing of individual requests. However, comprehensive request tracking across multiple requests requires additional steps on the backend to associate and relay the correlation ID through all relevant function calls and subsequent service requests.

HAProxy Enterprise:

Configuring HAProxy Enterprise to log client fingerprints alongside correlation IDs is a first step toward achieving end-to-end tracing. However, setting the correlation ID within HAProxy’s logs does not immediately provide full tracing benefits.

To fully leverage this setup, client applications should use the correlation ID to trace their own function calls and forward them to any service they interact with. Furthermore, integrating tools like OpenTelemetry can further enhance your tracing capabilities.

By taking additional steps, financial services can improve their ability to detect and mitigate fraudulent activities, enhancing their overall security posture.

Building on our prior discussion on securing traffic between systems using mTLS certificates, this blog post describes how to deliver the same capability using SPIFFE and SPIRE, both CNCF projects, to automatically generate and renew identities that include mTLS certificates. 

While the original approach to achieving mTLS is a fine solution, manually generating certificates is not ideal for zero-trust networks. Instead, automatic generation of identities, including the needed mTLS certificates, will ensure that certificate management follows best practices—that certificates are short-lived, and that certificate generation does not result in inevitable failure.

The end result of automating certificate generation? A service mesh composed of HAProxy instances, all securely communicating with each other.

• A central system that you can use to register new workloads.

• HAProxy instances that automatically receive a SPIFFE SVID (a workload ID that includes a mTLS certificate).

• HAProxy instances that communicate with one another using the appropriate SVID.

Key terms

Before diving into configuration, let’s introduce key concepts related to the SPIFFE protocol and its SPIRE implementation.

SPIFFE

Secure Production Identity Framework For Everyone (SPIFFE) is a set of open standards aimed at securely identifying software systems in diverse and changing environments.

SPIRE

SPIFFE Runtime Environment (SPIRE) implements the SPIFFE specification, a framework for issuing and managing SPIFFE identities.

mTLS

Mutual Transport Layer Security (mTLS) is a security protocol for authenticating the client and server in a session, providing encryption and ensuring the secure exchange of data.

Workload

A workload is the collection of resources communicating with each other, each using the SVID issued to it.

SVID

A SPIFFE verifiable Identity Document (SVID) is a cryptographic document attesting to the identity of a workload, used to verify authenticity within a SPIFFE environment.

SPIRE Server

A SPIRE Server holds your workload identities, issues the right SVIDs, renews them, and serves them to SPIRE Agents.

In the most basic deployment, you'll run one server. It's a good idea to run more in production to support high availability.

SPIRE Agent

Every HAProxy instance will run a SPIRE Agent, a software instance that carries out several functions needed for secure communications. The agent attests itself (registers) to a SPIRE Server through one of the available methods—in our case, a join token.

When a new SVID is issued, the agent receives it and caches it. We can then instruct the agent to output the two needed mTLS certificates, which are sometimes called an SVID certificate and a Bundle certificate.

The SVID certificate is the client certificate that an HAProxy node should use on the backend to connect to the other HAProxy nodes. The Bundle certificate is the server certificate that each HAProxy node will use on its bind line to verify the incoming requests (which use the SVID certificate).

The official SPIRE documentation has good instructions to get started, but in the below, we have adjusted them for the specific HAProxy use case.

Part one: Installing the SPIRE Server

First, install a SPIRE Server on a typical Linux distribution using the latest SPIRE release:

If you look into spire-1.9.0/conf/server/server.conf, you should see a configuration similar to the following:

• bind_address and bind_port: these are addresses the SPIRE server will listen on

• trust_domain: This can be, but does not have to be, a DNS name. It identifies the trust “circle” for the workloads. SPIRE supports advanced federation, which is not part of this blog post; just know that, in this case, every node in this trust domain will be able to talk to other nodes in the same domain

Next, start the SPIRE Server:

For the first node:

Now log in to your HAProxy nodes, download the same SPIRE release as your server, and edit your conf/agent/agent.conf file:

• trust_domain must be the same as on your server.

• Set server_address and port to the IP address of the SPIRE Server and the port that you bound SPIRE to.

Finally, start the agent on every node and use the correct join token you obtained previously:

Back on the SPIRE Server, you can now create a workload entry for each one of your nodes. This entry is what will generate the SVIDs on the agent.

Part three: Get the certificate on the agent and put it together

To validate that everything works, run the following command on the agent to fetch the certificate:

• svid.0.key (the certificate key)

• svid.0.pem (the client certificate)

• bundle.0.pem (the server certificate)

Following our original instructions, you can now use these files in your HAProxy configuration. 

Just remember: bundle.0.pem is the certificate you should use on your bind line, and svid.0.key and svid.0.pem are the certificates for the client or backend server line (in the Send a Client Certificate to a Backend Server section).

As long as the spire-agent is running, it will automatically fetch and cache the new certificates on your nodes, but it doesn’t actually save them in your filesystem to be used. To do that, you could continuously run the API fetch command, or use a utility called spiffe-helper.

Here is an example script you could run in cron to fetch the certificates and send them to HAProxy:

Adopting a zero-trust security model for your HAProxy instances is necessary in an environment where internal systems cannot be trusted. 

By following the steps outlined in this blog post, you can leverage SPIFFE and SPIRE to automatically generate mTLS certificates for your service mesh. With this approach, your HAProxy instances can securely communicate with each other, strengthening your security posture while simplifying certificate management by removing the manual work and risks involved with renewals.