Edge Workers are small programs — JavaScript or Rust compiled to WebAssembly — that run at the edge inside the same request path that serves your CDN traffic. Instead of routing a request to an origin or a central function platform, the edge evaluates your code between the viewer and the cache, then decides what to serve, rewrite, block, or fetch. The workload is serverless: there is no host to patch, and capacity scales with request rate.
This page covers the execution model and where it sits relative to the delivery model described in the CDN overview.
Where workers sit in the request path
A normal CDN request is: viewer → edge cache → origin on a miss. A worker adds programmable points at that path without giving up the cache. Typical insertion points:
- On request, before the cache is consulted, so you can rewrite the path, normalise headers, or reject a request early.
- On cache miss, before the origin fetch, so you can alter the upstream request or serve a fallback.
- On response, after the cache, so you can add or strip headers and shape the response per viewer.
Because workers run per request and per edge location, they see traffic close to the viewer. That is the point: decisions that would otherwise need a round trip to a central service — a token check, a geo rule, a header fix — happen within the same edge hop.
Isolated runtime and cold starts
Each worker runs in an isolated sandbox with its own memory, no shared filesystem, and no ambient network access beyond the bindings and APIs you explicitly grant. WebAssembly gives the runtime a defined, capability-based boundary: a worker cannot read another worker’s state or reach a resource it was not configured to reach.
Startup is measured in microseconds to low milliseconds, not the hundreds of milliseconds typical of container cold starts. That matters for adult traffic patterns, which are bursty and geographically scattered: a promotion, a new release, or a live event can spike one region while others stay quiet. A runtime that instantiates per request absorbs that without a warm-up pool.
Language and build model
You can write workers in JavaScript or Rust. Rust compiled to WebAssembly suits CPU-bound work such as signing, hashing, or parsing; JavaScript suits request shaping and glue logic. The build produces a portable module that the platform distributes to every edge location. Keep modules small — instantiation cost and memory limits both favour lean code.
Integration with CDN features
Workers are not a separate delivery tier. They compose with the resource settings that already exist:
- Cache keys and cache control. A worker can influence what is cacheable and how it is keyed, which is where many adult-site cache problems start. See Cache control and cache keys.
- Access policy. Workers enforce or refine the access rules described in Edge access policy.
- Security. Workers can run lightweight bot or abuse checks inline, complementing the policies in Web application and API protection.
- Origin protection. Workers can add signed headers on origin fetches so a private origin only trusts edge traffic.
What workers are not
Workers are not a general-purpose application host. They are stateless request logic with tight time, memory, and CPU budgets. They are not a database, not a media processor, and not a place to run long-lived jobs. State that must outlive a request belongs in edge KV, cache, or your own origin. See Edge Workers runtime and storage for the constraints.
Adult-platform use cases at a glance
The highest-value uses on adult platforms tend to be small, deterministic, and close to the request: entitlement and token validation, geo and policy decisions, request normalisation, hotlink protection, redirects, experiment bucketing, and light personalisation. Each is covered with mechanics in Edge Workers use cases.
Where AdultInfra fits
AdultInfra designs worker logic that respects the runtime’s limits and keeps media on the cache path. Age verification, consent, likeness rights, and moderation decisions remain your responsibility; the edge enforces the policy you define. To scope a worker against a real traffic class, start with Platform or contact us.