Installing NORG on a site that already runs a Cloudflare Worker
For a site that already runs its own Cloudflare Worker on {domain}. NORG’s Worker answers verified AI agents; everyone else is handed straight to your Worker, unchanged. The full technical guide is Installing in front of an existing Worker.
Two ways a Worker can be attached
Cloudflare lets a Worker answer a hostname in one of two ways. Which one your site uses decides what NORG does.
A URL pattern such as {domain}/* pointing at a Worker. The Worker runs in front of your origin server, and when it does a plain fetch(request) the request goes on to the origin named in DNS.
The hostname itself belongs to the Worker: the Worker is the origin. Cloudflare creates and manages the DNS record for it, so DNS shows a special record you did not add yourself.
One Worker per request
Only one Worker runs for a request. When a hostname has both a route and a Custom Domain, the route takes precedence. NORG’s Worker therefore goes first for every request, and it must hand everything that is not a verified AI agent on to your Worker.
Why a Service Binding named ORIGIN
If NORG’s Worker simply did a plain fetch, the request would go back out to the internet: a second billed request and, when your Worker is attached by a route, your Worker would be skipped altogether.
Instead NORG binds your existing Worker to its own as a Service Binding named ORIGIN. That is a private call from NORG’s Worker straight to yours by name, with no second public request and no reliance on which Worker takes precedence. It works the same way in both set-ups: ordinary visitors are handed straight to your Worker, unchanged.
What NORG does in each case
The installer reads your set-up before changing anything, then does one of three things.
| Your set-up | What NORG does | Asked first? | To undo |
|---|---|---|---|
| Your Worker is a Workers Custom Domain on {domain} | Adds one new route for NORG’s Worker and binds your Worker to it as ORIGIN. Nothing of yours is changed. | No: nothing of yours changes | NORG deletes its route and its Worker |
| Your Worker is attached by a route such as {domain}/* | Binds your Worker to NORG’s Worker as ORIGIN, then moves your route to NORG’s Worker. | Yes: the installer confirms before the route is moved | Your route is moved back to your Worker first, then NORG’s Worker is removed |
| NORG could not read the set-up | Binds nothing, and does not assume there is no Worker. The install shows a warning naming the read that failed. | The warning is shown on every install reply | Nothing of yours was bound or moved |
On a live site whose Worker is a Workers Custom Domain, running NORG Worker 0.15.0 with the ORIGIN binding: ordinary visitors receive your Worker’s response with its own headers unchanged, and an ?agent=true review request receives NORG’s mirror.
What changes and what does not
- One new Worker on your account: NORG’s, with its Site ID, a secret Site Key and a Service Binding named ORIGIN pointing at your Worker.
- One new route for NORG’s Worker (Custom Domain set-up), or your existing route moved to NORG’s Worker (route-attached set-up, only after you confirm).
- Your Worker’s code, its settings and the origins behind it.
- Your Workers Custom Domain and the DNS record Cloudflare manages for it.
- DNS, SSL/TLS and cache rules.
- What people and search engines receive: your Worker answers them, with its own response headers.
How to undo
Uninstalling leaves your set-up exactly as it was before.
- Custom Domain set-up: NORG deletes its route and its Worker. Your Custom Domain and your Worker were never changed, so your set-up is exactly as before.
- Route-attached set-up: your route is moved back to your Worker first, and only then is NORG’s Worker removed, so there is no moment when the route points nowhere. An install that stops part-way puts the route back the same way.
- At any time, the EDGE_DISABLED switch on NORG’s Worker hands every request straight to your Worker within seconds, without removing anything.
If NORG could not read your set-up
Reading your set-up needs the token’s zone-level Workers Routes: Edit permission (for your routes) and the account-level Workers Scripts: Edit permission (for your Workers Custom Domains). Both are part of the standard install token; see the token permissions.
If either read fails, NORG will not bind to a Worker it cannot see, and it will not assume there is no Worker. The install reply names the read that failed. If your site runs its own Worker, email solutions@norg.ai before installing.
Talk to us
If you are unsure which set-up your site has, or want NORG to check it with you before installing, write to us and include:
- The hostname, for example example.com.
- Your Worker’s script name, if you know it.
- Whether the install showed a warning, and its text.