The one that wins
HAProxy ALOHA scores highest, and we say so
140 stars out of 195 against our 138. It is a well built appliance on a genuinely excellent engine, and on the totals it comes first. This page is what that two star gap is actually made of.
Rows where ALOHA scores higher
15
Rows where we score higher
16
Level
8
Where HAProxy ALOHA is better
Mostly the things an appliance vendor has spent years on: a support contract, in process features that cannot be faked from outside, and a runtime API that changes backends without reloading.
| Capability | ALOHA | Us | Why |
|---|---|---|---|
| Somebody to call | 5 / 5 | 0 / 5 | Both appliance vendors sell support with the box and both are well regarded for it. Kemp runs tiers, with 24x7 premium cover on the higher plans. HAProxy do not run tiers at all: your ticket goes straight to an engineer, and the enterprise subscription carries a thirty minute target on a critical issue. We have nothing, and adding two more columns has only made that clearer. |
| Sticky sessions | 5 / 5 | 3 / 5 | A row we lose to everybody, and it is worth saying so twice. Kemp has a long list of persistence methods including its own inserted cookie. HAProxy inserts its own cookie and keeps stick tables that can key on almost anything and are shared across the cluster. Three of the four issue their own cookie; we do not. |
| Slow start after recovery | 5 / 5 | 4 / 5 | HAProxy has a per server slowstart setting that ramps inside the process, which is as good as this gets. Kemp throttles connections per second to a recovered server and grows the limit over a window, which is the same idea, but the setting is global and only applies to the least connection schedulers. |
| Request queueing | 5 / 5 | 1 / 5 | This is one of the best things HAProxy does and ALOHA gets all of it: a per server connection limit, a real queue in front of it, a queue timeout, and the queue depth on the stats page so you can see it filling. It is the clearest single win against us on the page. Kemp rate limits a real server and takes it out of rotation when the limit is hit, which protects the server without holding the request. |
| Active health checks | 5 / 5 | 4 / 5 | Both appliances check from inside the data path and take a server out without rewriting anything, which is the right way round. Kemp has a long list of check types built for the applications it is usually put in front of. Ours keeps the two habits above, and those are worth something, but not enough to move this row. |
| Web application firewall | 5 / 5 | 4 / 5 | ALOHA has the best WAF on this page and we should say so. It carries its own engine rather than plain rule matching, supports OWASP CRS 4, lets you build named WAF profiles and apply a different one per application, and sells a bot module and a threat detection engine beside it. It also has a non blocking learning mode for exactly this job, and publishes a false positive rate at paranoia 2 far below plain ModSecurity, which is the number that decides whether anybody leaves a WAF switched on. Kemp runs the same ModSecurity and OWASP rules we do, adds a paid feed for IP reputation and web shells, and has block and log only modes with a tuning screen that lists the false positives it recorded and writes exclusions from them, including excluding one rule against one parameter. So learning is not the differentiator; all three learn. The differentiator is that theirs learn from whatever arrived and ours only learns from addresses somebody named in advance. That is one design decision, not a category, and it is the only part of this row worth claiming. Both appliances need the higher tier before the WAF turns on at all, which is a cost their star does not show. |
| JWT validation at the proxy | 4 / 5 | 2 / 5 | HAProxy can verify a signed token in its own configuration language, so ALOHA gets this without a helper service. Kemp reaches the same end through its authentication pack, which is built around signing users in rather than checking a token an API client already holds. |
| OIDC sign in for proxied applications | 4 / 5 | 1 / 5 | This is the row Kemp wins outright, and it is the reason a lot of people buy one. The Edge Security Pack puts a login in front of any application it publishes, against Active Directory, LDAP, RADIUS, SAML or OIDC, and carries the session across every service on the box. ALOHA does Kerberos and SAML sign on. We do none of it for proxied traffic and there is no honest way to dress that up. |
| Live activity monitoring | 5 / 5 | 3 / 5 | The HAProxy stats page is the reference for this and ALOHA carries it: sessions in flight, queue depth, per server error counts, all of it live and all of it from inside the process. Kemp shows live counters per service in its interface. Both beat us and the reason is the same as with Plus: they are the proxy, and we are a manager standing next to one. |
| Changing upstreams without a reload | 5 / 5 | 3 / 5 | Both appliances add, drain and remove servers live over an API with nothing restarted, and both have done for years. This is a row we lose to all three, and the reason is structural: they own the process, we edit its config file. |
| Where the nginx binary comes from | 5 / 5 | 3 / 5 | Both appliances ship a signed firmware image the vendor tested, which is the whole point of buying an appliance. We lose this row to all three and it is the honest cost of choosing our own modules. The other side of that coin is the post quantum row above, which we only win because we build our own. |
| DNS based failover between sites | 4 / 5 | 3 / 5 | Kemp is the best on this page by a distance. Their GSLB steers on the client's country, continent, address range or actual distance in degrees, weighs the live load at each site, and can refuse addresses with a bad reputation. ALOHA has a solid GSLB module and added health checks over HTTPS so it can probe a site properly rather than guessing from a port being open. Both need the paid tier. |
| NTLM connection pinning | 4 / 5 | 0 / 5 | HAProxy handles this by never reusing a backend connection for a different client, which is a documented setting and does the job at some cost in connections, so ALOHA gets a four. Kemp publishes plenty about signing users in against Windows and much less about pinning the connection itself, so this is a 2 covering what we could confirm. |
| MQTT preread and filtering | 4 / 5 | 0 / 5 | Not Plus only after all, which is what happens when you widen a comparison. HAProxy can read MQTT fields and route on them, so ALOHA does this. Kemp does not. |
| Runtime key value store | 5 / 5 | 1 / 5 | ALOHA is the best of the four. HAProxy stick tables hold counters and state that survive a reload and replicate between peers, and map files can be edited live over the runtime socket, which is exactly the live blocklist people want this for. For Kemp we could confirm nothing equivalent either way, so that is a 1 meaning we do not know rather than a 0 meaning it is absent. |
Where we are better
Mostly the management layer: certificates, the browser interface, cluster wide config safety, and two things nobody else does at all.
| Capability | ALOHA | Us | Why |
|---|---|---|---|
| Post quantum key exchange | 4 / 5 | 5 / 5 | Harvest now, decrypt later is the reason this matters before anybody has a quantum computer: traffic captured today is decrypted whenever one arrives. We build against OpenSSL 3.5, so X25519MLKEM768 is there, and the shipped TLS snippet offers it first with classic curves behind it, so a site gets it without anybody knowing to ask. F5 have been adding this to recent releases, so the honest gap is not whether Plus can but whether the build you have does and whether somebody configured the groups. Building our own TLS stack is a cost in every other row and it buys this one. |
| Certificate lifecycle, end to end | 2 / 5 | 5 / 5 | nginx has gained a native ACME module, and it issues certificates. What is rated here is the rest of the job: issuing from whichever node owns the address, replicating to the others, renewing on a schedule, staging first, DNS-01 where HTTP-01 will not do, and degrading to the old certificate rather than freezing the fleet when something goes wrong. |
| Certificates from a paid authority | 2 / 5 | 5 / 5 | Neither product is a certificate manager, but we became one: authorities are profiles with their own credentials, several can be in use at once, and a certificate renews from the authority that issued it rather than quietly from somewhere else in sixty days. |
| Least time balancing | 3 / 5 | 4 / 5 | Also understated until the code was read. Plus picks the fastest backend per request. We time every health check already, so a pool can be set to lean weights toward the quicker boxes, with two rails: weights move one step at a time between a floor and a ceiling so one slow check cannot pull a server out, and if everything is slow it leaves them alone, because that means the problem is downstream and shuffling weights would pile load onto whichever box is least broken. Four, not five: ours reacts per check interval, Plus per request. |
| Load balancer failover | 4 / 5 | 5 / 5 | Plus ships a keepalived package, which works and is configured in files on each box. Ours is built in: election with a quorum rule, a standby that refuses to promote itself when it cannot see a majority, and the whole thing visible on a page. The quorum rule is the part that matters, because the failure it prevents is two nodes both deciding they are active. |
| Config tested on every node before any node applies | 1 / 5 | 5 / 5 | The one we would keep if we could only keep one. A change is staged and tested on every node, and applied nowhere unless it passed everywhere. Plus has nothing here; Instance Manager, sold separately, can validate config, and that is still not the same as an all or nothing fleet apply. |
| Blocking by country | 4 / 5 | 5 / 5 | The geoip2 module is free for both. The work is the database: getting one, putting it on every node, and keeping it current, which we do from a page on a schedule. With Plus that is yours to arrange. |
| Admin accounts, roles, two factor, audit log | 3 / 5 | 5 / 5 | Plus has no administrative interface to secure, so this is not a gap in it so much as a thing it does not have. Ours has roles, TOTP, lockout, and an audit log with secrets scrubbed. Instance Manager is where F5 put this, separately. |
| CPU, memory and load over time | 2 / 5 | 5 / 5 | Plus reports on nginx; the box it runs on is somebody else's problem, and its dashboard is the present tense. We chart both load balancers on their own page and now keep it: one minute detail for 48 hours, five minute buckets for thirty days, and drag across any chart to zoom every chart to that range. This was four while the history was two hours in memory that went on restart, which was the whole of the reason, so it is five now that reason is gone. Every bucket keeps min, mean and max, because a five minute average alone is where a spike goes to die. Measured on a real fleet at 27 MB for four nodes across both tiers. |
| Backend CPU and memory | 1 / 5 | 3 / 5 | Neither product has an agent on your backends. We read a Prometheus endpoint if a pool is given one, and label an application exporter differently from a machine one, because a JVM at 100% of one core is not a busy box. |
| Managing the whole thing from a browser | 3 / 5 | 5 / 5 | This is the product. Plus is configured in files; its GUI is a statistics dashboard, and configuration through a browser is Instance Manager or NGINX One, sold separately. Everything here is a page, and the API exists because the page needed it. |
| Importing an nginx config you already have | 0 / 5 | 4 / 5 | We parse an existing config into sites, pools and settings, so adopting this does not start with retyping. Four because anything it cannot model is kept as raw config rather than quietly dropped, and you should read the result. |
| Reaching backends with no public address | 0 / 5 | 4 / 5 | A WireGuard tunnel a workload enrolls into with one command, so a machine behind NAT becomes a pool member without asking anybody for a firewall change. Neither nginx nor Plus does anything like this; it assumes the backend is already reachable. |
| Custom error pages | 3 / 5 | 4 / 5 | error_page is free in both, and then you are writing HTML and putting it on every node yourself. Ours are templates you point sites at, replicated with the config. |
| What is actually in the backup | 3 / 5 | 5 / 5 | The row that decides whether a backup is worth having. Ours holds everything the fleet is configured to do: sites, pools, certificates and their private keys, WAF profiles and the exclusions somebody spent an afternoon earning, accounts, access lists, error pages. Node names and cluster identity are deliberately left out, because they belong to the machines rather than to the configuration. The file is encrypted with AES-256, and the honest caveat is that the password is the operator's login password through PBKDF2 at 1000 iterations, which is not a lot: treat the file as the bag of private keys it is. |
| Restoring, and rebuilding somewhere else | 2 / 5 | 4 / 5 | Ours rebuilds a fleet that has nothing in common with the old one: different addresses, different node names, different hardware. Secrets are unsealed on the way out and sealed again with the new fleet's own key, because the key that protects them here does not exist there. Four and not five because it is all or nothing. You cannot restore only the pools, and the one thing deliberately left behind is the management network list, since restoring it is a fine way to lock yourself out of the system you are in the middle of rebuilding. |
What the difference costs
HAProxy publish no list price. Trackers put HAProxy Enterprise, the engine inside ALOHA, at roughly $995 to $5,000 per instance per year across the Basic, Standard and Premium tiers. ALOHA itself is quoted by appliance model and throughput, so a physical unit lands above that range, and hardware costs extra.
Support is included and is not tiered by who answers, which is genuinely unusual. Your ticket goes straight to an engineer, and the enterprise subscription carries a thirty minute target on a critical issue. That is worth real money and it is the row we lose worst.
HAProxy community edition, which is most of the engine, costs nothing. If what you want is a free HAProxy rather than a free nginx, that is a perfectly good answer and this project is not trying to talk you out of it.
The honest summary
Choose ALOHA if
- You need somebody contractually obliged to answer, quickly.
- You want an appliance rather than software you install and own.
- You need a request queue, or reload free backend changes at a rate that matters.
- Buying hardware is easier for you than owning a build process.
Choose this if
- You have no budget, and that is the actual constraint.
- You want certificates handled end to end across a cluster without thinking about it.
- You have backends with no public address and no route to getting one.
- You are already on nginx and want to keep the config you have.
HAProxy and ALOHA are trademarks of HAProxy Technologies. This page names them only to say what those products do. Scores were taken in August 2026 from published documentation, release notes and datasheets, and are our reading of what was published that day.