We come second out of four, and we publish it anyway

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.

All four do this and all four do it well. Kemp adds resource based and fixed weighting on top; ALOHA has both the HAProxy algorithms at layer 7 and the LVS ones at layer 4, including maglev hashing. Nobody wins a row like this.

Neither appliance balances on response time as such. Kemp has resource based scheduling, which asks each real server for a number describing how loaded it is, so the server has to be told to publish one. HAProxy has no least time algorithm at all; least connections is the usual stand in and it is a good one. Three each for doing the job by a different route.

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.

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.

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.

Both appliances do layer 4 properly. ALOHA runs LVS alongside HAProxy, so it also does direct server return, where the reply skips the load balancer entirely. Neither we nor Plus can do that.

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.

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.

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.

Both appliances ship the location database as part of the firmware, which is a tidy answer: nothing to download and nothing to schedule. Kemp aims its location features at steering traffic to the nearest site more than at shutting a country out, and does both. Four each, and the half step we keep is that our database updates on its own schedule rather than waiting for a firmware release.

Both appliances have address lists and both let you attach one to a published service. ALOHA writes them as HAProxy rules, which can match on nearly anything. Five all round, for the same reason as above: this is a capability every serious product has, and the difference is in the shape of the screen, not in what the traffic sees.

Both appliances have this because both are things you log in to. Kemp has user accounts with permissions, change auditing, and can hand sign in off to your directory. ALOHA has accounts on its interface but publishes less about roles and audit trails, so it scores lower on what we could read rather than on anything we found missing.

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.

Kemp matches us and should: the web interface is the product there too, everything is a form, and it has been polished for longer than this project has existed. ALOHA has a real interface with a setup wizard, but a lot of the layer 7 work still comes down to editing HAProxy configuration text in a box in the browser, which is a file with a nicer background.

Neither appliance reads an nginx config, and there is no reason either would: they are not nginx. Moving to one means building your services again in their model, by hand or by script. That is a real cost and it lands on the week you migrate.

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.

No load balancer on this page does this, because a load balancer assumes it can already reach the servers. If your backends sit behind NAT you are buying a VPN alongside any of the other three and wiring the two together yourself.

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.

Both appliances let you upload a page and attach it to a service. The step we keep is that ours are templates several sites share and the fleet replicates, so fixing a typo is one edit rather than one edit per box.

ALOHA has carried HTTP/3 since version 15 and has been tuning it ever since, with QUIC memory limits, a switch to turn it off per listener, and experimental HTTP/3 out to the backend in version 18. It is the most mature QUIC on this page. For Kemp we could find nothing published, so this is a 1 meaning we do not know rather than a 0 meaning it is absent.

Neither appliance packages video either. This is a row Plus wins against everybody, and it is the clearest example on the page of why a star total is a poor way to choose: if you need this, three of the four products are simply out.

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.

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.

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.