Cloudflare Workers as Privacy Infrastructure: Edge Computing for the Invisible

Cloudflare’s network processes over 57 million HTTP requests per second at peak. Each request is handled at one of 330+ data centers distributed across 120+ countries, within milliseconds of the end user. The compute layer that processes these requests — Cloudflare Workers — runs not on containers, not on virtual machines, but on V8 isolates: sandboxed instances of the same JavaScript engine that powers Chrome, each consuming less than 1 MB of memory and starting in under 5 milliseconds.

This architecture was designed for performance. It turns out to be the most privacy-preserving compute model in commercial cloud infrastructure — not by intention, but by the constraints of its design. Workers have no filesystem. They have no persistent memory between requests. They have no raw socket access. They cannot write to disk because there is no disk to write to. They cannot log to a file because there is no file system. They process a request, return a response, and the isolate’s memory becomes eligible for cleanup.

For organizations building zero-persistence infrastructure, these constraints are not limitations. They are the exact properties required by a compute layer that must leave no trace.

The V8 Isolate Model

Traditional serverless platforms — AWS Lambda, Google Cloud Functions, Azure Functions — run customer code inside containers. A container is a Linux process with its own filesystem, its own network namespace, and access to the full Linux system call interface. Lambda’s Firecracker micro-VMs add hardware isolation, but each invocation still operates within an environment that has a writable filesystem, persistent storage, and the full capabilities of a Linux process.

Cloudflare Workers replace all of this with a V8 isolate: a sandboxed instance of the V8 JavaScript and WebAssembly engine. The isolation model is fundamentally different from containers.

What an Isolate Has

• A JavaScript/WebAssembly execution environment. V8 compiles JavaScript to machine code and executes it within the isolate’s memory boundary.
• A fetch API. The isolate can make outbound HTTP/HTTPS requests through Cloudflare’s network stack. These requests exit through Cloudflare’s IP addresses, not the user’s.
• Web Crypto API. Full access to the Web Cryptography API, including AES-GCM, RSA, ECDH, HMAC, SHA, and PBKDF2. All cryptographic operations execute within the isolate’s memory.
• Bindings to Cloudflare services. KV (key-value storage with TTL), R2 (object storage), Durable Objects (coordinated state), D1 (SQLite at the edge), Queues, and AI (inference).
• CPU time. Paid plans provide 50 ms of CPU time per invocation (standard) or 30 seconds (unbound). Free plans provide 10 ms.

What an Isolate Does Not Have

• No filesystem. There is no /tmp, no writable directory, no file descriptor. The isolate cannot create, read, or write files on the host machine.
• No raw sockets. TCP and UDP socket access is unavailable. The isolate communicates over the network exclusively through the fetch API (HTTP/HTTPS) and WebSocket API.
• No process spawning. The isolate cannot fork, exec, or spawn child processes. There is no shell, no /bin/sh, no command execution capability.
• No system calls. The isolate runs inside V8, which runs inside a host process managed by Cloudflare. The isolate has no access to Linux system calls — no open(), no write(), no mmap(), no socket(). The attack surface is the V8 engine, not the Linux kernel.
• No persistent memory between requests. Global variables persist within a single isolate instance for the duration of its lifetime (which Cloudflare controls and can terminate at any time), but there is no guarantee of persistence between requests, and Cloudflare explicitly documents that isolate reuse is an optimization, not a contract.

The security implications are significant. The 450+ Linux system calls that constitute the attack surface for containerized workloads are entirely absent. Container escapes — the class of vulnerabilities that allow an attacker to break out of a container and access the host — are architecturally impossible because there is no container to escape from. The entire category of filesystem-based persistence (malware dropping binaries, creating cron jobs, writing to /etc/) is eliminated.

Privacy Properties of the Workers Runtime

Zero Disk I/O

Workers execute entirely in memory. No request data, no response data, no intermediate computation results, and no temporary files are written to any persistent storage medium on the host machine. This is not a configuration option — it is a structural property of the runtime. The V8 isolate has no API for disk I/O.

For zero-persistence architectures, this eliminates the most common data remanence risk in cloud computing: data written to temporary files, swap space, or log directories that persists after the process terminates. In a container-based runtime, a developer must actively prevent disk writes. In Workers, they must actively seek out an external service (KV, R2, D1) to persist anything at all.

IP Address Masking

When a Worker makes an outbound fetch request (for example, proxying a sanitized prompt to an LLM provider), the request exits through Cloudflare’s network — not the end user’s IP address. The LLM provider sees a Cloudflare IP address, not the user’s. This is IP-level metadata stripping by architecture: the user’s IP address terminates at Cloudflare’s edge and is not forwarded to the origin.

Cloudflare’s Anycast network means that the egress IP may correspond to any of 330+ data centers. The LLM provider cannot determine the user’s geographic location from the egress IP — the request may have been processed at the Cloudflare data center nearest the user, but the outbound connection to the origin may route through a different path.

For comparison, a Lambda function deployed in us-east-1 that calls an LLM API reveals its AWS region through the source IP. A Workers request reveals only that it came from Cloudflare — one of the world’s largest networks, handling over 20% of all web traffic.

Request Isolation

Each request to a Worker executes in its own isolate context. While V8 may reuse an isolate instance for multiple requests to the same Worker (for performance), each request begins with a fresh execution context. Variables from a previous request are not accessible to the current request unless explicitly stored in a Cloudflare persistence layer (KV, R2, Durable Objects) — which requires deliberate API calls.

This means that cross-request information leakage within the Worker is limited to global scope variables that persist across the isolate’s lifetime. A properly written Worker that does not use global mutable state provides per-request isolation without any additional engineering effort.

Compute-at-Edge Jurisdiction

Cloudflare Workers execute at the data center nearest the end user. A user in Zurich is served by Cloudflare’s Zurich data center. A user in Tokyo is served from Tokyo. The request data — including the decrypted payload, if the Worker performs decryption — exists in the jurisdiction closest to the user, for the duration of the request, and nowhere else.

This has jurisdictional implications. If a Swiss user’s request is processed at Cloudflare’s Zurich data center, the decrypted data never leaves Switzerland. It is processed in Swiss territory, in volatile memory, and destroyed when the request completes. No cross-border data transfer occurs for the computation itself.

Cloudflare offers Workers data localization controls (Jurisdiction Restrictions) that can constrain which data centers are eligible to process a Worker’s requests. A Worker configured for EU jurisdiction will only execute in Cloudflare’s EU data centers, ensuring that request data is processed exclusively within the European Economic Area.

Performance Characteristics

Cold Start

Workers cold start in under 5 ms. This is not the time to boot a VM, start a container, or load a runtime — it is the time to create a V8 isolate and compile the Worker’s JavaScript/WebAssembly code. V8’s TurboFan JIT compiler produces optimized machine code on the first execution, and subsequent requests to a warm isolate incur no compilation overhead.

For comparison, AWS Lambda cold starts range from 200 ms (Python, Node.js) to 2+ seconds (Java, .NET). Firecracker micro-VMs boot in under 150 ms. Workers are 30-400x faster than the nearest serverless competitors for cold start latency.

The privacy implication: faster cold starts enable shorter-lived compute environments. If a Worker can spin up, process a request, and terminate in 50 ms total, the window during which decrypted data exists in memory is 50 ms. A Lambda function that takes 500 ms to cold start has a 10x longer exposure window before the first byte of useful work is even processed.

Global Latency

Cloudflare’s Anycast routing directs each request to the nearest data center, where the Worker executes. For a globally distributed user base, this means sub-50 ms Time to First Byte (TTFB) for the Worker’s computation, before the origin (LLM provider) latency is added.

Stealth Cloud’s zero-trust architecture benefits from this: authentication (wallet signature verification), payload decryption, and PII stripping all execute at the edge in under 10 ms, before the request is proxied to the LLM provider. The user perceives the LLM’s response latency, not the overhead of the privacy layer.

Throughput

Workers handle millions of requests per second globally, with automatic horizontal scaling. There is no capacity planning, no autoscaling configuration, no instance warming strategy. Each request is handled by the nearest available isolate, and Cloudflare manages the global pool of isolates transparently.

For burst workloads — which characterize chat applications where usage spikes at certain hours — Workers’ instantaneous scaling eliminates the cold start storms that plague container-based autoscalers.

Workers vs. Traditional Serverless: A Privacy Comparison

The distinction in log persistence is critical. Lambda logs every invocation to CloudWatch by default — including duration, memory usage, and any console.log output. Disabling logging requires explicit IAM policy changes and loses operational visibility. Workers emit no logs by default. Logging must be explicitly enabled via Logpush or Tail Workers, and the developer controls exactly what is logged.

For zero-persistence workloads, the Lambda default (log everything) is the opposite of the required behavior (log nothing). The Workers default (log nothing) aligns with the privacy architecture without requiring active countermeasures.

Durable Objects: Coordinated Ephemeral State

Workers are stateless by default. For applications that require coordinated state — real-time chat sessions, WebSocket connections, collaborative editing — Cloudflare provides Durable Objects: single-threaded, addressable compute instances with transactional storage that are co-located with a specific data center.

A Durable Object has:

• A unique ID. Addressable by name or generated ID.
• In-memory state. JavaScript variables that persist for the lifetime of the object (which ends when the object is evicted after a period of inactivity, typically 10-30 seconds).
• Transactional storage. A key-value store with ACID semantics, co-located with the object.
• WebSocket support. The object can accept and manage WebSocket connections, enabling real-time bidirectional communication.

For ephemeral chat sessions, Durable Objects provide the coordination layer: the object holds the active WebSocket connections for a chat session, manages the session state in memory, and is destroyed when the session ends. The transactional storage can be used for session metadata (model selection, burn timer configuration) with aggressive TTLs, ensuring that the storage is automatically deleted after the session expires.

The privacy property: a Durable Object’s state exists at a single, known location (the data center where the object is instantiated). When the object is destroyed — either by explicit deletion or TTL expiration — the state is removed from that single location. There is no replication to other data centers, no backup to a separate region, no WAL archive that persists indefinitely. The state has a single copy, in a single location, with a defined destruction time.

WebAssembly on Workers: Client-Side Logic at the Edge

Workers support WebAssembly (WASM) execution alongside JavaScript, enabling compute-intensive tasks — PII detection, data tokenization, format-preserving encryption — to run at native speed within the isolate’s sandbox.

A WASM module loaded into a Worker inherits the isolate’s security properties: no filesystem, no system calls, no raw sockets. The WASM module communicates with the JavaScript host through imported/exported functions only. A PII detection model compiled to WASM can scan text for personally identifiable information, replace detected entities with tokens, and return the sanitized text — all without any network capability, any persistence mechanism, or any access to data outside the function’s parameters.

This is the model Stealth Cloud uses for server-side PII verification: a WASM module running within the Worker isolate performs a secondary PII scan on the decrypted prompt (after the client-side scan) as a defense-in-depth measure. The WASM module has no ability to exfiltrate the data it processes, because it has no network access. It receives text, returns sanitized text, and has no side channel for leaking the input.

The Trust Model: What You Trust When You Use Workers

Using Cloudflare Workers requires trusting Cloudflare to:

1. Isolate your code correctly. V8 must enforce memory isolation between isolates. A V8 vulnerability that allows cross-isolate memory access would compromise the isolation model.
2. Not inspect your data. Cloudflare’s network terminates TLS. Cloudflare’s infrastructure has access to the decrypted request during processing. Cloudflare employees with production access could theoretically inspect request data.
3. Not persist your data. Cloudflare states that Workers do not log request/response bodies by default. This is a policy, not a cryptographic guarantee.
4. Comply with its stated data handling practices. Cloudflare is a U.S.-incorporated company subject to U.S. legal process, including FISA Section 702 and the CLOUD Act.

These trust requirements are real and should not be minimized. Cloudflare is a more privacy-aligned choice than AWS, Azure, or GCP for several structural reasons — it does not operate an advertising business, it does not offer data analytics services, and its business model (network security and performance) does not benefit from customer data analysis — but it is still a trusted third party.

For Stealth Cloud’s architecture, the mitigation is defense in depth: data arriving at the Worker is encrypted with AES-256-GCM keys held by the client. The Worker decrypts in the isolate’s memory, processes the request, and re-encrypts the response. Even if Cloudflare inspects the Worker’s memory during processing, the PII has already been stripped client-side. The Worker sees a sanitized prompt, not the user’s raw input. And the session key is destroyed when the request completes, making future decryption of any captured ciphertext impossible.

The Stealth Cloud Perspective

Cloudflare Workers are the compute backbone of Stealth Cloud’s zero-persistence architecture, and the choice was not a vendor preference — it was an architectural requirement.

The properties we need from a compute layer are: no filesystem, no default logging, sub-5 ms cold start, global edge distribution, built-in IP masking, Web Crypto API for AES-256-GCM operations, WebAssembly support for PII processing, and Durable Objects for ephemeral session coordination. No other commercial compute platform provides all of these properties simultaneously.

Lambda has a filesystem. Cloud Functions have default logging. Container platforms have system call surfaces. Traditional VMs have disk I/O. Each of these properties creates a data remanence risk that must be actively mitigated. Workers eliminate these risks at the platform level — the constraints of the V8 isolate model enforce the zero-persistence properties that other platforms require careful engineering to approximate.

The architecture processes each Ghost Chat request in a V8 isolate at the edge nearest the user: decrypt, verify, strip PII, proxy to LLM, re-encrypt, respond, destroy. The entire lifecycle completes in memory, at the edge, in the jurisdiction nearest the user, with no disk writes, no logs, and no persistent state. When the isolate’s memory is reclaimed, the computation might as well have never happened — and that is precisely the point. The best privacy infrastructure is the one where the infrastructure itself cannot betray the user, not because it chooses not to, but because it is architecturally incapable of doing so.