CF has an enormous set of products and features which would take a lot of resources to develop. I would expect Fly to focus on being a rock solid PaaS first, before going after more of these ‘higher level’ products. (You’re definitely right that Fly’s position as an SSL-terminating reverse proxy makes it possible, tho…)
Just one outsider’s conjecture, of course…
We get enough demand for WAF that we’ll ultimately end up doing it. But you’re right, we have no interest in building another CDN. Our big bet is that people don’t really need CDNs if you give them enough flexibility about where their app runs.
It might still make sense for some apps to run behind third party DDoS protection and similar features. At least for the near future. 
I’m getting some 522 errors (not 525) when using my Fly app with a CF Worker.
It’s very weird.
The Worker serves an MP3 file from a subdomain of my main domain media.domain.com/audio.mp3. When directly calling the URL, like say in the browser address, it works fine. But if an HTML in another subdomain like app.domain.com calls the MP3, I get the 522 error.
The app is hosted on Fly and proxied by CF using A and AAAA records.
If instead of using my subdomain for the Worker I use the one provided by CF like something.something.workers.dev it works fine.
Since both media.domain.com and app.domain.com are on the same domain, it shouldn’t be a referrer policy issue. Right?
I’ve tried not using CF to proxy the Fly app but that didn’t solve it.
I’m going to try to use the certs provided by CF on my Fly app (as I detailed in a previous post in this thread) and see if this solves it.
Edit:
Dumb me.
The solution was to add this header to the worker response:
'Cross-Origin-Resource-Policy', 'same-site'
Edit:
No that didn’t fix it. I’m getting the error again.
Edit:
The only thing that consistently worked was using the workers.dev subdomain CF provides.
So I ended up adding a new domain to CF and use it to trigger the worker.
I never tried to change the cert on the Fly app since the error also happened when trying to call the MP3 from any other domain.
For anyone still having this issue, the easiest fix is using the flexible SSL mode in Cloudflare settings and disable “force https” in your fly.toml config
fly.toml
[[services.ports]]
force_https = false
handlers = ["http"]
port = 80
Notice that this approach does not work with shared IP-v4, you will need to create an AAAA record in Cloudflare and connect the IP-v6 IP with the proxy option. Cloudflare will automatically create an A record that points to the Cloudflare servers.
This is required because the shared ips use the host to route traffic, they don’t work in Cloudflare DNS.
Thanks a lot my site BookTrader Home is now working.