Download the release bundle from Download Edge-Native Defender. New to Edge-Native Defender? Start with Edge-Native Defender overview.

Watch the install: the steps below, in order and as written: a hostname in the Cloudflare dashboard before Defender, the token check (step 1), defender.conf copied from the example and edited (step 2), preflight and install (step 4), the checks before going live (step 5), and removing it. Each part of the video is captioned with its step. The token itself is created in the dashboard (step 1), which the video does not show.

At a glance

Deployment architecture

Defender runs in your Cloudflare account as a Worker, in every Cloudflare location that already serves your zone, on a route you already have. There is no capacity to provision; a traffic spike is absorbed by the same network that absorbs it today.

  BEFORE

    client ---> proxied DNS ---> Cloudflare edge ------------> your origin


  AFTER

    client ---> proxied DNS ---> Cloudflare edge ------------> your origin
                                       |
                                       | Worker route (the paths you choose)
                                       v
                              Defender (Cloudflare Worker)
                                       |
                                       +---> your Cequence tenant: policies in,
                                             analytics out, in the background

What stays the same. Your DNS records, your origin, and every hostname and path you do not route to Defender. Defender forwards through your proxied DNS record, so it does not need to be told your origin.

What Defender does with a request. A blocked request is answered at the edge and never reaches your origin. An allowed request is forwarded byte for byte, and your client receives your origin's response byte for byte: Defender inspects a copy of each body, up to your tenant's capture settings, and never changes what it forwards.

What is sent to Cequence. For each request: its headers and URL, the response status and headers, and the inspected body copies, masked first with your tenant's Sensitive Data rules before they leave your account. Your traffic filters decide whether a request is reported at all.

No request waits on Cequence. Policies are already at the edge before a request arrives, and analytics are sent after your client has its response. The installer creates a Workers KV namespace and two Cloudflare Queues beside the Worker for this, all in your account and off the request path. Learned policies, such as IP and fingerprint policies, take effect within about 25 seconds; a policy you publish takes effect without a redeploy.

Installation

Prerequisites

• A Cloudflare account with the zone, on the Workers Paid plan. The free plan's 10 ms CPU cap is not enough for policy evaluation, and it has no Queues. Any zone plan, including Free, is enough.
• A proxied DNS record (orange cloud) for every hostname you route to Defender. If the hostname already serves traffic through Cloudflare, it exists. Without one, requests never reach Defender. The installer checks this for you in step 4 (./bin/defenderctl-cloudflare preflight).
• A Cloudflare API token for the account that owns the zone (step 1). It is used only by you at install time; Cequence never receives it.
• Node 20 or later where you install from.
• wrangler v4 or later where you install from (npm install -g wrangler).
• Terraform 1.5 or later, only if you install with the bundle's Terraform module instead of the installer.
• Your tenant name (such as acme.1), client ID and client secret, from Cequence.

Download the bundle

On Download Edge-Native Defender, click the release to save it with your browser, or copy its link and download it in a terminal. The link is signed: keep the double quotes, because it contains & characters that a shell otherwise splits the command at, and copy a fresh one if the download is refused (a link expires after a few weeks).

curl -fL -o edge-native-defender.tar.gz "PASTE_THE_LINK_HERE"
tar xzf edge-native-defender.tar.gz
cd edge-native-defender/defender-for-cloudflare

Every step below runs in that directory.

1. Create the Cloudflare API token

In the Cloudflare dashboard: My Profile -> API Tokens -> Create Token -> Create Custom Token, with these permissions:

Account -- Workers Scripts: Edit
Account -- Workers KV Storage: Edit
Account -- Queues: Edit
Account -- Account Analytics: Read
Zone    -- Workers Routes: Edit
Zone    -- Zone: Read
Zone    -- DNS: Read

DNS: Read (optional) lets the installer's checks in step 4 confirm your record is proxied; Account Analytics: Read is needed only for staged upgrades. Under Account Resources include only the account that owns the zone, and under Zone Resources only your zone. Copy the token; Cloudflare shows it once.

Export it, and check it works before going further. This is the test Cloudflare suggests on the token's summary page:

export CLOUDFLARE_API_TOKEN=PUT_YOUR_TOKEN_HERE
curl "https://api.cloudflare.com/client/v4/user/tokens/verify" -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN"

The answer should include "success": true and "status": "active". This proves the token is valid, not that it has every permission above; step 4 checks the permissions. This check is for a token made under My Profile, as above. A token made under the account instead (Manage Account -> Account API Tokens) is checked at https://api.cloudflare.com/client/v4/accounts/PUT_YOUR_ACCOUNT_ID_HERE/tokens/verify; the address above answers Invalid API Token for it although the token works.

2. Verify the bundle and fill in the config

sha256sum -c SHA256SUMS
cp defender.conf.example defender.conf

Set four values in defender.conf:

Account ID, not Zone ID. In the Cloudflare dashboard, open your domain: its Overview page lists both under API, at the bottom of the right-hand column. Use the Account ID. If you give the Zone ID by mistake, preflight (step 4) says so and names the account that owns the zone.

The four keys in the table above are the file's only uncommented lines; every other line is a comment. To see only the lines that are not:

grep -v '^#' defender.conf | grep .

Bundles before 0.26.0 shipped the same example to every platform, with three more uncommented lines for other platforms: CEQUENCE_DISTRIBUTION_ID (AWS), ENVOY_WASM_PATH and ENVOY_EXTPROC_IMAGE (Envoy). Defender for Cloudflare ignores them; leave them or delete them.

Optional: CEQUENCE_NAMESPACE (default prod) names the deployment's resources; use a different one per environment. CEQUENCE_CANARY_PERCENT inspects a share of clients while you onboard. ORIGIN is only for a backend on a different hostname from the route. The routes key was CEQUENCE_INSPECTED_ROUTES before 0.19.1, and that name still works. Every key is in CONFIGURATION.md in the bundle.

Secrets never go in the file (a file that sets them is rejected). Export them, in the same shell as the token from step 1:

export CLOUDFLARE_ACCOUNT_ID=PUT_YOUR_ACCOUNT_ID_HERE
export CEQUENCE_CLIENT_SECRET=PUT_YOUR_SECRET_HERE

3. Choose what Defender inspects

Routes are Cloudflare route patterns, so you can protect one hostname or one path prefix rather than the whole zone. * is the only wildcard. CEQUENCE_EXCLUDED_ROUTES keeps paths off Defender entirely: those requests skip the Worker and are not billed for it.

CEQUENCE_CLOUDFLARE_INSPECTED_ROUTES="api.example.com/* www.example.com/checkout/*"
CEQUENCE_EXCLUDED_ROUTES="api.example.com/health/*"

The Worker runs before Cloudflare's cache, so every request on a route is inspected, including ones the cache would have answered: a blocked client cannot be served a cached response, but static assets are inspected and billed for no return. Route Defender at your API and dynamic paths and leave static content out. (Defender for AWS is the opposite: the cache answers first.)

4. Install

./defender.conf is picked up automatically, so these take no arguments:

./bin/defenderctl-cloudflare preflight
./bin/defenderctl-cloudflare install

preflight checks your tools, the token, the zone, the DNS record and your Cequence credentials. install creates the resources, deploys, and stages the bypass version described under Availability. It is safe to re-run; --dry-run prints every command it would run. For infrastructure as code, use the bundle's terraform/ module instead.

5. Check it before you go live

1. Run ./bin/defenderctl-cloudflare status (what is installed, read-only) and ./bin/defenderctl-cloudflare validate (whether requests through the route are answered and reach your origin).

2. To check that policies arrive and analytics leave, turn diagnostics on and run install again, which redeploys with the change, then validate again:

   echo CEQUENCE_DIAGNOSTICS=yes >> defender.conf
   ./bin/defenderctl-cloudflare install
   ./bin/defenderctl-cloudflare validate
   

3. Send a request that one of your policies blocks, and check it is blocked. In the dashboard, the Worker's Observability -> Invocations with the query $workers.eventType = "fetch" AND $workers.event.response.status = 403 lists the blocked requests (= 200 the others); they take up to two minutes to appear.

4. Remove the CEQUENCE_DIAGNOSTICS line from defender.conf and run ./bin/defenderctl-cloudflare install again. With diagnostics on, /__end/status and the x-end-echo header are readable by anyone who can reach the route.

With diagnostics off, validate lists what it did not check, as expected. Allow a couple of minutes after a fresh install for your first policies to arrive. Before going live, make sure your origin accepts traffic only through Cloudflare (origin shielding, mTLS or IP allowlisting).

Upgrades and rollback

Extract the new bundle and run, from it:

./bin/defenderctl-cloudflare upgrade --worker cequence-defender-prod

Replace prod with your namespace (with one deployment, --worker can be left out). Export CLOUDFLARE_API_TOKEN and CEQUENCE_CLIENT_SECRET; your defender.conf is not needed, as the settings are read from the deployment.

The upgrade moves traffic in steps, 1% to 10% to 50% to 100% by default, holding each step for 10 minutes. At each step it compares the new version's error rate with the old one's using Cloudflare's own counters, and rolls back by itself if the new version is worse. Your policies and queued analytics are kept, so nothing is re-fetched from scratch.

To roll back at any time:

./bin/defenderctl-cloudflare upgrade --worker cequence-defender-prod --rollback

This puts 100% of traffic back on the last good version. If a ramp is interrupted, traffic stays split between the two versions until upgrade --resume finishes it or --rollback undoes it; status shows where it is. On a quiet hostname, where a step may never see enough requests to judge, re-run install from the new bundle instead, which moves all traffic at once. upgrade refuses to run while Defender is bypassed; turn the bypass off first.

Performance and sizing

There is no added network hop, and a blocked request never reaches your origin, so your backend sees no load from denied traffic.

Cost

Cequence charges nothing for the infrastructure. Defender runs in your Cloudflare account and Cloudflare bills you at list price:

• Workers Paid, $5 a month per account. One subscription covers every deployment on the account.
• A fixed floor per deployment for the background policy refresh, from $6 a month in about 10 Cloudflare locations to $46 in about 100.
• $0.45 to $1.62 per million requests for Workers requests, CPU and the analytics queue. Sparse traffic costs more per request than dense traffic.

Estimates from a reference deployment, excluding the $5 subscription, not a quote. DEPLOYMENT.md in the bundle has the full breakdown and the settings that lower the floor.

Availability

• If Cequence is slow or unreachable, your traffic is unaffected. Defender keeps enforcing the policies it last received, and analytics wait in the queue in your account and are retried. A background refresh that stops is restarted automatically.
• If Defender hits an error on a request, Cloudflare forwards that request to your origin as if Defender were not there.
• If you need Defender off the path at once, use the bypass lever:

  ./bin/defenderctl-cloudflare bypass --on
  ./bin/defenderctl-cloudflare bypass --off
  

--on sends all traffic to the staged bypass version, which forwards every request untouched (not inspected, enforced or reported) while still keeping policies fresh, so turning it off starts warm. --off returns traffic to Defender, --percent N splits, and no argument reports what is serving. Each takes seconds and changes no DNS, routes or zone settings. Cloudflare applies it before any Defender code runs, so it works whatever Defender is doing, and it is plain wrangler versions deploy, which you can run yourself. Cequence holds no credential in your Cloudflare account. As a last resort, removing the Worker route also takes Defender off the path; re-adding it restores the deployment as it was. - A fresh install blocks nothing until your tenant's first policy publish arrives. Until then Defender forwards all traffic.

Known limits

• Every policy action is enforced: block, add-header, challenge, rate-limit and redirect. Rate-limit counts are shared across all Cloudflare locations and are eventually consistent, so a client can briefly exceed its limit before it is limited.
• Response bodies are captured for analytics but never enforced on; a decision applies to the request. Response signals shape decisions on later requests.
• JA3/JA4 fingerprints come only from Cloudflare Bot Management (Enterprise). Without it, a JA3/JA4-keyed policy never matches.
• Only traffic passing through Cloudflare is inspected. For a zone such as example.co.uk, set CLOUDFLARE_ZONE.
• With Defender on a path only (a route such as api.example.com/api/*), validate, status and the end of install cannot reach Defender's status page and report no status, although Defender is running. Check such an install with a request your policy blocks on that path.

If something is wrong

./bin/defenderctl-cloudflare debug collects everything support needs into one file, with no credentials. The full troubleshooting reference is in DEPLOYMENT.md in the bundle.

Removing it

./bin/defenderctl-cloudflare uninstall

After you type the Worker name to confirm, it removes the Worker, its routes, and the queues and KV namespace that the installer created, keeping any it found already there. A Terraform install is removed with terraform destroy.

Your DNS records are untouched, and traffic goes straight to your origin again. If you created a record only for Defender, with no origin behind it, remove or repoint it, or the hostname will return 522.