When I first set up my web server I don't think Caddy was really a sensible choice. It was still immature (The big "version 2" rewrite was in beta). But it's about five years from when that happened, so I decided to give Caddy a try.
Wow! My config shrank to about 25% from what it was with Nginx. It's also a lot less stuff to deal with, especially from a personal hosting perspective. As much as I like self-hosting, I'm not like "into" configuring web servers. Caddy made this very easy.
I thought the automatic HTTPS feature was overrated until I used it. The fact is it works effortlessly. I do not need to add paths to certificate files in my config anymore. That's great. But what's even better is I do not need to bother with my server notes to once again figure out how to correctly use Certbot when I want to create new certs for subdomains, since Caddy will do it automatically.
I've been annoyed with my Nginx config for a while, and kept wishing to find the motivation to streamline it. It started simple, but as I added things to it over the years the complexity in the config file blossomed. But the thing that tipped me over to trying Caddy was seeing the difference between the Nginx and Caddy configurations necessary for Jellyfin. Seriously. Look at what's necessary for Nginx.
https://jellyfin.org/docs/general/networking/nginx/#https-config-example
In Caddy that became
jellyfin.example.com {
reverse_proxy internal.jellyfin.host:8096
}
I thought no way this would work. But it did. First try. So, consider this a field report from a happy Caddy convert, and if you're not using it yet for self-hosting maybe it can simplify things for you, too. It made me happy enough to write about it.
@GnuLinuxDude Since I'm a fan of Caddy I'll add in one little trick I recently found.
I have a use case where I might get requests in the first few seconds, while the reverse-proxied application is still starting up. Caddy actually has a load balancer built in. It's a bit overkill for the use case but it works:
https://caddyserver.com/docs/caddyfile/directives/reverse_proxy#load-balancing
Just make sure to set both lb_try_duration and lb_retries (seems redundant but whatever) and your early requests will wait until the app starts!
Do you have an example use-case? I don't think I've ever needed to wait for something to start, as anything that's reverse proxied is already running.
Perhaps it's super niche. I'm packaging apps for something called Sandstorm (https://sandstorm.org) which has a unique model. The apps are small and run in containers. They're asleep after a period of inactivity. You want to be able to click on your app and see something useful load on your browser, even if it has to take a couple seconds to wake up.
Sometimes our apps include Nginx/Caddy/etc with a reverse-proxy. Caddy can start faster than the app so it's nice that Caddy can wait for it.