Cloudflare
A thin worker in your own Cloudflare account, in front of your origin.
On Cloudflare, D3 Edge runs as a thin worker in your account, attached
to your hostname in front of your origin. Per request it extracts
metadata, asks the decision service for a decision, then passes the request
to your origin or returns a 403. It holds no state.
Exactly two calls leave your zone per request: the decision call, which is blocking and bounded by the timeout budget, and a fire-and-forget report of the outcome afterward, which never affects response time. Pass-traffic flows from your zone to your origin without touching our infrastructure.
How it attaches
Two ways to reach your origin, depending on what your origin is:
- Your origin is itself a Worker or Pages project. The D3 Edge worker takes over the hostname and forwards pass-traffic through a service binding. No public hop between the two.
- Anything else. The worker sits on the hostname (custom domain or zone route) and re-fetches the request against your origin.
Either way, pass means your origin serves as before. block means the
worker answers 403 without touching your origin.
Your zone's own security products are unaffected: Cloudflare runs WAF, Bot Management, and DDoS protection before any Worker, so D3 Edge only sees traffic they already passed, and changes nothing about how they behave.
Setup (guided)
The SDK is the worker itself; the guided part is only the installation. During early access we do it with you, because a worker in front of your production hostname deserves a second pair of eyes. The setup deploys the worker, attaches the route, and sets the secrets, all inside your account; everything it creates is yours to change or remove. Book a setup; it takes about half an hour. Have ready:
- An API key for your org.
- The hostname to protect, and what its origin is (Worker, Pages, or external).
- Someone with access to the Cloudflare zone.
Configuration reference
The worker reads these. Worth knowing even on a guided setup, since it all lives in your account and you can change any of it:
| Variable | Type | Default | What it does |
|---|---|---|---|
POLICY_WORKER_URL | string (URL) | unset | Decision endpoint. Unset means pure passthrough: the worker just proxies. |
POLICY_ADAPTER_KEY | string (secret) | unset | Your org's key, bearer for the decision call. |
POLICY_TIMEOUT_MS | number (ms) | 150 | Hard budget for the decision call. Guided installs set 500; lower it if you want a tighter budget. |
FAIL_MODE | "open" | "closed" | open | open: pass traffic when the call fails. closed: block instead. |
ORIGIN | service binding | n/a | Binding to a Worker/Pages origin. Takes precedence over ORIGIN_URL when both are set. |
ORIGIN_URL | string (URL) | n/a | Explicit origin URL, for origins that aren't Workers. |
The kill switch is built in: unset POLICY_WORKER_URL (or detach the
route) and the worker is a transparent proxy again. Your site never
depends on us to serve.
Response shape
Every response carries an x-d3-edge header: disabled, pass,
block, fail-open, or fail-closed. A blocked request gets a 403
with a JSON body:
{ "blocked": true, "ruleId": "…", "tier": "…", "identity": "…" }ruleId is absent when the block came from your org's default action
rather than a specific rule.