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

Self-Hosted Main

515 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

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 1 points 1 year ago (17 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 1 year ago (13 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 1 year ago (12 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 1 year 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.

load more comments (11 replies)
load more comments (11 replies)
load more comments (14 replies)