1·
8 months agoI accomplish what you are looking for more or less, but it’s not an appliance–it’s a system of tools that I setup myself and maintain (which I enjoy). But it sounds like you want to avoid doing that.
My solution includes:
- A small Proxmox cluster so that if any single host dies, VMs can move to another host. This cluster approach is only necessary to protect against hardware failure–if that isn’t something you care to protect against initially, you can do all of the rest with only a single Proxmox host
- On that proxmox cluster, a few VMs. I run these are VMs because that makes it super easy to snapshot each VM before making experimental changes (i.e. trivial rollback) and super easy to backup each VM to my NAS (again easy rollback for unplanned problems that get introduced without me noticing right away)
- A VM for Home Assistant. I prefer Home Assistant OS to running it in a docker container myself. It is easier for me to manage this way.
- A VM for just scrypted. Scrypted is easier to deploy if you can put it in network host most which could in theory interfere with other docker containers, so I keep it on an isolated VM. Extra VMs are easy with proxmox so there is little downside.
- A VM running docker where most everything else runs. Docker containers are managed via portainer using docker-compose files
- Docker compose files (called “stacks” in portainer) life in a private github and when I make changes it github, they portainer pulls them down and updates the running containers with the new compose file.
- I run the Renovate bot on my github repo which notices when my containers are out of date and creates a Pull Request with a recommended upgrade. I can either manually approve those or create rules to auto merge them.
- Because all the docker-compose files are in a git repo, rolling back after a problematic upgrade is usually trivial (unless the data got converted as part of an upgrade which might require restoring a VM backup in the worst case)
- A VM running ubuntu I use for development (connected to remotely with Visual Studio Code). This is also the linux VM that I use to launch ansible playbooks to remotely do things like apt upgrades on the other VMs (HA excluded).
- One of the containers I run is uptime-kuma which monitors general health of all my other services and notifies me via telegram and email if a VM or container dies or starts to look unhealthy.
- Another container I run is homepage which is a dashboard that lets me get to all my services and also has widgets to surface more health information.
This is not at all turnkey and took some time to put together, but I find it to be relatively low ongoing maintenance now that it is setup. And I have pretty good high availability and great rollback/recovery support in the event that something goes sideways with an upgrade or some configuration change I make manually.
The point of purchasing a registered domain name and connecting it to a public DNS server is to make it findable from any Internet location. If you only ever want to use the domain name internally, you don’t need to have a public domain name and you can make up your own internal domain name that is served by your local DNS. To avoid future conflicts with public domains, I’d probably use a TLD that doesn’t exist (e.g. not .com or the like).