I'm already experimenting moving workloads that I run on Workers to Fly Machines (because HTTP-only nature of Workers is limiting, and TCP Workers are no where

I'm already experimenting moving workloads that I run on Workers to Fly Machines (because HTTP-only nature of Workers is limiting, and TCP Workers are no where in sight), and I like what I see. That said: - Fly is missing HTTP/3 (QUIC) support (and it doesn't look like its going to be easy for them to simply bolt it on). Cloudflare is quick to deploy newer standards (even when experimental) like they did with HTTP/3 and ECH. - Sometimes Fly Machines start-up, but don't get sent any request from the Fly router. - Workers have free cache (up to 512M per obj), which essentially functions like a free blob store. On Fly, 10G disks spin up alongside Machines, but those are wiped every start/stop cycle. Whenever Fly Machines could be paused/resumed (with state intact)-- likely in near future-- things will start getting really interesting. - Plenty other rough (but livable) edges on Fly with Machines (that's okay, given it is still in preview). With Workers, Cloudflare has a very stable and highly optimized offering, I doubt established cloud providers can match that in the short-term, let alone upstarts. While Fly Machines (incredibly) boots my NodeJS app up in 200ms to 500ms, it is no where close to the 0ms to 5ms start-time on Workers. That said, for an unrelated workload where I run OLTP queries on-demand on DuckDB from parquet files stored in R2, I am definitely moving over to Fly Machines from AWS AppRunner (and this workload I can never run on Workers because just the DuckDB binary for WASM goes beyond Workers' 1MB limit). To me, Fly Machines are more of an AWS Fargate / AWS Lambda alternative than Workers, at this point in time.