The system
How the system worksThe DirectoryDispatchThe LedgerAI modelsAI agentsYour installationThe appThe research libraryWhat changes for your businessUse it from your softwareEverything it can do
Messaging
iMessageWhatsApp
Ads and leads
AdsCreativeLeads
Devices
Devices
Industries
RealtorsRestaurantsHome services
Explore
How it worksPermissions and limitsCompareSet upQuestionsText me

Cloudflare OS XL part 6: the edge layer in front of the Worker

Cloudflare OS XL part 6: the edge layer in front of the Worker

Part 6 of Cloudflare OS XL, an inventory of the Cloudflare platform this build does not have installed.

Every request to this site reaches a Worker. That is a design decision, and mostly a good one — the routing, the auth, the egress redaction and the render all live in code that can be read, tested and gated.

It also means that anything the Worker is asked to do, it does. There is no layer in front of it that decides a request is not worth running. The token-mint endpoint, the admin login, the objection intake and the article write path are all rate-limited by nothing at all. A caller who wants to hit /api/articles/<slug>/objections ten thousand times a minute will be served ten thousand Worker invocations.

Four products sit in that gap.

The rate-limit binding

The rate-limit binding lets a Worker define a limit and check it inline. It is not a dashboard rule; it is a binding with a method.

toml
[[unsafe.bindings]]
name = "MINT_LIMIT"
type = "ratelimit"
namespace_id = "1001"
simple = { limit = 20, period = 60 }
Line 5, Column 1toml
js
const { success } = await env.MINT_LIMIT.limit({ key: callerFingerprint });
if (!success) return json({ error: 'rate_limited' }, 429);
Line 2, Column 1JavaScript

The reason this belongs in the Worker rather than in a WAF rule is that the key can be anything the code knows. Not just an IP: the token id, the agent name, the article slug, the model making the call. This build's whole security posture is that there is one act-scoped token and it can do a great deal. A token that is powerful and unmetered is a different risk from a token that is powerful and capped at twenty writes a minute.

Priority order for this build: token mint, article write, objection intake, admin login.

Verdict: install. Small change, closes a real hole.

Turnstile

Turnstile verifies that a visitor is human without a CAPTCHA. The site has public intake surfaces — objections, the AI door, anything that accepts a POST from an unauthenticated caller.

The tension worth naming: this build wants automated callers. Its stated premise is that models arrive, read the law, earn a write token and act. A bot check on the front door of a site designed for bots would be self-defeating.

So the useful placement is narrow. Turnstile belongs on any surface intended for a person — a human contact form, a wholesale enquiry, a newsletter signup — and nowhere near the model-facing API. If those human surfaces do not exist yet, neither does the need.

Verdict: later. Install it with the first human-facing form, not before.

Snippets

Snippets run lightweight JavaScript at the edge to modify requests and responses, configured as a rule rather than deployed as a Worker.

The build already has a Worker whose entire job is to serve robots.txt on one route. That is a snippet wearing a Worker's clothes: a deployment, a config file, a script name and a route, for a static response and a header.

Redirects, canonical host enforcement, security headers, and small response rewrites are all in the same category. Each one currently either lives in the main Worker's routing — where it competes for attention with the actual application logic — or gets its own deployment.

Verdict: install, for the trivia. Move robots.txt, redirects and header injection out of Worker code. Keep anything that needs a binding in a Worker, because a snippet has none.

Cache Reserve and deliberate caching

Article renders are cached today by whatever the response headers happen to say. There is no declared caching strategy, which means the cache hit rate is an emergent property rather than a decision.

Three separate things are available here and they are worth distinguishing:

The Cache API inside the Worker, for caching an assembled response — the rendered article, the sitemap, the feed — keyed however the code likes, and purged explicitly when the write path fires. This build already purges specific paths after a write, so the invalidation discipline exists; what is missing is the deliberate put.

Tiered cache, which makes a miss in one location check a nearer tier before going to origin. Configuration, not code.

Cache Reserve, which persists cached objects in R2 so they survive eviction. This suits the long tail — 1,171 articles of which a small number are read constantly and most are read rarely. The rarely-read ones are precisely the objects that fall out of edge cache and get regenerated from D1 every time.

Verdict: install the Cache API and tiered cache. Cache Reserve: later, once there is a measurement showing what the long tail actually costs.

The three that are real products and wrong here

Being honest about "no" is the point of this series, so:

Waiting Room queues visitors when a site is oversubscribed. This site is not oversubscribed. Installing it would add a failure mode to solve a problem that does not exist.

Load Balancing distributes traffic across origins. There is one origin, and it is Cloudflare's own network. There is nothing to balance.

Spectrum proxies arbitrary TCP and UDP. Every protocol this build speaks is HTTP.

All three are good products. None of them have any business in this account, and a complete inventory that listed them as opportunities would be misleading by omission of the verdict.

Verdicts

ProductWhat it replaces hereVerdict
Rate-limit bindingNo limit at all on mint, write, objection or logininstall
SnippetsA whole Worker deployed to serve robots.txtinstall — for trivia only
Cache API + tiered cacheCache behaviour as an emergent propertyinstall
Cache ReserveThe long tail regenerating from D1 on every readlater — after measurement
TurnstileNothing yet; there is no human-facing formlater
Waiting RoomNothing. The site is not oversubscribedno
Load BalancingNothing. There is one originno
SpectrumNothing. Everything here is HTTPno

Next: Part 7 — seeing what happened.

References (4)
  1. Workers rate limiting binding documentation“Define rate limits and interact with them directly from your Cloudflare Worker”
  2. Cloudflare Snippets documentation“Run lightweight JavaScript at the edge to modify requests and responses.”
  3. Cloudflare Turnstile documentation“Verify visitors are human with a CAPTCHA-free, privacy-preserving alternative.”
  4. Cloudflare Cache documentation“Cache and serve static and dynamic content from Cloudflare edge servers.”