| ▲ | elashri 3 days ago |
| What I really like about Caddy is their better syntax. I actually use nginx (via nginx proxy manager) and Traefik but recently I did one project with Caddy and found it very nice. I might get the time to change my selfhosted setup to use Caddy in the future but probably will go with something like pangolin [1] because it provides alternative to cloudflare tunnels too. [1] https://github.com/fosrl/pangolin |
|
| ▲ | kstrauser 2 days ago | parent | next [-] |
| I agree. That, and the sane defaults are almost always nearly perfect for me. Here is the entire configuration for a TLS-enabled HTTP/{1.1,2,3} static server: something.example.com {
root * /var/www/something.example.com
file_server
}
That's the whole thing. Here's the setup of a WordPress site with all the above, plus PHP, plus compression: php.example.com {
root * /var/www/wordpress
encode
php_fastcgi unix//run/php/php-version-fpm.sock
file_server
}
You can tune and tweak all the million other options too, of course, but you don't have to for most common use cases. It Just Works more than any similarly complex server I've ever been responsible for. |
| |
| ▲ | pgug 2 days ago | parent [-] | | I find the documentation for the syntax to be a bit lacking if you want to do anything that isn't very basic and how they want you to do it. For example, I want to use a wildcard certificate for my internal services to hide service names from certificate transparency logs, and I can't get the syntax working. Chatgpt and gemini also couldn't. | | |
| ▲ | dizhn 2 days ago | parent | next [-] | | This here is how it's done, where you have a wildcard dns entry for subdomains of secret.domain.com. {
acme_dns cloudflare oWN-HR__kxRoDhrixaQbI6M0uwS4bfXub4g4xia2
debug
} *.secret.domain.com { @sso host sso.secret.domain.com
handle @sso {
reverse_proxy 192.168.200.4:9000
}
@adguard host adguard.secret.domain.com
handle @adguard {
reverse_proxy 192.168.200.4:9000
}
@forge host forge.secret.domain.com
handle @forge {
reverse_proxy http://forgejo:3000
}
# respond to whatever doesn't match
handle {
respond "Wildcard subdomain does not have a web configuration!"
}
handle_errors {
respond "Error {err.status_code} {err.status_text}"
}
}
| | | |
| ▲ | cpach 2 days ago | parent | prev | next [-] | | This integration doesn’t support the dns-01 challenge. So wildcard certs are out of the question at this point. | | |
| ▲ | cpach 2 days ago | parent [-] | | PS. Oh, this subthread is about Caddy, not Nginx. Nevermind my comment then! |
| |
| ▲ | nadanke 2 days ago | parent | prev [-] | | For wildcards you need a Caddy build that includes the dns plugin for your specific provider. There's a tool called xcaddy that helps with that. It's still kinda annoying because now you need to manage the binary for yourself but when I tried it with Hetzner it worked fine. | | |
| ▲ | snickerdoodle12 2 days ago | parent [-] | | In case it helps someone else, this is what I do: FROM caddy:2-builder AS builder
RUN xcaddy build \
--with github.com/caddy-dns/cloudflare \
--with github.com/greenpau/caddy-security
FROM caddy:2
COPY --from=builder /usr/bin/caddy /usr/bin/caddy
COPY Caddyfile /etc/caddy/Caddyfile
Then just build & run it via docker compose |
|
|
|
|
| ▲ | Saris 2 days ago | parent | prev | next [-] |
| Caddy does have some bizarre limitations I've run into, particularly logging with different permissions when it writes the file, so other processes like promtail can read the logs. With Caddy you cannot change them, it always writes with very restrictive permissions. I find their docs also really hard to deal with, trying to figure out something that would be super simple on Nginx can be really difficult on Caddy, if it's outside the scope of 'normal stuff' The other thing I really don't like is if you install via a package manager to get automated updates, you don't get any of the plugins. If you want plugins you have to build it yourself or use their build service, and you don't get automatic updates. |
| |
| ▲ | francislavoie 2 days ago | parent | next [-] | | Actually, you can set the permissions for log files now. See https://caddyserver.com/docs/caddyfile/directives/log#file | | |
| ▲ | Saris 2 days ago | parent [-] | | Oh good to know! Do you know if Caddy can self update or if is there some other easy method? Manually doing it to get the cloudflare plugin is a pain. | | |
| ▲ | francislavoie 2 days ago | parent | next [-] | | No, you have to build Caddy with plugins. We provide xcaddy to make it easy. Sign up for notifications on github for releases, and just write yourself a tiny bash script to build the binary with xcaddy, and restart the service. You could potentially do a thing where you hook into apt to trigger your script after Caddy's deb package version changes, idk. But it's up to you to handle. | | | |
| ▲ | 2 days ago | parent | prev [-] | | [deleted] |
|
| |
| ▲ | nodesocket 2 days ago | parent | prev | next [-] | | I use Caddy as my main reverse proxy into containers with CloudFlare based DNS let’s encrypt. The syntax is intuitive and just works. I’ve used Traefik in the past with Kubernetes and while powerful the setup and grok ability has quite a bit steeper learning curve. | |
| ▲ | dizhn 2 days ago | parent | prev [-] | | You can have the binary self update with currently included plugins. I think the command line help says it's beta but has always worked fine for me. | | |
|
|
| ▲ | karmakaze 2 days ago | parent | prev | next [-] |
| Not only that but Nginx how the configuration is split up into all the separate modules is a lot of extra complexity that Caddy avoids by having a single coherent way of configuring its features. |
|
| ▲ | dizhn 2 days ago | parent | prev [-] |
| I checked out pangolin too recently but then I realized that I already have Authentik and using its embedded (go based) proxy I don't really need pangolin. |