Svinhufvud

Are you running rootless or rootfull containers?

At least with rootless containers (I have not used roortfull) I think its quite pointless to create separate users for the services, as you could use just the subuids (and/or SELinux) to get container separation, as you already seem to do .

I run my quadlets with uidmap and gidmaps, so I get explicit control of the mappings. It can be a tad tedious at times but I think it’s worth the hassle.

Yes, between major releases there can be breaking changes. But within there wont be, which is what I was referring to. In “V1” we didn’t have such a guarantee.

V3 is stable. It is the new version after V2. V1 was where the majoriry of the breaking changes happened.

A single wildcard CNAME that points to your domains A record is easier to manage I would say. This comes handy when you add a new service to your stack, as you dont have to go and make a new subdomain record.

You already seem to manage all subdomain updates with that script, so it won’t help you much with dyndns. That is, unless you hit a rate limit when trying to update a very large amount of records at once.

Keeping separate TLS certificates is a separate topic from having a single wildcard CNAME record. Separate TLS certificates offer a slight security advantage, as a single leaked certificate secret wont compromize the rest of your sites.

Using cloudflare tunnels means that the TLS is terminated at cloudflare. This means that cloudflare has the capability to snoop on your traffic, so you have trust cloudflare not to do that, especially if your traffic contains sensitive information.

Also, the ‘no media in free tunnels’ is outdated information as far as I know, so be sure to check up to date information on that.

I recommend you make A and AAAA records for the top level domain you own, and then set the needed subdomains as CNAME entries.

example.com points to your IP addresses, and the subdomains point then to your top level name.

This avoids you having to point a new IP at multiple places (be it manually or by dyndns) when//if your public IP changes.

Then you can set up a reverse proxy (caddy for example, it comes with automatic TLS), bind ports 80 and 443 to it, and route the traffic based on the name a client is trying to connect with.

So jellyfin.example.com would lead to your reverse proxy which would forward it somewhere internally, say 192.168.1.10:8096 for example.

This avoids you having to specify ports when connecting externally.

I listed the alternatives I found out about in the repo. But in shiort: Ihatemoney, abrechnung, nextcloud cospend and kitcheowl.

Hi and thanks for the comment.

Just to clarify, I am looking for neither contributors nor QA testers for the code. I generated this just for my benefit and threw it into the open. If someone gets any use out of it, cool. If not, also cool.

I am also not claiming the code to be professional or particularly robust. This is why I made the LLM part clear.

Jellyfin is great! Glad you got it up and running!

No problem! I think making the AI tag mandatory could be good for the community. Though I also recognize that bad actors could easily omit it and try to hide AI contributions.

Do you want to have the site to be public facing? If so, I think your current setup is good.

If it doesn’t need to be public facing, I would use wireguard to VPN into your LAN network, and secure it that way.