HAProxy Reviews

We use it as a load balancer for our application servers, including Bonita, VPMN, our NAS reporting tools, and Telus solutions. We have two or four applications in the back end and use HAProxy as a load balancer.

Currently, we're just using it as a load balancer. We haven't explored all the functionality yet, but we find it has too much to offer.

There is room for improvement in the pricing model. It could be cheaper. 

We have been using HAProxy for a month. We are using the latest version.

We were using a big program, which caused issues when one of the servers went down. However, with the use of HAProxy, even if one of the nodes goes down, the request and reply can still be received, making it more stable.

It is a stable solution. 

It is scalable. We haven't experienced any major issues with scalability. We didn't need to apply any specific scheduling to the system. We have up to 1000 users in our company.

We were using Snap before. I don't know if you're familiar with it. It reached its end of life last month, in March. So we made some comparisons to find a replacement for Snap, and my team and I chose to use HAProxy. We just started using it. We paid the enterprise fee towards the end of last year.

The initial setup is fine. We just need to configure the solution. One good technical person is enough for the deployment. 

For the deployment process, we need to install Linux and follow the instructions provided on the site. It is deployed in the production. We did the collection online with the installation and checked out the bulk of the management before logging in and starting the application deployment. One of our team members took care of the installation.

There is a license model in place. It is accessible. 

I would definitely recommend using the solution. Overall, I would rate the solution a nine out of ten. 

HAProxy has been our primary SSL termination technology in production. We use it for our own product, which is Qivos Cloud. It is a software service and we used HAProxy for high-traffic API gateways. These products load balance our servers.

We are using HAProxy, for secondary loads and use cases. There are times that our customers require specific static IP addresses versus AWS CloudFront, which uses IP pools. So when we have such environments, we use HAProxy for SSL termination and load balancing.

Stability is number one. We have never had problems with it. When configured correctly, it could run for years. We never had a task that we could not achieve with HAProxy.

The reconfigurability in terms of the tooling could be improved and maybe an editor plugin can be added. Something that might help with syntax or common use cases.

We have been using HAProxy for more than five years.

HAProxy is very stable.

We had no problem with scalability both in terms of scaling HAProxy itself, or the backend behind it.

We only used it for public resources, like the manual, documentation, or stack overflow. We could find the solutions easily.

We replaced HAProxy with CloudFront because we switched to a serverless option. We did not have a problem with HAProxy. We re-architected our solutions. SSL termination and load balancing now happen in AWS CloudFront and application load balancer.

We deployed in-house. We learned how to use it. I would say less than a month. In the beginning, we only did specific things and over time we gained expertise and we expanded our users, but it was, more or less, a month to go with production.

HAProxy was very easy to script, but it had a learning curve back then. I am talking about four or five years ago. Once we gained our expertise on what we wanted to do with HAProxy, it was easier. We only used the open-source version of HAProxy for pricing.

HAProxy is something that we manage ourselves, so we cannot directly compare it with Amazon CloudFront. If we only focus on technology, it is the same features. The only reason we switched is because of management costs.

HAProxy is definitely a dependable choice. The only thing that needs some attention is the initial learning curve. When you get past that, it is a great tool to use. We are very happy with it. I would rate HA Proxy a nine out of ten.

I use it for managing Redis clusters where I have a front-end for a read-write and a front-end for a read-only. I have no idea who else in my company uses it. I had opted to use this because we have silos in our company. We have a network silo that does the load balancing, and I wanted to control how these tests worked with the load balancing. I wanted them to do load balancing where they hand off like a TCP Fast Open. They perform a check on these services with TCP Fast Open.

For example, there is one free HAProxy service for each node, and they use TCP Fast Open for things like that. It's flipped to the HAProxy, and then they establish a persistent connection. It's more of a hand-off, and then I can do all the magic. You can do most of the things I'm doing with HAProxy in F5 too. However, it's siloed off and takes a long time to get things done. I don't have any agility. I took that upon myself with HAProxy because it's a lot quicker to do it myself instead of waiting weeks for somebody else to do it.

The most valuable thing for me is TCP/IP Layer 4 stuff you can do with HAProxy. You can go down to the protocol level and make decisions on something. 

The logging is pretty hard to understand, but the documentation for the logging is decent. That would be my only criticism. Sometimes it's challenging to get through the log, and you need a log to understand what is going on. It isn't easy to map the logging with the documentation, and every time I read the log, I have to pull out the documentation to understand what I'm reading.

And there is some more functionality that I would like to see. For example, you'll do a TLS to the front leg— whatever connects to your load balancer. You do the HTBS or whatever TLS connection there. And then, on the back end, you usually have to clear it a lot of times. I want to be able to do TLS all the way through on both legs. I don't know if it can do that. HAProxy might be able to do this already, but I haven't done enough research to see if this is possible

Probably about two years now.

HAProxy is rock solid. I'm pleased with it.

HAProxy is scalable. It easily handles the current loads, but my connections are pretty low. It can take a lot more than what I'm doing. I'm making around 200 connections per second, which doesn't put much stress on the solution. HAProxy can handle it pretty easy.

I've never used any tech support. I just use the freeware.

The setup was pretty straightforward. When I started using HAProxy, I played around with it in a container and built from source, so I got a good feel for what it could do. And then I picked up a book called Load Balancing With HAProxy. After I read that, I felt confident I could use this service in a production setting. I was able to tune the knobs I needed to adjust and understand things pretty well. The book is pretty decent, but I wouldn't mind seeing a newer version of it. It was helpful. 

The HAProxy documentation on the web isn't bad, but the book is much nicer for me. I like to see how the authors apply HAProxy to specific use cases and leverage things. Also, they explain how to do something, whereas the documentation only tells you about the features and parameters. Sometimes it's hard for the documentation to show the importance of a feature and express how to do what you want. 

I'm using the freeware version. I have no idea if there is a paid solution because I've never looked into it. I might in the future if I have a use case for it. But right now, I'm leveraging the free version, and it seems to fit well in this stack because I'm using the free Redis.   

I would rate HAProxy nine out of 10. My biggest recommendation for any new HAProxy user is to read Load Balancing With HAProxy by Nick Ramirez. If you're thinking about using HAProxy and you want to get your feet wet, read this book and follow along with it. Determine whether you're trying to do an HAProxy for a web service or something else and concentrate specifically on those pieces. I read the whole book and enjoyed it, but you can focus on one thing if you need to. This book is short, and you can just read the whole thing to understand it.

Our primary use case for this solution is to perform Layer 7 load balancing/reverse proxying of both our internal and external web applications.

We also use it for SSL offloading, and are beginning to utilize the basic Web Application Firewall functionality of it. 

HAProxy also performs VRRP, for redundancy, in case one of the servers were to go down.

I estimate that this product has saved our company hundreds, if not thousands, of dollars in possible downtime from previous load balancers. We make a lot of our money from online sales, so it is critical to have 99.9% uptime.

The ease of use of the configuration, and great documentation, are the most valuable features for us.

The VRRP redundancy is also a mission-critical feature that works seamlessly. I can bring down a server live with minimal downtime because of this.

The only area that I can see needing improvement is the management interface, since it is pretty much all through the CLI or configuration. However, HAProxy does have another product that we evaluated called ALOHA, which has a web front-end, but we found it did not meet our needs.

No stability issues. HAProxy Enterprise Edition has been rock solid. We have essentially had no downtime caused by our load balancers in the last 10 months, because they’ve worked so well. Previously, our load balancers caused us multiple hours per year in downtime. 

I am also able to make configuration changes during the day, in production, with no worries of problems and/or downtime occurring.

No scalability issues, but only because we do not deal with a lot of scale here. We simply rely on an active/passive configuration, so if a load balancer were to fail, we would have a backup instance ready to go.

The technical support has been, in one word, perfect. Every time I call, I’m on the phone with a representative within five minutes who is highly skilled and willing to help, whether in the case of critical issues or simple advice. They always make me feel like I can pick up the phone just to have a good conversation about a new feature, a bug, a "what if" scenario, or anything else.

We previously used Coyote Point load balancers, and then switched to Fortinet’s Application Delivery Controller, due to end-of-life on the Coyote Points. After a few months of major issues involving hours of downtime and slowness, we had to make a decision to move away from Fortinet. We chose HAProxy because of the open-source community behind it, and previous experience with it. We then decided to upgrade to the Enterprise Edition for the support they offer.

The initial setup was fairly straightforward. With a minimal configuration, you can get up and going quickly. However, it is very easy to modify the configuration to meet any requirements you may have, and reload in production with no downtime. The only complex part is having to maintain the base operating system, as HAProxy EE is simply a Linux package. The hardening of the operating system was done by myself since there is no appliance, like their ALOHA offering.

The price is well worth it. HAProxy Enterprise Edition paid for itself within months, simply due to the resiliency it brings. It was a bit more expensive than we were originally interested in paying, but we are thankful we chose to go with HAProxy.

We did not evaluate any other options. We considered looking at Barracuda’s offerings, but after a few days of evaluating HAProxy, we decided that it would be the best fit for us.

I would rate this product a nine out of 10. I only took off one point because of the lack of a GUI, although in this case I would say that I prefer the CLI and configuration, which is primarily how we manage it. A GUI/web interface could be helpful for users who are not as experienced in the Linux shell.

Be sure you are familiar with the Linux command line and have networking knowledge. Specifically, VRRP is helpful to understand the high-availability aspect of it. The documentation is very helpful, so be sure to follow their given best practices and configuration tips.

The main use cases are for load balancing and limiting traffic. It is utilized as a front-end server for balancing HTTP traffic, as well as for balancing traffic between application servers and database servers like Redis and Elasticsearch. HAProxy is employed for both HTTP and TCP load balancing purposes, ensuring optimal resource utilization and preventing overloading of any single server. 

When dealing with scenarios that require splitting or monitoring Redis clusters with external masters and two slaves, HAProxy becomes essential. This is because HAProxy can significantly reduce delays in Redis communication when switching roles between servers. This reduction in delay improves application load time and prevents unnecessary downtime during server switchovers. It is a crucial tool in ensuring smooth service provision without any interruptions.

There is room for improvement in HAProxy's dynamic configuration. Currently, dynamic changes are lost when reloading the service, and it would be beneficial if dynamic configuration changes could be applied without losing the configuration or reloading the service, ensuring backups and preserving the static configuration.

I have been using it for six years.

I would rate its stability capabilities nine out of ten.

It provides impressive scalability. I would rate it ten out of ten.

In a specific situation where a question was posted on a forum, the issue was successfully resolved within a day or the following day. I would rate their customer support services nine out of ten.

Positive

We worked with NGINX, but these two solutions are not entirely comparable as they serve different primary purposes. NGINX functions both as a web server and a reverse proxy server, while HAProxy is primarily a load-balancing proxy. They both have load-balancing capabilities, but their main focus and functionalities are distinct.

The initial setup can be challenging. I would rate it six out of ten.

For simpler cases, the deployment process can take around one hour. For more complex scenarios, it can extend up to one week. 

We are using HAProxy as an open-source.

NGINX is easier to configure and is well-suited for load balancing against an application server. However, HAProxy is more versatile and can be fine-tuned for various scenarios, particularly in load-balancing multiple application servers. In terms of deployment, HAProxy is easy to integrate into a green-blue deployment approach. It allows for simpler configuration and sending commands to its sockets.

Based on customer stability and varying use cases, I recommend choosing this solution. I would rate it nine out of ten.

We have the following use-cases for HAProxy:

1. To load-balance dozens of Apache 2.4 Servers mod_proxy. (Internal load-balance Tomcat, Jetty, JBoss app containers, using TCP load-balancing).
2. To load-balance hundreds of MySQL and PostgreSQL databases using TCP load-balancing. We manage inventory of these through Ansible automation.
3. To provide a layer of security (username/passwd) authentication for legacy back-end Web apps that may not have username/passwd implemented yet. Some financial Web apps were created over 15 years ago and focused on reports, files, logs, and market share stats and were written in Perl. We also had a very old Kibana interface to visualize those logs. Such Web apps required HAProxy to tunnel the requests with un/pw authentication.
4. To redirect traffic internally based on /URL to the relevant services (DNS nameserver) and as a gateway to tunnel traffic to customers who explicitly require reverse-IP authentication. The DNS nameserver was a trendsetter that we learned quickly and now cannot live without.

As our traffic began increasing nine years ago, we desperately needed to load-balance TCP requests (for DBs). We originally used round robin on an array[] which stored the IPs of half a dozen DBs. But with HAProxy, we didn't need to maintain such complexity. We later exploited many more features.

The most important features would be the load-balancing of HTTP and TCP requests, according to multiple LB algorithms (busyness, weighted-busyness, round robin, traffic, etc). 

Another important feature that we cannot live without is the username/passwd authentication for legacy systems that had none.

The web stats UI, which provides the status of the health and numbers, could greatly benefit from having a RESTful interface to control the load-balanced nodes. Although there is a hack around the UI (by issuing a POST request to HAProxy with parameters), a RESTful interface would greatly improve the automation process (through Chef and Ansible).

I have deployed over 50 instances of HAProxy over the past 15 years and never encountered any stability issues. Most HAProxy instances have continuously run for over two years until the server required a kernel upgrade.

I have used it for over 10 years. I started using it as a Web application (Tomcat, Apache, JBoss) load-balancer when it had a few stable releases. When I first start using it, HAProxy was primarily used to load-balance HTTP requests. Since we are a B2B company that deals primarily with hotel inventory, IP authentication was a must. Therefore, our customers had single end-points to send and receive RESTful requests. To make this viable, we had to use a central server as a proxy to tunnel out the requests. We will continue to use HAProxy as our entry-point and exit-point of the system.

In some environments we are handling millions of requests per minute in a high-availability HAProxy cluster. I don't know any other free software that can do that, from a performance perspective.

• Reliability. HAProxy is the most reliable product I have ever used.
• It is stable. Period. Will not fail unless you do something wrong.

These features are why I give it a 10 out of 10.

HAProxy running in multiple cores, for example one for HTTP and another for HTTPS, requires the use of "nbproc". So if nbproc = 2, you will have two processes of HAProxy running. However, the stats of HAProxy are not aggregated, meaning you don't really know the collective status in a single point of view. Each process has its own socket and it's up to you to aggregate them, and then your stats become less accurate.

Also, having multiple HAProxy nodes in High Availability mode requires the use of clustering software such as Pacemaker and Corosync which are very complex.

Yes, I have encountered issues, but they are always related to configuration, OS settings, network.

Yes, there have been issues with scalability, but that's because of other software configuration such as OS settings, network.

We don't use commercial support.

I used appliances such as Alteon (Radware) which are not as good and do not support all the features required in our environment.

Setting up an HAProxy is simple, however to run it in production you have to do a lot of tweaking.

There is no pricing for HAProxy. There are other HAProxy paid products (support/appliances) but we haven't used them so far.

Only lately, nginx has introduced an advanced "proxy" product. It is okay, but HAProxy is better in terms of performance and stability.

• Use the best hardware you can (CPU and memory).
• Don't log files locally, if possible.
• Use multi process only if you have to, and don't utilize the first core.

We use the open source version in our dev environments, and the commercial product for production and pre-production. Our primary use case is for reverse proxy, especially for switches in the different environments. I am a system engineer. 

The solution is user-friendly, works quickly and efficiently. 

I'd like to see better documentation and preferably a French version as well. The product is used a lot here and that would be helpful.

I've been using this solution for a year. 

In my previous job we had some stability issues related to configuration and compatibility with other products. It was unstable because of cookie problems. 

We have good scalability. 

The initial setup takes a few minutes. We use Terraform to deploy and it's very fast. We have five users in the company. 

I had a look at Nginx for the reverse proxy part but I preferred the typology of the writing of HAProxy.

It's important to define your use case clearly so you can be sure the product corresponds to your needs.

I rate the solution seven out of 10.