The HAProxy configuration is just as simple as Caddy for a reverse proxy setup. It's also written in C which is a comparison the author makes between nginx and Caddy. And it seems to be available on every *nix OS.
In fact I use HAProxy in production pretty regularly because it is solid but its config one of the main reasons I would choose something else.
A basic HAProxy config is fine but it feels like after a little bit each line is just a collection of tokens in a random order that I have to sit and think about to parse.
- Do you want to add a header in this "location" block? Great, you better remember to re-apply all the security headers you've defined at a higher level (server block for instance) because of course adding a new header will reset those.
- Oh, you mixed prefix locations with exact location with regex locations. Great, let's see if you can figure out by which location block will a request end up being processed. The docs "clearly" explain what the priority rules for those are and they're easy to grasp [1].
- I see you used a hostname in a proxy_pass directive (e.g.: http://internal.thing.com). Great, I will resolve it at startup and never check again, because this is the most sensible thing to do of course.
- Oh... now you used a variable (e.g.: http://$internal_host). That fundamentally changes things (how?) so I'll respect the DNS's TTL now. Except you'll have to set up a DNS resolver in my config because I refuse to use the system's normal resolver because reasons.
- Here's an `if` directive for the configuration. It sounds extremely useful, doesn't it? Well.. "if is evil" [2] and you should NOT use it. There be dragons, you've been warned.
I could go on... but I think I've proved my point already. Note that these are not complaints, it's just me pointing out that nginx's configuration has its _very_ significant warts too.
[1] https://nginx.org/en/docs/http/ngx_http_core_module.html#loc...
[2] https://www.nginx.com/resources/wiki/start/topics/depth/ifis...
Unfortunately it's likely I worked in the same building as one of the people responsible for either creating or at least maintaining that mess, but I didn't know at the time that he needed an intervention.
Other than Caddy, Caddy has been great so far but I have only used it for personal projects.
Disclosure: Community contributor to HAProxy, I help maintain HAProxy's issue tracker.
I'm currently on a push to improve our docs, especially for beginners, so feel free to review the changes and leave your feedback: https://github.com/caddyserver/website/pull/263
I last setup a Caddy config maybe 6- 9 months ago, and everything related to client certificates was either scantily documented, wrongly documented, or not documented at all. It might be I got unlucky, as some of the client cert features were fairly new, but it wasn't a great experience.
Still, I much prefer Caddy's config system to Nginx or HAProxy.
Oh, something else I'd really love to see are more fully-featured example configs, as it can be hard to know how to start sometimes.
Generally we encourage examples in our community wiki though: https://caddy.community/c/wiki/13 -- much easier to maintain that way.
The problem with "fully-featured" examples is that people copy and paste instead of learn how the software works. I'd rather our user base be skilled crafting configuration.
Generally we recommend that big examples go into our wiki: https://caddy.community/c/wiki/13
Go's TLS stack is set to be more efficient and safer in coming versions thanks to continued work by Filippo and team.
I'm keeping a watching brief on https://github.com/darkweak/souin and its Caddy integration to see if that can step up and replace Varnish for short-lived dynamic caching of web applications. Though I've lost track of its current status.
Does HAProxy have built in support for Let’s Encrypt?
That is one of my favorite features. Caddy just automatically manages the certificates for https.
sub.domain.com {
# transparent proxy + websocket support + letsencrypt TLS
reverse_proxy 127.0.0.1:2345
}
caddy reverse-proxy --from sub.domain.com --to :2345
Where and how parameters are configured is a bit more of a wild card and dependent on the environment you are running in.
See this issue and especially the comment from Lukas Tribus: https://github.com/haproxy/haproxy/issues/1864
Disclosure: Community contributor to HAProxy, I help maintain HAProxy's issue tracker.
> Disks accesses can be unpredictably slow and would block the entire thread which is not something you want when handling hundreds of thousands of requests per second.
This is not something I see mentioned in the issue, but I don't see why disk accesses need to block requests, or why they have to occur in the same thread as requests?
> I wonder if a disk-writing process could be spun out before dropping privileges?
I mean … it sure can and that appears the plan based on the last comment in that issue. However the “no disk access” policy is also useful for security. HAProxy can chroot itself to an empty directory to reduce the blast radius and that is done in the default configuration on at least Debian.
> but I don't see why disk accesses need to block requests
My understanding is that historically Linux disk IO was inherently blocking. A non-blocking interface (io_uring) only became available fairly recently: https://stackoverflow.com/a/57451551/782822. And even then it's a operating system specific interface. For the BSD's you need a different solution.
If your process is blocked for even one millisecond when handling two million of requests per second (https://www.haproxy.com/de/blog/haproxy-forwards-over-2-mill...) then you drop 2k requests or increase latency.
> or why they have to occur in the same thread as requests?
“have” is a strong word, of course nothing “has” to be. One thing to keep in mind is that HAProxy is 20 years old and apart from possibly doing Let's Encrypt there was no real need for it to have disk access. HAProxy is a reverse proxy / load balancer, not a web server.
Inter-thread communication comes with its own set of challenges and building something reliable for a narrow use case is not necessarily worth it, because you likely need to sacrifice something else.
As an example at scale you can't even let your operating system schedule out one of the worker threads to schedule in the “disk writer” thread, because that will effectively result in a reduced processing capacity for some fractions of a second which will result in dropped requests or increased latency. This becomes even worse if the worker holds an important lock.
haproxy started out as a proxy and has gained some web server abilities, but is all about proxying.
haproxy has less surprises as a reverse proxy than nginx does. Some of the defaults for nginx are appropriate for web serving, but not proxying.