[tecleandor]

There's a lot of mentions to Caddy here. Haven't used it as, back in the day, there was something funny about its license and binary distribution. AFAIK that's not a problem anymore, isn't it?

From people that migrated from Traefik to Caddy... What are the main differences? Anything you really miss?

I use Traefik in a bunch of small deployments, sometimes pointing to Docker stuff, sometimes outside of Docker, Kubernetes, or anything similar.

[aborsy]

Caddy is dead simple. Like, send https://example.com to 1.2.3.4:5000. That’s it!

Certificate provisioning, TLS configs, TLS termination, mTLS and client certificates, sticking in middlewares, … are all simple. The config is a straightforward text file. Really good webserver!

Traefik is docker centric, and had various obscure labels. Too much text for a simple proxy. The debugging can be an issue if it doesn’t work. It also takes more resources. But it can probably do more, if you have a complex need.

My main issue with Traefik was the debugging.

[Ajedi32]

Does Caddy automatically detect when you deploy a new Docker service and reconfigure itself to route traffic to that service? That's pretty much the main value preposition of Traefik for me. I don't want to be messing with config files when I'm deploying.

[rirze]

Yes, there's [caddy-docker-proxy](https://github.com/lucaslorentz/caddy-docker-proxy) which I personally use in my homelab. It will read and update on docker compose labels to configure the route. Highly recommend.

[sph]

Caddy is a webserver like Apache or nginx. Integration with Docker is a higher-level layer. There’s caddy-docker-proxy but I haven’t tried it.

[Ajedi32]

Traefik is also a web server like Apache or Nginx and it does integrate with Docker. I thought that feature was like the entire reason to use Trafik, so I guess I just find the comparison a bit strange.

[jspdown]

Traefik maintainer here.

Traefik is a reverse proxy and load balancer that automatically discovers services and configures routing rules dynamically through integration with various configuration sources such as container orchestrators (Docker, K8s, Nomad, Consul, ECS, ...)

As of today, Traefik is not a web server.

[LtdJorge]

Traefik is a proxy first

[ajayvk]

I have been building an app deployment service https://github.com/openrundev/openrun.

For the use case of network routing for services running in containers, OpenRun provides a simpler abstraction. It does the container management and the network proxying.

[tecleandor]

Yeah, don't know exactly why, but when I've had problems, debugging Traefik has been kinda frustrating.

Also, I feel like they've slowly moved focus to Docker during the years, and I find the file based configuration more and more difficult (or worse documentation maybe) every time I go back to the docs.

Thanks for sharing!

[therein]

Maybe you're thinking of the drama involving Caddy putting sponsorships into its Server header. They walked that back relatively quickly and hasn't been a problem since then.

Back when they both were on the rise, they felt equivalent. I haven't deployed Traefik in a long time but as far as I remember, Traefik's configuration is more service-discovery oriented. While they both are capable of working with a static set of hosts, it felt like Traefik made it harder to configure for a static set of upstream servers while Caddy made it much easier. Traefik almost started off with the assumption that you would have some service discovery of some sort.

[jspdown]

Traefik maintainer here.

You are right, Traefik is fundamentally built around the concept of "providers," which are external systems from which Traefik obtains routing configuration and service/server definitions.

These providers can range from dynamic service discovery systems (like Docker, Kubernetes, Consul) to static configuration sources (file-based configs, HTTP APIs, etc.). The provider architecture is what makes Traefik particularly well-suited for containerized and cloud-native environments where services are ephemeral and discovery is crucial.

[tecleandor]

Ah, I didn't remember that. I've been googling a bit and I think this was it [0]: binaries on their download page or GitHub releases were only usable on a personal basis. If you were to use them in a company, even internally, you needed to get a commercial license or build the binary yourself.

That's not the case anymore.

--

  0: https://github.com/caddyserver/caddy/issues/2185#issuecomment-392470508

[justsomehnguy]

I found autoconfig in Docker (using labels) working better in Caddy+lucaslorentz.

It is still PITA (it's a nested JSON expressed as YAML) but it was easier for me than Traefik, somehow.

[baobun]

I guess one possible gotcha I can think of is, be prepared to build your own binaries/images if you aren't already. Some bread-and-butter features like L4 proxying depend on plugins and aren't part of the core package. It's good to self-build for other reasons, just sayin', distro versions or the official docker image will only get you so far.

Also iirc not all such functionality is actually available when configuring via Caddyfile so it can be confusing if you expect that and don't realize you need to switch to json/yaml configuration to do what you want. A little remniscient of the Traefik static/dynamic confusion ;)

All good, just things that can be different than what you are used to and expect.