For litestream specifically, using fly-force-instance-id
should direct the request to a VM instance, instance-id
, iff fronted by Fly’s http/s proxy, ref: Is it possibly for a client to connect to a particular instance - #4 by jerome
Technically, you could also make use of the 6pn
internal network to chain the request through to wherever; ie, to any fly app within that fly org (ref).
Forgive me if what I’m saying doesn’t make any sense.
Discounting the many failure modes (idempotent requests, replica unresponsive after write, client dead, network partitioned, timers running out of sync due to cpu starvation, writes interlaced between get requests, and so on…), it does make sense. But as you mention, I’d rather wait for Fly to integrate litestream themselves (and solve those distributed systems problems for me). In the meanwhile, as a placeholder, you could consider using another database like PlanetScale (read-replicas), Aurora Serverless v2, Xata, tiledb, and its ilk.