Edge workers are powerful precisely because they are constrained. Those constraints are not incidental — they are what makes per-request instantiation, isolation, and predictable latency possible. Designing within them is the difference between a worker that helps and one that becomes a hidden origin load. See Edge Workers overview for the execution model.
Runtime constraints
A worker executes under hard limits on time, memory, CPU, and outbound work. The exact numbers vary by platform and plan, so verify them before you rely on them, but the categories are always the same:
- Wall-clock time per invocation. Long enough for a token check or a small fetch, far too short for media processing or a chain of dependent network calls.
- Memory. WebAssembly gives each instance a bounded linear memory. Loading a large library or buffering a big body will hit the ceiling.
- CPU. Bounded to keep one tenant from starving others. Expensive crypto or regex over large inputs can trip it.
- Subrequests and concurrency. The number of outbound fetches and their concurrency is limited. Each one adds latency you own.
- Payload size. Request and response bodies are capped. Workers are for shaping requests, not for moving objects.
Design rule: keep the worker on the request path, not in the data path. If a worker needs to read a full video segment or call three services, move that work behind the cache or into your origin.
Edge KV and cache for state
Workers are stateless between invocations; anything that must persist goes to a store:
- Edge KV is a globally distributed key-value store for small, read-heavy values: feature flags, policy tables, public keys, redirect maps, allow/deny lists. Reads are fast and local; writes propagate with eventual consistency, so never use KV as a strongly consistent counter or lock.
- Edge cache holds cacheable HTTP responses. A worker can read from and write to the cache, which is useful for short-lived computed responses — a signed manifest, a small JSON policy document — as long as you set a correct TTL and key.
Use append-only event streams, not read-modify-write on KV, for anything that must not lose updates. The idempotency concerns in Edge Workers use cases apply directly here.
Secrets management
Never embed secrets in the worker bundle. Bundles are distributed widely and are easy to leak through logs, source control, or a debug endpoint. Instead:
- Store signing keys, API tokens, and shared secrets in the runtime’s secret store, injected as environment bindings at invocation time.
- Rotate on a schedule and support two valid keys during rotation so you can roll without rejecting live tokens.
- Scope secrets per worker and per environment; a staging worker should never hold production signing material.
- Treat a secret that has ever appeared in a log or a bundle as compromised and rotate it.
Runtime configuration
Keep policy out of code so you can change behaviour without a redeploy. Put versioned config — geo rules, redirect tables, experiment weights, allowlists — in KV or a small cached object, read it at the top of the worker, and fail safe if it is missing. A worker that cannot read its config should fall back to a conservative default (usually “serve normally” for delivery, “deny” for access control), never to an open or undefined state.
Data-handling caution for adult workloads
Adult platforms carry sensitive traffic: viewer identity, viewing behaviour, payment adjacency, and sometimes age-verification data. That shapes what should ever pass through an edge worker:
- Minimise what you touch. Validate a token, don’t decode and log the viewer’s identity. Process a hash, not the raw identifier.
- Do not log sensitive values. Request logs and worker logs are widely accessible and long-lived. Redact tokens, cookies, and any personal data before they reach a log sink.
- Keep regulated data out of edge state. Age-verification records, identity documents, and payment data belong in systems built for them, not in edge KV or a worker cache.
- Be explicit about retention. If a worker records an event, define how long it lives and who can read it. Edge caches with long TTLs can outlive the reason they were written.
Compliance obligations — age assurance, consent, record-keeping, and lawful processing — remain the customer’s responsibility. The edge should process the minimum data needed to enforce the policy you set.
Where AdultInfra fits
AdultInfra designs worker configuration and storage patterns that respect runtime limits and keep sensitive data off the edge unless it must be there. See Edge Workers use cases for the patterns, or contact us to review a specific worker against your data-handling requirements.