Caddy is a wonderful alternative for nginx for small / medium sized projects I've worked with it on. Mid market enterprise is where I have seen alot of Caddy uptick as of late.
nginx has a ton of inertia, but Caddy is a welcome player. I highly recommend anyone into this sort of thing give it a try. The configuration is so easy by comparison and its handling of HTTPS certs automatically is a huge win.
I feel its a leap forward from the typical Apache / nginx setup to me nowadays
I've used Caddy in the past and it worked well but the syntax for their config caddyfile is just so confusing. I haven't found a tutorial to explain how it all works properly.
Caddy is indeed wonderful for straightforward and simple projects.
There are a number of complex configurations used by larger organizations that are well served today by Nginx Plus, HAProxy, and Traefik that don't seem possible with Caddy. And it's difficult to get a sense of whether the Caddy developers are interested in meeting those more complex use cases or whether they want to keep Caddy smaller and simpler.
But yes, by all means, for a simple project pick Caddy!
> welcome to 2024. it is shame that traefik cannot handle functionality which can be handled by caddy2.
(posted this morning)
Anyway, we already do walk up to quite a few complex requirements in large enterprise deployments. Happy to hear about your use case that isn't possible!
I've tried to use Caddy several times (once before the config lang changed and once after). Configuration was a nightmare, mainly because it doesn't throw on what should be bad configs and things just don't work as expected.
I don't think that's as true anymore. We've put a lot of effort on adding errors/warnings on bad config. But it's hard to imagine all the "wrong" ways users can try to configure Caddy. If there's something you don't find obvious, please ask us for help on our forums, or open an issue on GitHub if you think it's a bug. Feedback is extremely important for us to be able to improve!
I love caddy. Most recently, I used it for a small personal project where I wanted to be able to upload files via Webdav and serve them out over HTTPS. I can't believe how small the configuration for this setup is. Especially if you compare it to something like Apache:
```
{
order webdav before file_server
log {
level DEBUG
}
}
files.example.org {
log {
output stdout
format json
}
@notget {
not method GET
}
root * /srv/ssftp
route @notget {
basicauth {
bob $2y$10$f/asdasd.asdsadasd.asdasdasd
}
webdav
}
file_server browse
}
```
The integrated LetsEncrypt support makes life so much easier than a comparable setup with apache or nginx.
Caddy is great and it's configuration is such a breath of fresh air compared to other web servers. As a little self plug I wrote about some cool things you can do with only using caddy config https://jarv.org/posts/cool-caddy-config-tricks/
I’m so confused by these things, setting up a Linux box with nginx isn’t that hard. It takes maybe a day to do, and while doing it you really understand better how your server works. The first time might take you 5 days to go through some tutorials, but generally after that it’s less than 1 day of work.
For me personally I really want to know what is going on in each folder and keep track of new folders, files etc. It’s maybe my paranoia of hacking. Context; when I was a kid I hacked so many things and knowing where the files are kept and hiding them is a key part of hacking. Therefore it’s always been a priority for me to check in regularly see what’s happening.
The main benefit for me is the integrated SSL certificate generation without needing to configure separate certificate infrastructure or Letsencrypt/acme. Also, Caddy implements a number of best practices by default without needing to specifically configure them, e.g. redirecting HTTP to HTTPS.
I do still manage a couple of fairly complex Nginx configurations, and I don't really see any benefit to retrofitting Caddy into that kind of scenario. But for a new deployment, I'll almost always reach for Caddy in the first instance.
Seems unnecessary to me - I would only consider running Caddy in Docker if the web application it was serving was also in Docker. Installing Caddy without Docker is pretty straight-forward - I have a basic Ansible playbook that does this with just 5 tasks.
Yep, I agree, only need to run Caddy in Docker if you're planning to use Docker for things Caddy will serve.
Our docs cover many installation methods, most commonly used is our apt or rpm repos, which run Caddy as a systemd service. See https://caddyserver.com/docs/install
Oke thing I really like about caddy is that it's super easy to use it to expose a bunch of docker-compose services to the Internet, with HTTPS, compression, and all that jazz. It helps avoid weird stuff I've ran into with other web servers like "oh, this nginx feature requires you import some random dudes packages because the official version doesn't enable it, and if the random dude and the official package versions ever diverge everything breaks"
I'm a beginner, but clearly too much of a beginner for this beginner guide. Went to it expecting a guide on how to set up a caddy webserver, spent most of the time reading about how to use docker. I just want to be able to set up a server to server html/CSS/JavaScript easily, and securely. Not edit yaml files and run containers locally.
Readit News
nginx has a ton of inertia, but Caddy is a welcome player. I highly recommend anyone into this sort of thing give it a try. The configuration is so easy by comparison and its handling of HTTPS certs automatically is a huge win.
I feel its a leap forward from the typical Apache / nginx setup to me nowadays
Anything in particular you find confusing?
There are a number of complex configurations used by larger organizations that are well served today by Nginx Plus, HAProxy, and Traefik that don't seem possible with Caddy. And it's difficult to get a sense of whether the Caddy developers are interested in meeting those more complex use cases or whether they want to keep Caddy smaller and simpler.
But yes, by all means, for a simple project pick Caddy!
> welcome to 2024. it is shame that traefik cannot handle functionality which can be handled by caddy2.
(posted this morning)
Anyway, we already do walk up to quite a few complex requirements in large enterprise deployments. Happy to hear about your use case that isn't possible!
Just want to say, it's great for large deployments too! (Ask Stripe and Framer)
```
```The integrated LetsEncrypt support makes life so much easier than a comparable setup with apache or nginx.
https://blog.tjll.net/reverse-proxy-hot-dog-eating-contest-c...
https://news.ycombinator.com/item?id=32865497
For me personally I really want to know what is going on in each folder and keep track of new folders, files etc. It’s maybe my paranoia of hacking. Context; when I was a kid I hacked so many things and knowing where the files are kept and hiding them is a key part of hacking. Therefore it’s always been a priority for me to check in regularly see what’s happening.
I do still manage a couple of fairly complex Nginx configurations, and I don't really see any benefit to retrofitting Caddy into that kind of scenario. But for a new deployment, I'll almost always reach for Caddy in the first instance.
> without needing to configure separate certificate infrastructure or Letsencrypt/acme.
is not only that your deployment is simpler, it also scales better and is more robust to failures. It can tolerate external factors more robustly.
Our docs cover many installation methods, most commonly used is our apt or rpm repos, which run Caddy as a systemd service. See https://caddyserver.com/docs/install
https://caddyserver.com/docs/quick-starts/static-files