Cloudflare OS: the edge in front

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.

[[unsafe.bindings]]
name = "MINT_LIMIT"
type = "ratelimit"
namespace_id = "1001"
simple = { limit = 20, period = 60 }

const { success } = await env.MINT_LIMIT.limit({ key: callerFingerprint });
if (!success) return json({ error: 'rate_limited' }, 429);

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

Next: Part 7 — seeing what happened.