This also adds a lot of moving parts and failure modes. For self-hosting I’d rather have downtime on a simple system that’s easy to fix rather than a complex setup that stays up but needs more maintenance when some component fails.

It's containerized. It's an easy enough problem to solve, if you don't want it complicated.

Here's what I did with my own setup: Stop the containers at night, copy the files to a second system that's configured with the same containers and that can become the primary as needed.

I already monitor my systems for health and backup states, so these would be added to that. But all that does take a few hours to set up.

You want your backups regardless and you want to have some certainty they're working/good. It's a problem that needs to be addressed, even you are going to agree with me on that.

  > So no fail over/redundancy? I think at minimum it should be two machines, so one can break.

Do you have two instances of everything in your life?

It's clear this product is intended for personal use.

I guess you have a couch in your home. This couch can seat friends/family. Yet you don't have a spare one?

Of course I do. There's also chairs in case there's an issue with the couch.

As soon as you add multiple instances you have to consider concurrency for every app you add, which is a huge cost on the app development side.