Server
Isolate
Also called V8 isolate.
Isolate is a lightweight sandbox inside a V8 engine process that runs one tenant's JavaScript with its own heap. Cloudflare Workers use isolates so thousands can share a process without sharing memory.
How it is measured
You do not see an isolate directly. You see its effects: start times of a few milliseconds, a memory cap near 128 MB, and a CPU time limit per request. Platforms expose startup and CPU time in logs.
Compare against a container, which boots an operating system layer and takes hundreds of milliseconds to seconds. Isolate startup is measured in single-digit milliseconds.
Worked example
A redirect rule runs as a Worker on 2 million requests a day. Because each request can land on an already-resident isolate, the median run takes 0.6 ms of CPU. On a rare new isolate the code loads in about 5 ms, and the visitor does not notice.
The same logic as a container-based function on a regional platform showed a 1.2 second first hit after idle. The isolate model removed that cost, but capped each request at 50 ms of CPU.
How it differs
An isolate is a sandboxed JavaScript context inside a shared process. A worker is the program you deploy that runs inside one. The isolate excludes OS-level boundaries like a separate filesystem or arbitrary binaries. The worker excludes the memory management layer, it is only the code and its bindings.
Common errors
Assuming an isolate keeps state between requests. Writing code that needs Node built-ins the runtime lacks. Holding big objects in global scope and hitting the memory cap. Treating isolate cold start as zero. Forgetting that long CPU work is cut off.
In practice
If you use Workers or similar, log CPU time per request and keep under the limit with headroom. Keep global state tiny, store anything durable in KV or a database, and do not rely on a particular isolate being reused.