keepalived is never the answer; if you can run it, your services are by definition crash-only share-nothing or inconsistent by design, or else you wouldn't let keepalived choose when to move the "primary flag" to the other service (as there'd be no way of sending the last ACKed data from the previous primary). Since this is the case, you could just load balance across the services and have them both active.
From a networking perspective, getting VRRP working on anything but physical equipment (e.g. in the cloud) is a fool's errand; it's L7/API-based and not on the ethernet level. Similarly with keepalived, which will get isolated from the monitored instances (thereby failing to the other, also "down" instance) — except it might have access to the API gateway of the cloud provider thereby disassociating the V-IP from both your instances; so you'll end up with more downtime with keepalived than you gain by it.
Since DNS is by default inconsistent, but eventually consistent and thereby possible to load-balance, you could run one instance of this stack on your static home IP and another instance on GCP/DO/AWS and configure multiple DNS servers in your DHCP options and on your phone, to get higher availability.
From a networking perspective, getting VRRP working on anything but physical equipment (e.g. in the cloud) is a fool's errand; it's L7/API-based and not on the ethernet level. Similarly with keepalived, which will get isolated from the monitored instances (thereby failing to the other, also "down" instance) — except it might have access to the API gateway of the cloud provider thereby disassociating the V-IP from both your instances; so you'll end up with more downtime with keepalived than you gain by it.
Since DNS is by default inconsistent, but eventually consistent and thereby possible to load-balance, you could run one instance of this stack on your static home IP and another instance on GCP/DO/AWS and configure multiple DNS servers in your DHCP options and on your phone, to get higher availability.