I would not directly expose Jellyfin to the Internet (including reverse proxy) because of security issues they've had. And no, a reverse proxy (like Caddy) doesn't usually add much insecurity or security^.
The thing I currently do is use forward_auth w/ Authelia (from anywhere, you could also use basic_auth though the UX sucks) but bypass it for the app in private IP ranges (aka at home or in VPN):
Apps get to continue working, and I can access it from my phone without a VPN setup (because it's annoying and I only look at metadata on my phone anyway).
You can also do a simpler config (which I used to do) where you just give an HTTP Unauthorized for anything outside of private ranges (this lets you do the HTTP challenge for a certificate while still not exposing Jellyfin to the general internet).
^You can configure more security by doing authentication in the reverse proxy so that anyone trying to attack services behind it must first authenticate with the reverse proxy, but this is not the default. Security-wise this ends up similar to forcing all access through a VPN first, if a little harder to setup.
Really? My experience was the opposite. I found everything I needed intheir docs rather quickly.
I guess it's true they don't have as many basic examples as nginx, but I'd take their lack of example over the mess an nginx config can become any day.
Maybe just cause I'm still learning this stuff but I found the docs fairly challenging to comprehend too. Now that I get the basics though, it's pretty easy looking back
The main problem is it's all written as a reference -- for people who already understand what/how, who need to just refresh their memory of the actual syntax.
There's very little explanatory stuff for people who need more than that. I had to read the same stuff multiple times, traversing many (or often, the same!) links, make notes, and then form a mental picture of what is going on.
Caddy maintainer here, if you could point to specific sections you find confusing, that would help. We rarely receive actionable feedback about the docs, so it's hard for us to make improvements.
Caddy is very basic, and thats why it works so easily. There is nothing wrong with it.
However it lacks some features that other reverse proxies offer. But if you dont need any of those, use Caddy.
Additional security? Not directly. But fail2ban and CrowdSec are easily set up too. And Caddy also combines very well with Authelia for authentication.
I'm wondering what those features are? What are the top 2 features you use most that are missing in Caddy? I used to go to nginx by default, but I switched to Caddy recently and I'm wondering what hurdles I'm setting up for myself.
Random question from a noobie…. Why do you use something like Traefik versus something like Cloudflare Zero Access? (Again sorry if question is dumb). I’m just a new guy to this learning as I go and after getting up zero access with a $8 domain and now being able to securely access everything via subdomains it seems confusing why apps like Traefik are still so popular? I know I’m missing something there but hoping someone points it out.
Anyone know if Caddy would be a good pick for a reverse proxy on a public subnet to distribute traffic to a bunch of subdomains in low traffic settings? I figure it could be a single source for all HTTPS stuff in my stack.
Or is it really just for like single applications running through Docker? Sorry, I haven’t played with it too much.
It basically acts like a DNS server serving up SRV records that caddy can use for dynamic configuration, I added in an on_demand_tls endpoint as well so that you don't get spammed for non existent TLS records.
Caddy is a great, easy web server. It honestly has some pretty good performance too. If you want to see some good tests against nginx, take a look at this:
tldr: Optimized nginx does outperform caddy in some areas in under heavy load, and they have a completely different strategies to handle failure. Under very heavy load Nginx just starts dropping and refusing connections to keep itself fast, while caddy will dramatically slow down response times in order to keep failures from happening.
I started with caddy because it seemed to have the least complex config file even though the documentation lacks examples which I found really annoying when troubleshooting or trying any less basic stuff. I also found certificate related issues really hard to fix.
Now I run nignx-proxymanager as a docker-container which unifies nearly all services into portainer for updating therefore making it easier to keep my stuff up to date.
nginx-proxymanager is also much easier imo on the certificate side of things. I create wildcard certificates for a few domains and select the right one depending on the proxy I add. I also use forwards for a few of my shelly-devices which don't seem to work with proxies and make it easier for me to access them via a domain instead of memorizing a growing number of IPs.
It is a simple layer 7 proxy and nothing more. It is the simplest so it works. As a comparison, almost all other reverse proxies can handle layer 4 traffic.
and I don't miss the label feature of traefik at all. centralized config for an entrance gateway is so much easier to maintain and find security flaws. I think labeling would be useful only in production clusters with thousands of microservices that you absolutely need the reverse of control to get away from dependency hell. Otherwise, I advice against using such feature, not even with a caddy plugin. (I mean if you really need it, why not just use traefik...)
After using Nginx for almost a decade, Caddy is pretty damn awesome regarding how simple it is. I don't need 8-10 lines of code to setup an SSL secured reverse proxy, I need three.
been running my reverse proxy on caddy from last 4-5 years. No issues at all. No maintenance needed. Setup and forget. Just needs a simple config file. Auto certificate generation.
It sits in charge of your ports 80/443 and decides to which webserver it sends traffic. If to your jellyfin, or your nextcloud, or your uptimekuma, or your vaultwarden or your mealie or your dashboard...
unlike others it automaticly do https certificate for you and its config is really clean and readable which is nice.
npm is nice for people who want easy web gui to configure stuff
caddy makes me feel more in control, its easier to backup too, since its all in one easy and readable config, and probably has more features as you go with your needs
There is also not that layer of which developer fucked up that you get when projects are projects of projects...
Strange, I never quite got why ever would i want to swtich to NPM, tried it and never liked it...
I ssh in and edit my caddyfile faster than I go to npm web interface and click through menus. I actually can just copy paste caddyfile config and have backup of it, while I am not even sure if npm has any backup solution by now, or you just suppose to backup on docker level.
And it is kinda in the way, a gui layer if you wanna do something more..
Caddy is great, been using it for a long time and made the switch from v1 to v2. The biggest negative, IMO, is that examples are usually for NGINX. This is fine if all you have to do is to translate the nginx 5-liner into a Caddy 1-liner, but for nextcloud, the code was a bit more complicated and required some googling (as people had that issue before and their forums are helpful).
LLMs can also be useful for translating nginx directives to caddy.
I would like to jump over to it. I have been struggling with Nginx and Apache and I am afraid I have made a mess of things. I am installing on an old Mac Mini with Mac OS so I don't really have a way to isolate and remove Nginx and Apache and I have a feeling if I try Caddy I will get some interferences.