Skip to content
EPF Docs

Cloudflare CDN — Edge Termination for epf.productjorge.com

Date: May 6, 2026 | Status: ✅ Production

Why this version exists

The EPF dashboard is hosted on a single GCP us-east1 VM (Virginia), but the audience is mostly European traders. Every TLS handshake from a European user round-tripped to Virginia (~150 ms RTT) before any application data flowed, and the VM’s nginx was doing all compression on the hot path. Adding a Cloudflare Free proxy in front of the API origin moves TLS termination and compression to the closest CF point of presence (Madrid or Frankfurt for most European users at ~20 ms RTT).

The change also addresses a long-running concern about DDoS exposure — the VM origin IP had been publicly resolvable from the dashboard hostname, with no rate limiting or filtering layer in front of FastAPI.

What changed

Cloudflare Free proxy on the dashboard host

epf.productjorge.com is now proxied through Cloudflare Free. The DNS record at Cloudflare points at the VM origin IP 34.74.247.12 with the orange cloud (proxy ON).

The marketing apex (productjorge.com and www.productjorge.com) stays DNS-only at Cloudflare with the grey cloud — those records continue to resolve to the Squarespace marketing site directly. Only the dashboard subdomain is proxied.

Auto-applied by Cloudflare Free

These features are on by default once the proxy is enabled:

  • Brotli compression on text responses (HTML, JS, CSS, JSON when CF caches it)
  • HTTP/3 for compatible browsers (most modern Chromium/Firefox/Safari)
  • Edge SSL termination at the nearest PoP — the long Virginia round-trip happens once per TCP connection rather than once per request
  • DDoS protection at the edge

Manual follow-up still needed

A handful of CF dashboard settings are not auto-applied and should be configured explicitly:

  • SSL/TLS mode → “Full (strict)” — currently the auto-detected mode works (the origin presents a valid Let’s Encrypt cert), but explicit Full (strict) is the safer setting and avoids drift if CF’s auto-detection ever misclassifies.
  • Cache Rules for JSON responses on /api/v1/forecast/*, /api/v1/market/*, and root-level *.json. Cloudflare Free’s default doesn’t cache application/json even when the origin sends Cache-Control: public, max-age=.... Without an explicit Cache Rule, edge caching applies only to JS/CSS/images. This is the biggest remaining win on the table.

Origin still serves direct on its IP

Anyone who hardcodes 34.74.247.12 or has a stale DNS cache bypasses Cloudflare and hits the VM origin directly. Don’t rely on Cloudflare for security-critical filtering — nginx + FastAPI must remain hardened on the origin side, regardless of edge protection. The proxy is a performance and DDoS-rate-limit layer, not an identity firewall.

DNS delegated to Cloudflare

DNS records are now managed at Cloudflare zone 058e57cba7f4cf1fca270b5dff415422. Squarespace remains the registrar but has been told to delegate authoritative DNS to Cloudflare’s nameservers. This is the operationally important change: don’t change DNS at Squarespace anymore; go to the Cloudflare dashboard.

Let’s Encrypt renewal continues working

The certbot ACME-challenge path /.well-known/acme-challenge/ is passed through by Cloudflare even with the proxy ON, so existing Let’s Encrypt renewal cron continues to work without modification. Verified on the next renewal cycle after the cutover.

Key files

The cutover was a configuration change at the DNS / Cloudflare dashboard layer; no code changes were required on the application or nginx side. Reference documentation:

  • Performance Sprint — companion sprint shipped the same week, addressing the application-side performance budget that this entry addresses at the edge