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 over a wildcard cert, 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 (or a single wildcard) 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 domain name a client is trying to connect to.

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 way you can use one top level domain for multiple services, and not have to specify ports when connecting externally