Cloudflare Workers in Anchorline

I tend to favor boring infrastructure. Boring usually means predictable, debuggable, and hard to accidentally break. Most of Anchorline follows that rule, but one place where I intentionally added complexity was at the edge, using Cloudflare Workers.

The Setup

First it's important to know that Anchorline has a lesser-known capability where every user can have their own subdomain and publish public logs. These public logs are meant to be shareable, fast, and cheap to serve. At the same time, the private Anchorline API is locked down behind Cloudflare Access, and the public pages are served by a simple Node app running on Cloudflare Pages.

Because all of this lives in the same Cloudflare Zone, I was able to introduce a Worker that sits in front of every request and acts as the traffic coordinator.

Routing at the Edge

So now when a request comes in for something like xyz.anchorline.io, it hits the Worker first. The Worker determines whether that subdomain is public, where it should be routed, and whether it should be proxied, rejected, or passed through untouched. Not all subdomains are public, and handling that distinction at the edge keeps the application code simpler and safer.

Now a bit about caching since this has been a bonus byproduct of how this worker is setup. All user public subdomains are cached at the edge indefinitely. When data backing a public log changes, the cache is explicitly purged and immediately repopulated on the next request. The result is that public pages serve almost entirely from cache, and the backend API only sees traffic when data actually changes. This keeps bandwidth usage low and removes load from the API without introducing stale data issues.

I am intentionally skipping the detailed caching mechanics here, because they deserve their own post. The important point is that the Worker makes the rules explicit. Nothing is cached by default, and nothing is uncached by accident.

Worker Routes

One critical detail that made this setup reliable was careful use of Worker Routes. The Worker only runs on the routes it is responsible for, and is explicitly disabled on paths and subdomains where it should not interfere. Without this scoping, it is easy to create subtle bugs where edge logic leaks into private or internal traffic not to mention you quickly end up paying for requests that are entirely unnecessary. By removing them from the route you cut them off before they hit the worker and cost you a request.

Conclusion

This setup has taken many iterations to get right. It is slightly less boring than pure app-level routing or static rules, but in practice it has been stable and easy to reason about. More importantly, it keeps edge concerns at the edge, instead of spreading routing and caching logic across multiple codebases and dashboards.

So far this additional complexity has far outweighed the downsides.