Cloudflare Workers use V8 isolates as the main boundary between tenants, with many isolates sharing one process. Cloudflare then adds layers: trust based grouping, process level sandboxes for some Workers, restricted timers and no filesystem. This is the provider's description of its design, not a guarantee, and your own code remains your responsibility.
Isolates, in plain terms
A V8 isolate is a separate instance of the JavaScript engine's heap and execution state. Cloudflare's security model page says isolates are the primary boundary, and that many isolates share a single process, which is how thousands of tenants fit on one machine.
That density is the reason isolates start fast. It is also why the provider layers extra defenses: a flaw in the engine would be more serious than a flaw in a container boundary.
The layers Cloudflare lists
- Trust levels. Each Worker gets a trust level, and low trust Workers are placed in separate groups, so an engine zero day has less reach.
- Process level isolation. Workers that use certain features, such as the devtools debugger, run in their own process with a sandbox. A second layer uses Linux namespaces and seccomp to block filesystem and network access, with communication over local UNIX domain sockets.
- Restricted timers. The value from Date.now is locked while code executes, so code cannot measure its own run time. No other timers, multithreading or shared memory are available.
- Spectre mitigations. Cloudflare states there is no official fix for Spectre, so it layers mitigations: only JavaScript and WebAssembly are accepted, Workers with suspicious performance metrics are moved into their own process, and the runtime is periodically restarted and Workers rescheduled across machines.
- No filesystem, HTTP only. Workers have no filesystem API. Outbound requests pass through a local proxy that blocks internal addresses.
The page also describes runtime patching: when a V8 patch is published, Cloudflare builds a new release and, after one click sign off from reviewers, pushes it to production, with a patch gap under 24 hours.
One scope note worth remembering
The page says these facts apply to hosted Workers on Cloudflare. A local workerd process lacks some of the defense in depth protections. So do not copy the production threat model onto a self hosted workerd deployment without checking.
What this means for your threat model
- The provider owns engine patching and tenant isolation. You do not patch V8.
- You still own your code, your dependencies, your secrets and your bindings. A vulnerable package in a Worker bundle is exploited inside your isolate, regardless of how strong the wall around it is.
- Reduced timers and no native binaries limit what attackers can do in a compromised Worker, but they do not stop data theft through the bindings you gave it.
A reasonable stance: trust the platform to isolate you from others, and spend your own effort on what the platform cannot see.
Quick check
Is an isolate the same as a container?
No. Isolates share a process and run inside the JavaScript engine, which is why Cloudflare adds extra sandboxing layers around them.
Does isolation protect me from a vulnerable dependency?
No. It separates tenants from each other. A vulnerable package still runs with your Worker's bindings and secrets.
Safeguard's SBOM and dependency scanning, with a free scan, covers the part of the stack you own.
Sources
Last reviewed: 19 October 2026.
