Why are you having to update your DNS records when you add a new service? Just set up a wildcard A record to send *.myserver.com to the reverse proxy and you never have to touch it again. If your DNS doesn’t let you set wildcard A records, then switch to a better DNS.
I didn’t use to, but I do now. Debian on everything (except the Proxmox servers, but Proxmox is basically Debian too)
I’m not a computer expert or planning to be.
Then don’t use Arch. Seriously, where are you guys even finding out about Arch, much less wanting to try it? Whoever told you Arch would be a good fit, don’t listen to them on anything Linux-related again. Arch is not for beginners, and it’s not for people who don’t want to learn the ins and outs of their computer because they’re having to dig into the guts to fix it whenever an update breaks something. Arch is a fine distro for people who WANT those things, need bleeding edge hardware support, and don’t mind having to fix it whenever it breaks. It doesn’t sound like that’s at all what you’re looking for though.
I guess it depends on the containers that are being run. I have 175 containers on my systems, and between them I get somewhere around 20 updates a day. It’s simply not possible for me to read through all of those release notes and fully understand the implications of every update before implementing them.
So instead I’ve streamlined my update process to the point that any container with an available update gets a button on an OliveTin page, and clicking that button pulls the update and restarts the container. With that in place I don’t need fully autonomous updates, I can still kick them off manually without much effort, which lets me avoid updating certain “problematic” containers until after I’ve read the release notes while still blindly updating the rest of them. Versions all get logged as well, so if something does go wrong with an update (which does happen from time to time, though it’s fairly rare) I can easily roll back to the previous image and then wait for a fix before updating again.
Unfortunately that approach is simply not feasible unless you have very few containers or you make it your full time job.
self-signed won’t get rid of any warnings, it will just replace “warning this site is insecure” with “warning this site uses a certificate that can’t be validated”, no real improvement. What you need is a cert signed by an actual certificate authority. Two routes for that:
Create your own CA. This is free, but a PITA since it means you have to add this CA to every single device you want to be able to access your services. Phones, laptops, desktops, etc.
Buy a real domain, and then use it to generate real certs. You have to pay for this option ($10-20/year, so not a lot), but it gets you proper certs that will work on any device. Then you need to set up a reverse proxy (nginx proxy manager was mentioned in another post, that will work), configure it to generate a wildcard cert for your domain using DNS-01 challenge, and then apply that cert to all of your subdomains. Here’s a pretty decent video that walks you through the process: https://m.youtube.com/watch?v=TBGOJA27m_0
Who cares if it’s exposed to the internet?
Encrypting your local traffic is still valuable to protect your systems from any bad actors on your local network (neighbor kid cracks your wifi password, some device on your network decides to start snooping on your local traffic, etc)
Many services require HTTPS with a valid cert to function correctly, eg: Bitwarden. Having a real cert for a real domain is much simpler and easier to maintain than setting up your own CA