Thank you so much for this reply! Cloudflare Workers as a way of bypassing whitelisted Cloudflare IPs makes a lot of sense, and of course is an attack vector t

Thank you so much for this reply! Cloudflare Workers as a way of bypassing whitelisted Cloudflare IPs makes a lot of sense, and of course is an attack vector that needs to be mitigated. Now I'm really dreaming – but it would be really neat to have a mechanism similar to LetsEncrypt where you could prove ownership of a domain and allow arbitrary requests to that domain. Given the potential throughput of Cloudflare Workers, it could be valuable as a safeguard even in the current setup (I'm guessing it's possible to amplify one request quite a lot which could annoy a victim server even with if the requests have the wrong `Host`-header?). You're partially right about the CNAME. The reason I ended up needing workers is to preserve the cookie check that I currently have (implemented in NGINX/Lua) which redirects to app.peergrade.io if a session cookie is set (the cookie is scoped to the top-level domain). Not the neatest, but it used be quite common -- Heroku still does something similar. I didn't think about Node not being as set-in-stone-standard as The Web Platform and not being sandboxed. An example of where the current setup is awkward would be using `atob` and `btoa` with actual binary data, I had this case when unpacking base64-data in the cookie.