Hacker News Reader

Comment by iansinnott | Hacker News Reader

> Traefik is more comparable to HAProxy than to nginx/caddy/apache2

Aren't caddy and traefik fairly comparable? I've only used them both lightly so I may be missing the core point of each, but I thought of them as very similar.

View on HN

Traefik can't serve static files, or interact with CGI providers like PHP.

The rest of the sentence you quoted explains that nginx, Caddy, and Apache are all webservers (which can also reverse proxy). Traefik and HAproxy are only reverse proxies and not webservers.

HAProxy can be a web server though, albeit it is not designed to operate this way and thus requires some goofy configuration to make happen. I only know this because it was useful for me while working on a HAProxy extension.

Caddy is primarily a web server like nginx and apache httpd. Traefik and HAproxy are primarily reverse proxies.

Caddy is actually used as a reverse proxy more than a static file server. It's equally excellent and proficient as both! Caddy's functionality is comparable to nginx, apache httpd, and haproxy.

And while we’re at it, it can even forward proxy recentlyish I believe?

Yeah, Caddy v1 had a forwardproxy plugin that finally got updated for v2: https://github.com/caddyserver/forwardproxy/

Caddy is at the same level as nginx/apache. It is able to do everything a web server is expected to (serving web sites, files and proxying services) plus handling LetsEncrypt automatically. It does not, afaik, do dynamic service discovery like traefik nor load balancing of TCP at the protocol layer, like e.g. haproxy. https://caddyserver.com/features

Just to add on, haproxy does service discovery too.

https://www.haproxy.com/blog/consul-service-discovery-for-ha...

Caddy can absolutely do both of those things.

- https://caddyserver.com/docs/modules/http.reverse_proxy.upst...

- https://github.com/mholt/caddy-l4

We are long-time fans of Caddy, preferring it over traefik + nginx especially for our docker-compose flows.. though it's fair to distinguish 'can' vs 'easy to do'

E.g., we can imagine writing or using a plugin to figure out some upcoming fancy sticky session routing logic based on routes/content vs just the user IP, but there are easier and more 'with the grain' solutions than with what Caddy exposes today, afaict

(Agreed tho: The reverse proxy module, for more typical cases, is awesome and we have been enjoying for years!)

Sticky sessions are supported: https://caddyserver.com/docs/caddyfile/directives/reverse_pr..., and yes it's pluggable so you could write your own LB policy. Very easy, just copy the code from Caddy's source to write your own plugin. Let us know if you need help.

Also yes, Caddy does service discovery if you use https://github.com/lucaslorentz/caddy-docker-proxy, configuration via Docker labels. Or you can use dynamic upstreams (built-in) https://caddyserver.com/docs/caddyfile/directives/reverse_pr... to use A/AAAA or SRV DNS records to load your list of upstreams.

`query [key] ` A+++, I missed when this got added, amazing!

(this basically solves the sticky shared chatroom websocket problem for us when routing to resources with gravity, in our case, multiuser data science notebooks!)

caddy-l4 still shows:

     This app is very capable and flexible, but is still in development. Please expect breaking changes.

And it does not seem to be really seeing many new commits recently, so it feels pretty much "beta" at this point.

Reply on news.ycombinator.com