The DNS server is only one thing you tell the domain, the other is the certificate authority. And those publish all issued certificates as part of certificate transparency. https://en.m.wikipedia.org/wiki/Certificate_Transparency

To mitigate the amount of published information, you can request wildcard certs to keep the subdomains private.

You can also use a wildcard cname entry to capture all subdomains and leave out the pihole faff, given that you use a reverse proxy that forwards to respective services by subdomain.

How will you provide long term maintenance of their server for a one time payment of 150$?

Be cautious with the answers when asking things like this. In discussion boards like here many are (rightfully) very excited about selfhosting and eager to share what they learned, but may (“just”) have very few years of experience. There’s a LOT to learn in this space, and it also takes a very long time to find out what is truly foolproof and easily recoverable.

First of, you want your OS do be disposable. And just as the OS should be decoupled, all the things you run should be decoupled from one another. Don’t build complex structures that take effort to rebuild. When you build something, that is state. You want to minimize the amount of state you need to keep track of. Ideally, the only state you should have is your payload data. That is impossible of course, but you get the idea.

Immutable distros are indeed the way to go for long term reliability. And ideally you want immutability by booting images (like coreOS or Fedora IoT). Distros like microOS are not really immutable, they still use the regular package manager. They only make it a little more reliable by encouraging flatpak/docker/etc (and therefore cutting down on packages managed by the package manager) and a slightly more controlled update-procedure (making them transactional). But ultimately, once your system is in some way defect, the package manager will build on top of that defect. So you keep carrying along that fault. In that sense it is not immune to “os drift” (well expressed), it is just that drift happens slower. “Proper” immutable distros that work with images are self healing, because once you rebase to another image (could be an update or a completely different distribution, doesn’t matter), you have a fresh system that doesn’t have anything to do with the previous image. Furthermore the new image does not get composed on your computer, it gets put together upstream. You only run the final result with you know is bit for bit what was tested by the distro maintainers. So microOS is like receiving a puzzle and a manual how to put it together, and gluing it in a frame is the “immutability”. Updates are like losening the glue of specific pieces and gluing in new ones. In coreOS you receive the glued puzzle and do not have to do anything yourself. Updates are like receiving an entire new glued puzzle. This also comes down to the state idea: some mutable system that was set up a long time ago and even drifted a bit has a ton of state. A truly immutable distro has a very tiny state, it is merely the hash of the image you run, and your changes in /etc (which should be minimal and well documented!).

Also you want to steer clear from things like Proxmox and generally LXC-containers and VMs. All these are not immutable (let alone immune to drift), and you only burden yourself with maintaining more mutable things with tons of state.

Docker is a good way to run your stuff. Just make sure to put all the persistent data the belongs together in subfolders of a subvolume and snapshot that, and then backup these snapshots. That way you ensure that you meet the requirements for the data(base)'s ACID properties to work. Your “backups” will be corrupted otherwise, since they would be a wild mosaic from different points in time. To be able to roll back cleanly if an update goes wrong, you should also snapshot the image hash together with the persistent data. This way you can preserve the complete state of a docker service before updating. Here you also minimize the state: you only have your payload data, the image hash and your compose.yml.

I think you slipped in the discussion intendations somewhere, this branch of the discussion tree is about the implications of piping curl into bash vs. installing packages

By that logic you have to review the Zed source code as well. Either you trust Zed devs or you don’t - decide! If you suspect their install script does something fishy, they could do it just as well as part of the editor. If you run their editor you execute their code, if you run the install script you execute their code - it’s the same thing.

Aur is worse because there usually somebody else writes the PKGBUILD, and then you have to either decide whether to trust that person as well, or be confident enough for vetting their work yourself.

Security wise it doesn’t matter, you run the code they wrote in any case. So either trust them or don’t. Where it matters is making a mess on your computer and possibly leaving cruft behind when uninstalling. But packages are in the works, Arch even has it since before linux support was announced officially.

Additionally, night time is the time of creating backups. A second server pushes its backup also at night too. Potentially long running tasks like database migration I do at night. Lastly, when my server starts up it needs almost an hour until it truly reaches idle (potentially because it has to keep millions of files in sync with syncthing, I have to investigate). So my servers are more busy at night than at day