FairyStack · concrete test case
What would Cloudflare change for FairyStack?
Today, public requests reach nginx on FairyStack’s VPS. Compare that verified path with three possible edge-assisted paths.
Request path
“Cloudflare edge · Cache + WAF” for FairyStack
Edge
A proposed Cloudflare layer in front of fairystack.com. It would receive public requests before FairyStack’s VPS.
Cache
A temporary copy of FairyStack assets such as icons, CSS, or JavaScript. A cache hit would avoid the VPS.
WAF
A web application firewall. It could reject suspicious FairyStack HTTP traffic before nginx or Flask sees it.
Worker
Optional edge code. A deliberately converted FairyStack endpoint could run here; existing Python does not move automatically.
Origin
FairyStack’s VPS: nginx, the Python control plane, app services, agent processes, secrets, and persistent data.
What moves—and what does not
| Capability | At the edge | On the VPS |
|---|---|---|
| TLS and attack filtering | Cloudflare could terminate public HTTPS and reject unsafe traffic early. | FairyStack retains AuthReturn checks and origin defense in depth. |
| Static files | Cache reusable FairyStack HTML, CSS, JavaScript, icons, and guides. | The release remains the source of those files. |
| Small request handlers | A chosen endpoint could be rewritten for the Worker runtime. | Existing Flask APIs continue unchanged unless deliberately converted. |
| Agent sessions and deployments | Not ordinary request Worker workloads. | Systemd services, Codex processes, durable tasks, and release draining stay here. |
| Secrets and persistent data | Move only with a separate storage and security design. | SOPS mounts, session state, app data, and local databases stay here. |
FairyStack’s realistic first experiment is additive. Put one test hostname through Cloudflare, cache safe assets, observe WAF behavior, and keep the control plane and agents on the VPS. A Worker endpoint is a later, separate experiment.