traefik VS Caddy

Compare traefik vs Caddy and see what are their differences.

Our great sponsors
  • Scout APM - A developer's best friend. Try free for 14-days
  • Nanos - Run Linux Software Faster and Safer than Linux with Unikernels
  • SaaSHub - Software Alternatives and Reviews
traefik Caddy
67 127
35,850 35,577
1.0% 1.5%
9.3 9.2
5 days ago 6 days ago
Go Go
MIT License Apache License 2.0
The number of mentions indicates the total number of mentions that we've tracked plus the number of user suggested alternatives.
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.


Posts with mentions or reviews of traefik. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2021-11-26.


Posts with mentions or reviews of Caddy. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2021-12-04.
  • How Do Webservers Stay Safe From Hackers?
    2 projects | | 4 Dec 2021
    I've started to use a web server called caddy. You should check it out; it's awesome. Configuration is so much simpler, and it has a lot of other advantages also! Built-in lets-encrypt handling -- you don't even have to do anything (other than setup DNS "A" and/or "AAAA" record!)
  • Using Nginx as an Object Storage Gateway
    3 projects | | 2 Dec 2021
    Have you tried Caddy server? No affiliation just a happy user. It’s open source.

    It may or may not be able to replace Nginx depending on your use case. For me Caddy has replaced everything I used Nginx for and more.

  • Caddy – The Ultimate Server with Automatic HTTPS
    1 project | | 29 Nov 2021
    1 project | | 29 Nov 2021
    7 projects | | 29 Nov 2021
    In case you missed it:

    Those issues are a thing of the past. There's no use bringing it up again, tbh.

    > like acting as a cache

    That's fair, we have a WIP cache module here, it should be ready soon!

    7 projects | | 29 Nov 2021
    In my eyes, Caddy is a lovely web server that works pretty well as ingress for container clusters (e.g. Nomad, Docker Swarm etc.). That said, i can't help but to feel that v1 was easier and in some ways nicer to use than v2, even though it's abandoned at this point.

    That said, i have certain grievances with most of the web servers out there.

    Apache2/httpd - actually decently usable even nowadays, but if the fragmentation of service names (httpd vs apache2, with additional scripts like a2enmod) between different distros doesn't hurt it, then the configuration format and how it does reverse proxying and path rewriting most certainly will. The performance is still passable, no matter what anyone says, my applications still have been the bottleneck in approx. 95% of the cases, though that might change with frameworks like Vert.X or such. The further down you scroll, the less user friendly it becomes:

    Nginx - recently migrated my ingress to it at work, seems pretty okay so far, the configuration format seems to make a bit more sense and probably lies somewhere between Apache and Caddy as far as its ease of use and pleasantness goes. I no longer even need rewrite rules to get websockets working properly, which is nice. And my containers can have all of the necessary config in a single file vs the unnecessary boilerplate fragmentation that httpd forces upon me. For example, both of these seem more passable to me when compared to Apache2: and

    Currently, my biggest gripe is that Nginx kills itself when it cannot resolve an upstream host, for example, while Docker containers are still starting, their health checks haven't passed and therefore their DNS records also haven't been created: The worst part is that none of the suggested answers actually work for me, so i can't have a single Nginx instance be in front of the development environment with about 20 containers, a few of those being down when Nginx is being restarted will not let many of them be used until the startup finishes. Unacceptable.

    Caddy - as stated before, i liked v1 more than v2, though the project itself is pretty close to as good as a web server might get. What i don't enjoy is them taking the old docs offline, merely letting you download an archive, nor am i a fan of the current docs, since at the current point in time they are a bit like running "tar --usage":

    It's nice that there are a few examples for the common use cases, but there probably could be even more, just look at what the PHP documentation has at the bottom for a good example: (crowd sourced, but i like the idea of letting the community contribute useful information like that).

    Apart from that, some of the behavior is weird and you will get a 200 when you'd expect to get a 502/404 in most other web servers: which will sometimes be misleading ("Huh, i'm not getting any data in the response to my request, even though the status is 200 in my log, weird...")

    Also, i remember when v1 had this "fail-fast" habit of shutting down the entire server when renewing/obtaining a certificate failed, something that i utterly hate when web servers do: Admittedly, things are a bit better now: I just don't understand why web servers can be so opinionated about these things and not provide something like "failure_action" in Docker Compose ( so that people can choose between either stopping everything as soon as problems manifest, or continuing with a "best effort" strategy.

    If i'm hosting 100 sites behind a reverse proxy, i don't want 99 to be taken down just because 1 of them was misconfigured, the web server should be able to throw out a warning about that one host if i tell it to, and proceed to run the rest 99 as instructed. When no web server forces me to cope with such brittleness will be a good day.

    7 projects | | 29 Nov 2021
    It wasn't a security incident, actually. It's true that "a GitHub bug caused it". It wasn't malicious.

    TLDR, a contributor made a tag on their own fork of Caddy, and for some reason our next release used their tag, because it turns out forks in GitHub aren't actual separate repos, but rather "still technically the same repo". It's really strange.

    All that happened is that the v2.2.1 release wasn't properly signed with Matt's signing key. There was no problem with the code at all.

    We've put in place checks during our CI actions to ensure that releases are always verified to be signed by Matt's key. See

    7 projects | | 29 Nov 2021
    On the Caddy website ( it says:

    > Caddy is both a flexible, efficient static file server and a powerful, scalable reverse proxy.

    > LIGHTWEIGHT For all its features, Caddy runs lightly and efficiently with relatively low memory footprint and high throughput.

    > STATIC FILES By default, Caddy will serve static files in the current working directory. It's so brilliantly simple and works fast.

    > Caddy's HTTP server has a wide array of modern features, high performance, and is easy to deploy.

    Emphasis with the italics being mine. All of these seem to hint at performance comparaisons being done in specific domains agaisnt other web servers. For example:

    - efficient static file server: I would assume that "efficient" here is compared to other file servers, though that could mean also that it doesn't use much resources

    - For all its features, Caddy runs lightly and efficiently with relatively low memory footprint and high throughput: That seem to imply that other servers with all these features are heavier and less efficient? Or that other servers just don't have those features? Relatively low memory footprint and high throughput? Relative to what?

    - It's so brilliantly simple and works fast: What does fast mean here? Fast relative to what? Apache? The standard Go static file server? Python SimpleHTTPServer?

    - high performance: High compared to what?

    My goal here isn't to be confrontational. My point is that if there are all those claims on the main page of Caddy, then you must at some point have measured performance, resource usage and things like that against other servers. I think what people are asking is to substantiate those claims with data. You're right that it's hard to generate data in a way that applies perfectly to everyone use case. But then on what do you base all these claims? Why is Caddy called "the ultimate server"? At least that's why I'm wondering.

    7 projects | | 29 Nov 2021
  • Geofence your self-hosted API's
    6 projects | | 27 Nov 2021
    Caddy is an awesome web server alternative to nginx and apache (httpd). Caddy is written in Go, is a much more performant and extensible web server (in my opinion). With Caddy, you can host basic files or reverse proxy your API's, which is how I use it. I use Caddy because of its automatic TLS functionality so I don't have to worry about manual creation of certificates and keys.

What are some alternatives?

When comparing traefik and Caddy you can also consider the following projects:

Nginx Proxy Manager - Docker container for managing Nginx proxy hosts with a simple, powerful interface

HAProxy - HAProxy documentation

envoy - Cloud-native high-performance edge/middle/service proxy

Nginx - An official read-only mirror of which is updated hourly. Pull requests on GitHub cannot be accepted and will be automatically closed. The proper way to submit changes to nginx is via the nginx development mailing list, see

Squid - Squid Web Proxy Cache

cockpit-podman - Cockpit UI for podman containers


gobetween - :cloud: Modern & minimalistic load balancer for the Сloud era

consul - Consul is a distributed, highly available, and data center aware solution to connect and configure applications across dynamic, distributed infrastructure.

socks5-proxy-server - SOCKS5 proxy server

tailscale - The easiest, most secure way to use WireGuard and 2FA.