Yes, stateless apps automatically recover from individual-host failures by shifting workloads between two or more Machines on different servers, App Availability and Resiliency · Fly Docs has details on this. In short, for service-based apps, the default deploy is two Machines configured to auto-start and auto-stop, and for apps without services, the default deploy is an always-on Machine plus a standby machine that starts only if the paired Machine becomes unavailable.
On what might technically be feasible in the future for Volumes, see Bottomless S3-backed volumes for some experimental work we’ve done on Fly Volumes backed by durable object storage.
Fly apps come in many shapes and sizes- development apps are fine on a single machine, many production apps work best as a low-latency cluster of machines in a single region to protect against individual-host failures, and uptime-critical production apps might want to deploy machines in multiple regions with cross-region replication/failover to protect against region-wide failures. The tradeoffs between architectural choices depend on the particular app and the amount of availability risk it can tolerate, so there’s not a one-size-fits-all answer on what’s best. In any case I hear your confusion/frustration on this, and appreciate the feedback.