this post was submitted on 13 Nov 2023
2 points (100.0% liked)

Self-Hosted Main

502 readers
1 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

For Example

We welcome posts that include suggestions for good self-hosted alternatives to popular online services, how they are better, or how they give back control of your data. Also include hints and tips for less technical readers.

Useful Lists

founded 1 year ago
MODERATORS
 

This seems too straightforward, what's the catch?

Like how secure is it? Should I be turning it off (and disabling the port forwarding) when not using it?

Do I need any additional security? Mainly just want to use it for Jellyfin

Thanks

top 50 comments
sorted by: hot top controversial new old
[–] [email protected] 2 points 10 months ago

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):

jellyfin.example {
        @notapp {
                not {
                        header User-Agent *Jellyfin*
                        client_ip private_ranges
                }
        }

        forward_auth @notapp localhost:8080 {
                uri /api/verify?rd=https://authelia.example/
        }
        reverse_proxy 192.168.1.44:8080
}

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.

[–] [email protected] 1 points 10 months ago (1 children)

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.

load more comments (1 replies)
[–] [email protected] 1 points 10 months ago (3 children)

The documentation it's surprisingly bad at explaining common patterns of use.

It is also a bit thicker compared to nginx or HAproxy.

[–] [email protected] 1 points 10 months ago (1 children)

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.

[–] [email protected] 2 points 10 months ago

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

[–] [email protected] 1 points 10 months ago (1 children)

Totally agree.

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.

[–] [email protected] 1 points 10 months ago (4 children)

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.

[–] [email protected] 1 points 10 months ago (1 children)

One thing that threw me in the beginning was that the docs didn't show examples in context. As an example, if you look at the basicauth docs it shows:

basicauth /secret/* {
	Bob $2a$14$Zkx19XLiW6VYouLHR5NmfOFU0z2GTNmpkT/5qqR7hx4IjWJPDhjvG
}...
}

Where can I use this? Globally? In the top-level of the virtualhost definition? If I'm reverse proxying, do I put it inside the reverse_proxy stanza? I used Apache for years and the docs always stated what context directives could be used in, eg.

https://httpd.apache.org/docs/2.4/mod/core.html#acceptpathinfo

load more comments (1 replies)
[–] [email protected] 1 points 10 months ago (1 children)

at the moment my caddy setup is stable; I am recounting my experience from memory.

It may be useful to consider what I said in a broader perspective -- i.e., what you have is an excellent reference but it does not help discovery of task-oriented solutions.

Sorry I am unable to express the problem better than that. Will keep an eye out in future if I can get more concrete and open an issue or something.

[–] [email protected] 1 points 10 months ago (1 children)

😬 Well, that's not helpful. Without specific feedback, there's nothing we can do to improve the docs. It's exhausting to read vague complaints about the docs, because it's 90% of the feedback we get.

But yes, please do reach out (open a GitHub issue, comment on the forums etc) if you do notice something that doesn't meet your expectations in the docs.

[–] [email protected] 1 points 10 months ago (2 children)

What I think they meant is more “how to achieve X or Y” focused documentation, rather than just explaining how features A or B work. The former approach explains what you should use and how to do it, the latter only documents what each variable does.

To use an analogy: I could probably build a bicycle from the individual parts based on a tutorial with that goal in mind, but not based on the individual technical descriptions of each part.

/u/xkcd__386 is that what you meant?

[–] [email protected] 1 points 10 months ago (2 children)

I understand what they meant, but it's broad/vague, and not specific/actionable.

We do have a tutorials section in the docs, and we have the https://caddyserver.com/docs/caddyfile/patterns page which are that.

Our question is how are those lacking? Just saying "more please" doesn't help because we don't know what the need is. We can't imagine every single possible usecase, because it's actually infinite. Caddy is a "general purpose webserver" which means "it can do just about anything".

Help us by telling us what specifically what usecase is important to you. We don't have telemetry, we need users to tell us.

[–] [email protected] 1 points 10 months ago

Right, gotcha. I can’t help you there since I don’t use Caddy.

[–] [email protected] 1 points 10 months ago

The tutorials section is very basic; I am not talking at that level. The patterns page is closer to the level of complexity that one needs help with, and it does cover several items, but you have 30-40 directives, many with several options, global options, and so on, so there're bound to be gaps.

In the other comment you said this is "90% of the feedback we get", and I can certainly understand the frustration -- people want documentation to magically solve their specific problem quickly, without having to read anything extraneous to it, which is clearly impossible.

As I said before, I'll keep it in mind next time I need to do something if I can't find it easily in the docs I'll at least highlight the effort it took, what I searched/read/found, etc., so you have something concrete.

[–] [email protected] 1 points 10 months ago

Spot on.

Of course from their point of view that's "not helpful". Maybe I'll spend some time looking at it to come up with something, if I have time.

[–] [email protected] 1 points 10 months ago (1 children)

Something I encountered last week.

  • wanted to test running caddy without https and without being open to the world, to turn off automatic https.
  • Googled and came up with auto_https off documentation that I read.
  • It did not work, http still did not work
  • Googled more and landed on forum page that explained why auto_https is not working and that it needs explicitly stated http:\\ or port :80 in the address. Otherwise caddy will listen by default for only https.

It was no biggie, that forum post is literally the second google result for auto_https and does good job, but you asked and I have it fresh in memory...

[–] [email protected] 1 points 10 months ago

Thanks, that's helpful. Yeah the docs for auto_https should explain up-front that this only affects the feature called "Automatic HTTPS" and does not change the default port/procotol of Caddy, which is always HTTPS unless otherwise specified (i.e. by using http:// as a site address prefix, or :80 as a suffix).

[–] [email protected] 1 points 10 months ago

I found the practical use cases helpful, probably should expand that cookbook.

E.g. I've found this sort of construct helpful (not sure how safe using {host} here is though):

app.example.com, another.example {
   reverse_proxy unix//srv/backend/{host}/server.socket
}

It is hard to understand the whole thinking behind the config system, with directives, matchers, placeholders, invisible reordering of rules, and all the other concepts. And to add to the complication, Caddyfile and API are completely distinct systems and it is not very clearly explained [that one really ought to be using Caddyfile and ignoring the API for most use cases]. And that distros do ship Caddyfile-based systemd service now (some also API-based, and perhaps with root-only control socket to add to the confusion).

I did dig into it to really understand how it works but that took a couple of weeks to digest, which is a lot for someone who only needs a simple server/proxy.

[–] [email protected] 1 points 10 months ago

Caddy maintainer here, which patterns are you confused about?

What do you mean by "thicker"? I don't think I agree but I'm not sure what you mean.

[–] [email protected] 1 points 10 months ago (11 children)

I switched from Traefik to Caddy a few years ago and have no ragrets. The only complaints I have about Caddy:

  • It doesn't support configuring virtual hosts automatically via docker labelsl (like Traefik).
  • Many features (like DNS auth for certs) require compiling Caddy. Which is easy but annoying.
[–] [email protected] 1 points 10 months ago

You mean using dns providers like cloud flare?

It’s very easy just don’t this

caddy add-package github.com/caddy-dns/cloudflare

[–] [email protected] 1 points 10 months ago (1 children)

If you are using Docker, check out this repository for Caddy builds with different plugins https://github.com/serfriz/caddy-custom-builds

[–] [email protected] 1 points 10 months ago
[–] [email protected] 1 points 10 months ago (1 children)

It doesn't support configuring virtual hosts automatically via docker labelsl (like Traefik).

Here you go: https://github.com/lucaslorentz/caddy-docker-proxy. No more extra Caddy configuration file.

[–] [email protected] 1 points 10 months ago

Whoa, just when I thought I had completed my setup haha

[–] [email protected] 1 points 10 months ago

I wrote something that can setup caddy automatically from docker labels.

It's not well documented as I mostly wrote it for myself. https://hub.docker.com/r/mheys1/docker-dynamic-caddy https://github.com/mattheys/ddc

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.

[–] [email protected] 1 points 10 months ago (1 children)

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.

[–] [email protected] 1 points 10 months ago

Because this is r/selfhosted. :-)

[–] [email protected] 1 points 10 months ago

I use Caddy and agree with your last point in the context of Crowdsec

load more comments (5 replies)
[–] [email protected] 1 points 10 months ago (2 children)

What is it? Is it an alternative to unraid?

[–] [email protected] 1 points 10 months ago

No, it’s a web server and reverse proxy.

It automatically adds HTTPS using let’s encrypt certificates.

[–] [email protected] 1 points 10 months ago

It's no different than NGiNX, put in your config and it just works.

[–] [email protected] 1 points 10 months ago

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.

[–] [email protected] 1 points 10 months ago (2 children)

How do you compare Caddy with nginx proxy manager?

[–] [email protected] 1 points 10 months ago

Id say npm is 10x better than caddy

[–] [email protected] 1 points 10 months ago

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...

[–] [email protected] 1 points 10 months ago (3 children)

Can somebody explain in plain English what it is used for?

[–] [email protected] 1 points 10 months ago

Caddy is an http server, often used as a reverse proxy. It’s particularly useful for TLS termination and automatic TLS certificate management.

load more comments (2 replies)
[–] [email protected] 1 points 10 months ago

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.

[–] [email protected] 1 points 10 months ago

there are some trade offs, mostly performance

[–] [email protected] 1 points 10 months ago

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.

[–] [email protected] 1 points 10 months ago

Been using it for a few years now, and yeah, it's just that simple.

I have 443 open and pointing at my Caddy instance, it handles everything else.

[–] [email protected] 1 points 10 months ago

It just runs... Two years straight. Some more services since start of caddy... No worries.

Recently added auth with authelia... Still straight forward.

Easy setup, always online. That's it. Period.

[–] [email protected] 1 points 10 months ago

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...)

[–] [email protected] 1 points 10 months ago

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.

[–] [email protected] 1 points 10 months ago

it is what you mean...no less no more...Caddy rocks...

[–] [email protected] 1 points 10 months ago (1 children)

Used Caddy for years and after a week of Nginx Proxy Manager I never went back to Caddy.

load more comments (1 replies)
load more comments
view more: next ›