3 ms·
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 probl
by therein 1y ago
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.
- tecleandor 1y agoAh, 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
- jspdown 1y agoTraefik 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.