Isolate

A single server in a data center rarely runs the programs of just one company. Usually, many customers share the same machine without knowing about each other. So that none of them can read the others' data, each program needs its own, sealed-off workspace. Exactly such a workspace is called an isolate: its own memory space plus its own variables, from which the program cannot break out. The term originates from the software V8, the engine that executes JavaScript code in Google's Chrome browser. You can think of an isolate like a private office in a large office building: its own desk, its own files, but shared heating and a shared power grid.

Why providers save on entire servers

Before isolates, there were mainly two ways to separate third-party programs from one another. One is the virtual machine: a complete, simulated computer with its own operating system. The second is the container, a leaner variant of this. Both are secure, but cumbersome. A virtual machine often needs several hundred megabytes of memory and takes seconds to start.

An isolate gets by with just a few megabytes and is ready in about five milliseconds. That sounds like a technical detail, but it changes the business model. A provider can keep thousands of isolates running simultaneously on one machine instead of a few dozen virtual machines. This drastically lowers the cost per customer.

What happens at startup also matters. With virtual machines, there’s the so-called cold start: if no request comes in for a while, the machine is shut down and has to boot up again. The first user then experiences a noticeable wait. Isolates start so quickly that this problem is hardly noticeable in practice.

One engine, many desks

The trick lies in what is shared and what isn’t. All isolates on a server use the same program engine, meaning the same installed software that translates and executes the code into machine instructions. Only the workspace is individual per isolate: its own memory, its own variables, its own objects. That’s why an entire operating system doesn’t need to be dragged along for every customer.

The engine itself handles the isolation. It simply prevents code from one isolate from addressing a memory location belonging to another. In addition, each isolate is given hard upper limits, such as 128 megabytes of memory and just a few milliseconds of compute time per request. A program stuck in an infinite loop gets terminated and doesn’t block its neighbors.

This design also comes at a price. An isolate is not a complete computer, so it cannot run just any program. Usually you’re limited to JavaScript or WebAssembly, a compact format into which other programming languages can also be compiled. Anyone wanting to run a classic database or an old legacy company application still needs a container or a virtual machine.

Isolates in cloud offerings and in practice

Isolates became best known through Cloudflare Workers. There, you upload a small program that then runs in isolates in data centers all over the world. The code is executed close to the user instead of in a single central data center. Similar approaches can be found at Deno Deploy and in parts of Vercel.

Isolates also show up in AI services. There, they typically handle the work surrounding the actual model: checking requests, authenticating users, caching responses. The large language model itself still runs on specialized graphics processors, not in the isolate.

A common misconception is that isolates are just as secure as virtual machines. That’s not quite true. With a virtual machine, hardware provides an additional layer of separation, whereas with isolates, you rely solely on the correctness of the program engine. Bugs in this software can, in principle, undermine the separation, which has occasionally happened in the past. Providers therefore add further layers of protection on top.