HAProxy Reviews

My main use case for HAProxy is to serve web pages, call backend applications, and serve customer queries. On HAProxy, we have different rules to accept user requests and redirect them to either Nginx in the backend for proxy pass or reverse proxy, or we give it to the Tomcat application, a Tomcat Java application, to serve the request and give the response back to the customer.

Regarding how those rules work, for example, let's talk about serving static content. We have a rule, such as /static or some node URLs. Based on that, we give the request to Nginx to serve the static content. Static content is hosted on the local server or maybe some S3 bucket. Similarly, if there's a Java application URL for various purposes, such as reporting, transactions, payments, or order booking, all those requests, based on whatever rules we have, go to the backend Tomcat application where we've configured multiple servers for high availability. We have also kept HAProxy in the backend to the application load balancer, so we can manage multiple HAProxy servers with a single application load balancer and from there manage multiple Tomcat Java application servers, multiple Node servers, or multiple static content Nginx servers.

The best features HAProxy offers include the reverse proxy feature, which I find to be the best. The second is that the rules and templates are very easy to understand, read, and write. Another great feature is that HAProxy supports SSL, the certificates and all for multiple domains. This is also great and while it is available in other web servers, HAProxy includes it here, which is useful. The simplicity of the rules is another advantage which I mentioned earlier, and the logging of HAProxy has in-depth printing that can be very useful. We can pass those logs later for our analytics purpose.

Regarding logging, we log the X-Forwarded-For IP, the original client IP from where the request lands to HAProxy so that we can see which IP is hitting how many requests with what action or what URL. This helps us identify potential spamming attacks or scraping on our platform. We parse all these logs or forward them to a centralized logging server so that the other team can review and take action. For example, we can block it in our firewall or web application firewall, or we can implement rate limiting based on this logging analysis. As for the rules, we can mention multiple domains' configurations with actions or rules and redirect them to any backend server, whether it is a Java application, Next.js application, or any Node application. This way, they will be served better.

I think HAProxy is good as it stands now, but I believe there could be improvements. gRPC has recently been implemented, which is great, along with TLS 1.2 and 1.3 support, and HTTP 2.0 is also available. However, I'm unsure about the benchmark of those HTTP 2.0 requests on HAProxy. If there were any other protocol with better performance than HTTP 2.0, or perhaps mTLS and other similar features, including that in HAProxy would be really great.

For improvements, I think that during setup and configuration, the steps provided are neat and clear. Anyone can easily install and configure it. There are many kernel tuning parameters also available, which is great. For specific improvement, in terms of logging, I think printing the full object of the request may help, or if there's a way to reference two requests, it would be beneficial to find a complete session history from a logged-in customer, as it would help analyze customer and user analytics.

HAProxy is something we started using somewhere in 2013, almost 12 years back.

HAProxy has helped with performance and uptime. Before HAProxy, we had Apache web servers. The performance of HAProxy is awesome; I would say it's far better. We have reduced a lot of servers, replacing them with one or two HAProxy servers which deliver better performance, accuracy, and an almost 100% success rate with requests coming from customers or other sources, and there are no loopholes, disconnects, or gaps in the entire data flow.

HAProxy's scalability is excellent. We have multiple HAProxy servers, and we've achieved load balancing based on CPU utilization, CPU load average, and memory. We manage an automatic load balancing feature where we add HAProxy servers dynamically behind the application load balancer to handle more traffic. At low peak levels, we remove HAProxy servers after completing in-flight requests, managing our scalability efficiently.

So far, we haven't needed to reach out for customer support for HAProxy. We have utilized all the features provided without requiring assistance.

Positive

We were previously using Apache web servers before implementing HAProxy, and we switched because Apache gave us many issues with customer user queries. It would time out, slow responses, and even throttle requests in a heavily loaded environment. We haven't seen those issues with HAProxy. HAProxy performs well with proper CPU utilization and maintains great accuracy with a high success rate.

Before choosing HAProxy, we evaluated other options. When we experienced challenges with Apache web servers, we considered whether to go with HAProxy or Nginx, but we chose HAProxy due to the benchmark results with our rule sets showing it winning in most cases. That's why we have been using HAProxy in production for the last 12 to 13 years.

In terms of my setup of HAProxy, we have the open-source HAProxy latest 3.0 on Linux, Amazon Linux OS server. By the way, we have multiple HAProxy servers. We follow the standard configuration on the Linux platform along with high tuning parameters and kernel tuning parameters so that it can serve multiple connections parallelly without any connection overhead or taking much resources. We do a lot of kernel tuning parameters for HAProxy to serve with better performance, fast, and accurate.

I can share one use case in terms of ROI related to money and time saved. We had multiple Linux servers for Apache web servers, which we replaced with a few HAProxy servers. This resulted in a drastic decrease in costs and, at the same time, the accuracy of the hits coming on HAProxy was almost around 100% or 99.99%. This was not the case with the other web servers in our heavily loaded environment.

I find the pricing, setup costs, and licensing for HAProxy to be acceptable. The setup cost is fine since we understand the logic and concepts behind it. We should explore how licenses can be further improved, but I believe the offerings of HAProxy are really good, and I don't see any concerns or challenges regarding pricing.

For the backend configuration, there are a lot of features provided by HAProxy, including multiple connections and timeout settings.

HAProxy has positively impacted our organization as we serve many domains. We use rules to serve our B2B domains, which include numerous B2B websites served through HAProxy based on requests and other requirements. All these B2B platforms handle regular order bookings, payments, different analytics, and MIS reports, among many other activities. It's one of the best; we don't use any other web server apart from HAProxy.

My advice for others considering using HAProxy is that it should be based on their specific requirements and challenges within their environment. I recommend conducting benchmarking and testing in their staging or performance testing environments. HAProxy is one of the best web servers known for its drastic scalability, performance, and accuracy, as mentioned earlier. I also suggest focusing on the simplicity of use and debugging, making HAProxy a favorable option.

I think HAProxy is good, and I can see that many new versions are being released. There is a proper release mechanism or SDLC life cycle for HAProxy versions, which is commendable. Overall, I believe in using it as it is. I would rate this solution a 10 out of 10.

My main use case for HAProxy is as the Ingress controller for all my workloads sitting in Kubernetes, where anything entering from the public internet has to hit HAProxy first. HAProxy makes the weighted routing for blue-green deployments and also some sort of request and header-based routing to different environments and different applications or microservices in the Kubernetes clusters.

I used HAProxy mostly with the initial 1.5 or 1.6 Kubernetes clusters where it was the only solution compatible with NGINX, which I used for Kubernetes workloads and also for the monolithic architecture where the traffic comes from the external world, and we want to have a similar kind of configuration with a load balancer in place. I use the same HAProxy open source for on-premises to maintain similar toolsets, one from the commercial variant for the cloud and one for the on-premises variant.

A unique use case I would highlight is that initially, most API gateways or reverse proxies did not support all the functionalities we expect from an API gateway. For example, we needed rate limiting functionality not just on IP addresses but on a mix of multiple headers and content manipulations. I used HAProxy for rate limiting and integrated it with ModSecurity, our homegrown tool from open source, which we wanted to inline with HAProxy. Eventually, HAProxy introduced WAF functionality for web application filtering, where we configured certain rules for acceptance and content enrichment, ensuring that X-Forwarded-For requests were sent to downstream applications for visibility and effective issue triage. We wrote some plugins for HAProxy and received significant help from the HAProxy team to empower our WAF use cases over time.

In my experience, the best feature of HAProxy is its load balancing capabilities, as it provides various algorithms, stickiness, and configurations. I have extensively used HAProxy along with NGINX over the years and found its load balancing feature to stand out. Configuration management is easy once you are familiar with deploying it, but it is not flexible enough to allow complete configuration from the UI. I have not used HAProxy in the last three to four years, but previously, its UI perspective was lacking, requiring manual adjustments. Though configuration management is not a primary focus, load balancing definitely stands out in terms of feature set. Flexibility-wise, we centralized multiple environments with a single HAProxy deployment, and its ability to handle billions of events amazed me. However, while security features have replaced WAF functionality, they are limited for smaller organizations that do not need dedicated load balancers or WAF capabilities. Built-in capabilities provide a core advantage from a cost perspective, especially for those starting out, and I recommend exploring Terraform or Ansible for configuration management, though it is still in an outdated style.

HAProxy positively impacted our organization by exceeding scalability expectations, initially projected at 200k requests but ultimately handling over 15 million transactions per second without any issues. We assume it can handle beyond 1 billion transactions per second since we encountered no performance hiccups. In terms of reliability, we have not experienced significant issues, though reliability concerns can arise during configuration management reloads. Cost savings are notable for startups needing minimal feature sets across WAF, API gateway, and load balancer functions, making HAProxy a cost-effective foundational tool that can save more than $100k per year for users.

One needed feature for HAProxy is a more robust API Gateway, which still has limitations despite many validations for Kubernetes, especially around ease of use and persona-based designs for different user roles. The existing functionalities around load balancing do not focus enough on security or configuration management aspects. The reloading functionality is effective as it allows soft reloads without interrupting traffic patterns, but configuration management should improve significantly, especially concerning UI and GitOps principles for easier management. While RBAC is implemented, it is not sufficiently granular for controlling access privileges, which should improve over time for managing distinct features.

A significant area for improvement in HAProxy is its tenancy model; managing multiple environments can be challenging, especially with mergers, acquisitions, or domain changes. It lacks centralized management capabilities for uniform configuration templates across regions. The tool should allow smooth version transitions and facilitate zero-touch deployments to streamline operations.

Enhancements in tooling and integration with technologies like eBPF are crucial for HAProxy. The customer support aspect also requires improvement, as their SLA responses are often not immediate enough for users who depend on HAProxy as a primary tool. Documentation can be better, particularly regarding configuration templates and best practices that fit diverse requirements.

I have been using HAProxy for almost four to five years during my career at Arista Networks and some portion at the Zeta as well, especially for the Kubernetes workload deployments from the marketplace.

HAProxy is generally stable in my experience, though issues can arise during configuration management when changes are necessary.

For scalability, HAProxy meets my needs, supporting our initial horizontal scaling and then adapting to vertical scaling in a VMware environment, utilizing Horizontal Pod Autoscaler (HPA) for Kubernetes and Vertical Pod Autoscaler (VPA) for the VM deployments.

My interactions with HAProxy's customer support were limited, but the feedback from my team indicated satisfactory service; however, SLAs were longer than our expectations.

Neutral

Before HAProxy, I initially used NGINX and switched due to scaling and reliability needs, finding HAProxy more maintainable and user-friendly with better documentation.

We purchased HAProxy via the AWS Marketplace, deploying it with our own methods using the provided Helm charts.

I estimate seeing a return on investment with HAProxy, as it significantly reduced staff requirements and enhanced scaling capabilities, particularly when transitioning from NGINX, which faced issues. Although HAProxy simplified the transition to Kubernetes, operational differences remained minimal over time.

My experience with HAProxy's pricing was positive, though I do not remember the exact figures as it was a few years ago. The pricing remains competitive compared to other vendors, and the service is somewhat aligned with recent tooling developments, although pricing structures may require re-evaluation for future offerings.

I considered NGINX during my selection process and also looked into Kong, which I find to be a robust API gateway with better functionality alongside Envoy.

We measured transaction rates and cost savings by comparing alternatives like dedicated tools for WAF, such as Cloudflare WAF or AWS WAF, noting their costs and estimating a 30% to 40% saving. We evaluated metrics with Prometheus, analyzed through Grafana, and created custom metrics that confirmed our handling of requests without any performance issues during our scale-up period. Cost-wise, we determined HAProxy was a tool that could replace WAF, load balancer, and reverse proxy capabilities in a unified solution.

I would rate HAProxy an eight out of ten because of concerns around configuration management, the need for better management of multiple environments, a single source of truth, UI enhancements, and the potential for more frequent updates and support. Once these areas are improved, HAProxy could easily become a nine or ten out of ten.

My advice to new users is to pre-plan their intended feature use, clearly define limitations, and understand compatibility to avoid scalability issues. It is also crucial to benchmark in real-time environments. Overall, HAProxy is a great product; thorough evaluation is important to ensure that it meets user expectations before fully committing.

My main use case for HAProxy is for my project, which focuses on full high availability. I use HAProxy for load balancing between my two apps while connecting to Keepalived. HAProxy is very helpful for myself and my team, utilized primarily for load balancing as it is powerful for that purpose.

The best feature that HAProxy offers is load balancing, as the ability to balance both transport TCP and application HTTP or HTTPS layers gives much flexibility. SSL termination is also essential, handling SSL efficiently as HAProxy supports dynamic certificate storage. Moreover, health check functionality is significant, as HAProxy constantly checks backend servers to ensure they are healthy and pulls them out of rotation if not, preventing server traffic issues.

One of the biggest wins with HAProxy has been SSL termination, as before using HAProxy, I had to install and renew SSL certificates on each backend server individually, which was time-consuming and error-prone. By moving all SSL termination to the load balancer, I now manage certificates in a single place, and I can also utilize Let's Encrypt with HAProxy's built-in ACME support, making renewal automatic. For example, we had a small cluster of app servers for a client project where each server served the same domain. Originally, every server had its own cert, leading to issues when scaling up or replacing instances, but after offloading SSL to HAProxy, the backend servers only need to communicate via plain HTTP, while HAProxy handles all the TLS handshakes.

HAProxy is already a robust solution, but there are a few areas for potential improvement, especially regarding configuration complexity. The configuration syntax is powerful yet can become overwhelming for newcomers; a more beginner-friendly interface or a native GUI without relying on third-party tools would ease the onboarding process. Built-in observability could be enhanced; while HAProxy features great logging and stats, utilizing Grafana, Prometheus, or external tools for in-depth insights is still necessary. Native service discovery could be improved; although dynamic scaling works, it generally requires DNS or runtime API scripting. More features in the Community Edition would be beneficial, as the Enterprise version contains advanced security, WAF, and bot protection that would be advantageous for smaller teams if included in the community build.

Another area that could see improvement is documentation and onboarding resources. HAProxy's documentation is very detailed but can feel dense for newcomers, and finding practical, step-by-step examples often requires sifting through mailing lists, GitHub issues, or blog posts. More modernized guide tutorials and real-world playbooks would simplify getting started for beginners, so enhancing technical improvements to make HAProxy more approachable through better docs and a stronger community ecosystem would significantly assist in broader adoption.

Additionally, an important area for improvement is tighter integration with cloud ecosystems, particularly AWS. Native AWS service discovery would be advantageous; currently, one usually relies on DNS or external scripts to register new EC2 instances in HAProxy, but direct hooks into AWS Auto Scaling Groups, ECS, or EKS would facilitate automatic joining and leaving of instances without added glue code. Furthermore, direct integration with AWS Certificate Manager or Secrets Manager could reduce manual steps surrounding SSL, TLS, and backend credentials management. Enhancing cloud-native integration, especially with AWS services, could significantly strengthen HAProxy's plug-and-play appeal in cloud environments.

I have been using HAProxy for maybe two or three months, as I just explored HAProxy and the configuration.

In my experience, HAProxy is remarkably stable; we haven't encountered crashes or unexpected downtime. Once running, it simply continues to operate without issues, and any downtime we've faced was linked only to planned upgrades or configuration changes, not the software itself. This reliability serves as a key reason for our choice, providing us with confidence even when faced with heavy traffic.

From my experience, HAProxy's scalability is excellent; as our traffic expands, it handles load increases effortlessly.

Our interaction has primarily been with community resources rather than the official support team. Since we are utilizing the open-source edition, community forums, mailing lists, and GitHub have been invaluable, with typically someone having encountered the same problems we faced. We haven't needed to submit a ticket to HAProxy Technologies' support team, but based on feedback I've seen, they are responsive and knowledgeable. For now, the combination of the open-source community and documentation has sufficed in resolving our issues, so I would rate community support as strong, but if guaranteed SLAs or direct assistance are required, then enterprise support would be the go-to option.

Before adopting HAProxy, we relied on NGINX as our primary reverse proxy and load balancer. NGINX served our basic use cases adequately, but we faced challenges as our traffic increased. The first challenge was flexibility; HAProxy offered more advanced load-balancing algorithms and health checks than we configured in NGINX. Next, dynamic configuration was a concern, as reloading config in NGINX led to occasional connection drops. HAProxy's hitless reloads and runtime API represented a notable improvement. Lastly, in heavy traffic tests, HAProxy demonstrated superior performance when handling concurrent connections, yielding lower latency and higher throughput in our setup. The shift wasn't due to any deficiencies in NGINX—it's still a solid option—but HAProxy simply aligned better with our scaling and reliability requirements as our infrastructure evolved.

Since adopting HAProxy, we've seen some remarkable improvements backed by numbers, particularly in downtime reduction. Before using HAProxy, we experienced small outages almost monthly due to backend servers going offline during cert renewals, but after centralizing load balancing and SSL management in HAProxy, those incidents have dropped to near zero with our uptime becoming consistent. Our average response time during peak load dropped by about 20 percent with connection pooling and Keepalived.

We've definitely seen a clear return on investment from using HAProxy, even while sticking with the open-source edition. Time savings have been significant; previously, SSL cert renewals across multiple servers took a couple of hours each quarter. With centralized SSL termination and automated renewals now in place, that time requirement has dropped to nearly zero hours, translating to dozens of hours saved per year. Operational efficiency has improved; we no longer have staff consistently monitoring backend servers during deployment or scaling events, as HAProxy's health checks and hitless reloads allow us to push changes with minimal manual intervention. This has freed up our operations team for higher-value work. Lastly, improved uptime stands out, with our uptime statistics rising from around 98% to consistently above 99.900, meaning reduced SLA penalties while keeping our clients happier.

Our experience with pricing, setup costs, and licensing has been quite straightforward. Since we use the open-source edition, there are no licensing fees, with the main cost being the infrastructure running on EC2 instances in AWS, which helps maintain low expenses. Regarding the setup cost, the primary investment centers on time and expertise; while HAProxy is incredibly powerful, the initial setup requires a bit of a learning curve. However, once the configuration templates are established, adding new applications or backends becomes easy. We haven't opted for HAProxy Enterprise yet, so there are no licensing complexities. In summary, using the open-source version incurs low financial costs but requires an upfront effort to set up, resulting in an overall cost-effective experience.

We evaluated a few other options before deciding on HAProxy. The primary alternatives were AWS ELB and Application Load Balancer; while they are convenient and integrated, they are also less flexible and their costs add up when compared to operating HAProxy on our own instances.

My advice for others considering HAProxy is to not be dissuaded by its learning curve; it's wise to start with a simple load-balancing setup and gradually incorporate advanced features such as ACLs, SSL termination, or rate limiting as confidence grows. Additionally, leveraging community resources and example configurations can save substantial time. Furthermore, if you're managing mission-critical workloads, it may be worthwhile to contemplate whether HAProxy Enterprise could provide the additional support and features desired. My guidance is to initially keep things simple, rely on documentation or the community, and expand into the more powerful features once the foundational stability is established. I rate HAProxy 9 out of 10.

HAProxy serves as an application load balancer that facilitates communication between applications and microservices. We operate an ad-serving platform that receives a high volume of requests to our front-facing application, and depending on certain criteria, we pass those requests to our backend application, which is horizontally scaled. We needed a proxy or load balancer between them to proxy all these requests. Instead of using a cloud-native solution, we chose HAProxy, which helps us scale effectively whenever requests are being passed through.

Being an e-commerce application, we often received a lot of requests, and although we scaled our applications in the backend, HAProxy managed to handle all those connections without much scaling. This significantly helped us during events with massive traffic or specific campaigns in our e-commerce applications.

The proxying capability itself is a feature we have used, and we utilize it as a load balancer. The multiple algorithm support, such as round-robin and least requested, along with all those options, proved very effective, and it was able to handle a lot of connections.

The concurrency handling of HAProxy was remarkably efficient. As a production engineer at that time, I definitely wanted to ensure that the system could handle massive connections, especially since we operated an e-commerce platform where we could not lose any customer calls. It was very critical to handle all the connections, and therefore, the concurrency handling of HAProxy was truly efficient.

During those high-traffic campaigns, there was actually very minimal latency. There definitely was a spike in latency, but it was very minimal, and HAProxy was able to manage the traffic without any noticeable latency in the application.

HAProxy already provides many of the features that other solutions in the market are providing, such as Nginx, so I do not see much room for improvement.

I have been working in the current field for more than 15 years.

HAProxy is definitely stable. It was very scalable, and we never had many issues. The hot reload feature of HAProxy also really helped us so that we never had to shut it down to reload it.

HAProxy's scalability is excellent. It handles tens and thousands of connections without any problem.

I have never had to contact customer support, so I cannot speak to that experience.

Neutral

Before choosing HAProxy, we evaluated Nginx.

We tried Nginx before using HAProxy, but HAProxy was far better than Nginx, especially because of the syntax. We had a script that auto-reloads HAProxy, making it a superior choice at that time.

We definitely saw fewer employees needed and money saved. We achieved 100% money savings and fewer employees with very little maintenance required. HAProxy has a very community, so we never had to get stuck while troubleshooting or creating new configuration files, resulting in significant time saved.

Since we used the open-source version, we were not concerned about pricing, setup cost, or licensing.

My advice for others looking into using HAProxy is that it is really scalable. We used the open-source version, and I think the paid version offers even better options and support. If you are looking for a proxy solution, HAProxy is a good option to consider.

I would recommend moving forward with HAProxy. I am rating this review a 10 out of 10.

I have been using HAProxy for about a year.

My main use case for HAProxy is mostly forwarding public traffic into internal services over a Proxmox HA cluster. I get traffic from Keepalived VIP and forward it to HAProxy, and from there to internal services. I monitor and track port 80 and 443.

I am also using HAProxy for Redis and RabbitMQ traffic. I have three dedicated servers right now, with each server having one Redis node and one RabbitMQ node. Based on the traffic, for example, if an API is running on host one, HAProxy forwards traffic from this API host one to host one Redis node or RabbitMQ node one, internally making them use the same host to prevent latency.

The best features HAProxy offers for my setup are easy configuration, as I don't need to set up many things; I just installed it and write configurations based on my needs. Traffic flows easily, and it's easy to manage all the internal services in one place, in one file.

The configuration is easy for me because the syntax is straightforward; it's easy to catch paths and domains. It seems simpler than NGINX, and the load balancing is very good on HAProxy. The load balancing is easy on HAProxy, and I appreciate that.

HAProxy has positively impacted my organization by making it easier for me to manage configurations. I put configuration files on the Ceph storage shared across the whole cluster, allowing me to write my configuration, change it easily in one place, and reload it. I wrote a reload script that reloads all the configurations on all the cluster nodes, allowing them to run smoothly.

I don't know how much time I save, but it made my setup stable, which is the most positive aspect. There are months when I don't even touch it as long as I don't add a new service on my cluster.

HAProxy is very easy for me to use. I installed it easily and configured it after checking the documentation, which was clear. I wrote as described, and it worked well, but an easier desktop interface to connect to a remote server and make changes on my PC would be beneficial.

An alerting system would be better as I need to check log files if any backend is down. Integrated Telegram alerts or WhatsApp or different channels would make it better.

HAProxy is very stable.

HAProxy's scalability is easy for me as I'm using it on dedicated servers with a cluster, but I haven't used it for Kubernetes or any other cloud platforms, so I cannot comment on that.

I was using NGINX before switching to HAProxy.

Setting up HAProxy didn't cost anything for me.

Setting up HAProxy didn't cost anything for me.

Before choosing HAProxy, I discussed it with ChatGPT, found it convenient, tried it, tested it, and it was fine, so I didn't bother to try anything else.

My advice to others looking into using HAProxy is to dive straight into it; there's nothing to lose and many things to gain. I would rate this product an 8.

We use the solution for load balancing.

The solution's implementation and troubleshooting are not easy. The solution's dashboards and reports could be improved.

I have been using HAProxy for 12 years.

We didn’t face any issues with the solution’s stability.

I rate the solution’s stability an eight out of ten.

HAProxy is a very good solution for small and medium sized businesses.

I rate the solution’s scalability an eight out of ten.

Since HAProxy is an open-source product, we did not receive support. However, there are some sites where we can receive support, and that support is not good.

Neutral

The solution’s initial setup is not easy.

HAProxy is an open-source solution.

F5 is HAProxy's main competitor in the market. If its implementation, dashboard, and reporting are improved, HAProxy could be better than F5.

If your team knows the product well, integrating HAProxy with IT workflow is easy. Otherwise, it is not easy. I would recommend the solution to other users.

Overall, I rate the solution a seven out of ten.

I use the tool mostly for small and quick load-balancing tasks. Additionally, I integrate it with Docker because the integration is quite fine.

What I like best about the product is its simplicity and speed. When you need to set up a load balancer quickly, HAProxy offers options like sticky sessions and round-robin. It's also fast to configure, including adding SSL for security. While it may have fewer options than other solutions like F5, HAProxy gets the job done for basic load-balancing tasks. 

The reliability features of HAProxy were particularly useful in a scenario where I needed to test load balancing between two Tomcats. Since these domains were inaccessible, I set up a third Docker with HAProxy, which had access to the Tomcat domains. I then configured HAProxy to handle the load balancing. This setup allowed the client to interact with HAProxy. 

The solution's integration with other elements is easy. 

Improving the documentation with multiple examples and scenarios would be beneficial. Most users encounter similar situations, so having a variety of scenarios readily available on the tool's website would be helpful. For instance, if I were part of the HAProxy team, I'd create a webpage with different scenarios and provide files for each scenario. This way, users wouldn't have to start from scratch every time. 

I have been using the product for six years. 

I rate the tool's stability a nine out of ten. 

I've only deployed a single instance and focused on monitoring it. 

I haven't had direct experience with their technical support team. Whenever I encounter issues, I usually turn to Stack Overflow. I've found that other users often have similar problems, and I can usually find solutions there.

The tool is open-source. 

I rate the overall product an eight out of ten. It is good and famous. 

I use the solution in my company for TCP streams. I have not used the product for web servers like Apache and NGINX. I have used the product for SMTP and SMPP protocols. I also used the tool for email services and POP3 servers. HAProxy handles the area where traffic has to be forwarded from one port to another very well.

HAProxy is very weak in the logging and monitoring part and requires improvement.

In the future, the tool should have additional modules for different purposes.

I have experience with HAProxy.

HAProxy's TCP load balancer is excellent and super stable.

I have not had the opportunity to use this scalability feature of the product, but I know that it depends on the machine or the hardware on which the tool is loaded. I would say that it is a scalable product since it is a software-based solution.

I can speak about the services being used on the product since there is no user interaction required with HAProxy. I can say that my company uses more than 50 services on HAProxy.

I use DNS Made Easy.

If a Linux user who is fairly good with Linux products takes care of HAProxy's installation part, it can be done easily.

It is possible to deploy the product within one to three hours with a fair amount of knowledge.

The product's deployment process is straightforward, as it can be easily managed with the help of HAProxy's document, which is available on its website. Users should be familiar with some Linux commands.

The solution is deployed on the cloud and on-premises models.

HAProxy is similar to engine NGINX, especially if you have a small company since you need only one or two people to take care of the deployment process. If you have a big enterprise, five to ten people are required to take care of the deployment phase.

HAProxy is preferable when the company wants a load balancer to manage the traffic and doesn't want to spend on a high-end load balancer. The product helps save costs for the company.

I use the open-source version of the product. I don't have experience with the licensed version of the solution.

I have used load balancing on the TCP layer. I have not used the product for areas like HTTP and HTTPS. I have not used the product for web or API applications. I have only used the product for the TCP part.

HAProxy improved our company's applications' availability. I had a use case in my company where we had to connect to one of my voice servers from a back-end proxy for which I had used HAProxy. HAProxy helped me when I had to distribute the traffic between all the voice servers from a single application in my company.

HAProxy's most valuable feature for network traffic management stems from the functionalities attached to the area revolving around TCP load balancers since it has helped me achieve excellent results.

To those who plan to use the product, I would say that they need to consider including the HTTP proxy part product, similar to the offerings made by NGINX. The product's potential users can introduce a lot of modules, which can help HAProxy when compared with NGINX.

I did not face any challenges with the integration capabilities of the product. My organizational objectives were achievable with HAProxy.

Considering the tool's TCP part, I rate the overall tool a seven out of ten.

For production purposes, we use HAProxy, which is a web application.

Our primary use case is load balancing.

We are not fully utilizing it. We are only responsible for load balancing. The most used and valuable is load balancing.

I can't speak to all of the HAProxy features because we don't use them all, but load balancing is very good.

Although HAProxy is essentially open-source, many features are not available.

While troubleshooting, we are having some difficulties. There are no issues when it is running; it is stable and very good; however, if there is a troubleshooting issue or an incident occurs, we will have issues because this is open-source.

We are only experiencing problems at that time. Otherwise, everything is fine.

Because we need to search for a document or some troubleshooting information. That could be beneficial to us.

To resolve the troubleshooting issues, additional documentation and troubleshooting are required.

The product is satisfactory. However, additional documentation, additional technical documents, and troubleshooting steps are the types of things that can only make this solution better. Also, more clarity on where the package is hitting and where it is stopping is needed.

I have been using HAProxy for four or five years.

HAProxy is generally stable. We had only two days of problems in the last five years, this was an extremely rare occurrence. We are back to being stable.

We have publicly permitted our web application for this, and approximately 5,000 users are using it.

It is used every day because it is our production-related order-lease domain or something along those lines. We are also using this as a dealer, with approximately 5,000 users per day.

Normal users. We will publish it on one of the websites that provide the production information. We provide the order and invoice the order to the product. These are the types of details. This is our dealership's publisher for an automotive dealership.

It is essentially the dealership's publisher.

HAProxy is scalable. There are plans to expand to the Japan team. They may suggest a paid tool.

I would rate their technical support a three out of five. Additional documents and troubleshooting should be made available on the internet.

There is no direct support. We use open-source software and do not rely on their support. We rely on our knowledge, and we are studying the implementation.

Previously, we were using F5. F5 is a very good product.

It's a great product that is also very stable and scalable, but it is very expensive in terms of price.

We switched to HAProxy because it is open-source.

We are also working with Zscaler and FortiGate.

The initial setup is easy.

I would rate the initial setup a three out of five.

We completed the installation in-house and did not use a third party.

HAProxy is free open-source software.

It will primarily be determined by the budget, the size of their company's budget, or if you have the budget. I would always recommend the F5. Because it has more clarity and more features are available in the F5, if budget is an issue, go with HAProxy. It's a good product.

If you are not utilizing very basic things that you should be using for the HAProxy.

Depending on the balance If the balance is very minimal, they should use HAProxy, an open-source solution, but if the balance is larger, such as an enterprise, they should use F5 BIG-IP Local Traffic.

I would rate HAProxy an eight out of ten.

The primary use case of this solution is to control the IP addresses accessing our devices and and blocking invalid requests to our back end servers.

It is much more flexible than a firewall since it gives you great logging and then control of what is let through to the WAF.

The ability to block constant requests for files that are not applicable to our VoIP deployment. We used to have a lot of 404s from our backend. Now they are blocked right up front.

The solution can be improved by controlling TCP behavior better rather than just reporting them in the logs. Automatic blocking of clients that don't properly close their TCP session (CH/CD) would be good.

I have been using the solution for three years.

The solution is stable.

The solution is easily scalable. If I were to run out of CPU space, or memory space, it would be very easy to just take my rules and virtualize them into VMware, and get a much more powerful solution. The other choice is to get another pair of servers and use the load-balancing functionality that comes with them to go between the two server environments.

The tech support is good however, there are sometimes delays in resolving issues because when there is a shift change there doesn't seem to be any communication between the support staff and we are constantly having to repeat our issues to the next person. The vendor follows the support around the globe approach that can lead to a lot of repetition and sometimes miscommunication.

Positive

The initial setup is straightforward and took about two weeks to implement.

The implementation was completed in-house with the help of vendor technical support.

The solution helps with customer retention each year.

The licensing fee for the entire WAF solution is very affordable with Loadbalancer.org. There are no separate charges for HAProxy and WAF.

I give the solution an eight out of ten.

We're a very small company of 400 employees, so there are only two of us in VoIP engineering who maintain all the equipment, which includes phones, Metaswitch, and LoadBalancer.org. The solution is maintained by one person taking only one hour a day to monitor the logs and apply new rules.

The solution is a layer seven device that allows your traffic to flow through. So if you are running any type of web interface for your customers, put a WAF in front of it that will allow you to limit the traffic that goes to the backend.