How fuast runs little apps safely: V8 isolates

A small cloud runs a lot of little apps for a lot of different teams, all on the same infrastructure. That is the whole pitch: you write a fifty-line tool and we run it for you. But it raises an obvious question the moment you think about it. If my expense tracker and your competitor's hiring tool run on the same machines, what stops one from reading the other?

The answer is not a policy or a promise. It is the runtime. Every fuast capsule runs inside a V8 isolate, out of process, and every app is served on its own subdomain origin. Two walls, each doing a different job. Here is what each one is and why we chose it.

What a V8 isolate actually is

V8 is the JavaScript engine inside Chrome and Node. An isolate is a separate execution context inside V8: its own heap, its own memory, its own globals. Code in one isolate cannot reach into another's memory. It cannot see another's variables. There is no shared object graph to walk. It is the same mechanism a browser uses to keep two tabs from reading each other.

When a capsule's server code runs, it runs in an isolate that holds only that app's state. The database handle it gets, the secrets in ctx.env, the storage keys, all of it is scoped to that one app. There is no ambient access to a neighbor because the neighbor is a different context entirely.

Isolate vs container, honestly

The usual way to run untrusted code is a container: a slice of Linux with its own filesystem and process space. Containers are a heavier, more general boundary, and they are genuinely strong. So why isolates?

Two reasons, and one honest tradeoff.

• Startup. A container cold-starts in seconds. An isolate starts in milliseconds. When you run thousands of small apps that each get traffic in bursts, the difference is the product. Isolates are why a rarely-used tool can sleep and wake instantly instead of costing you an always-on box.
• Density. Isolates are cheap enough that a shared cloud can host far more small apps per machine, which is exactly the shape of small software: many tiny things, most of them idle.
• The tradeoff. An isolate is a narrower boundary than a container. It is a JavaScript boundary, not a kernel one. So fuast does not stop at the isolate. The capsule contract itself is locked down: server/ code may import only fuast/server, there are no Node builtins, and there is no filesystem or arbitrary network to reach for. A capsule cannot open a socket to a neighbor or read a file off the host because the contract never hands it those tools. And each app runs in its own process, so a crash or a runaway loop is contained too. The isolate is the memory wall; the restricted contract and separate process are the rest of it.

We are being specific on purpose. "Isolated" is a word every platform uses. The honest version names the boundary and the parts that back it up.

The subdomain origin: the wall your browser enforces

The isolate keeps apps apart on the server. There is a second attack surface people forget: the browser.

Every deployed app is served on its own subdomain, your-app.fuast.com, which is a separate web origin from the dashboard and from every other app. This matters because the browser's same-origin policy is tied to the origin. Because each app lives on a different origin, its JavaScript cannot reach into your fuast session and call account APIs on your behalf. A tool someone shared with you cannot quietly use your logged-in identity against the dashboard, because to the browser it is a different site.

That is subdomain isolation, and it is doing work the server-side isolate cannot. The isolate stops one app's server from reading another's data. The subdomain origin stops one app's client-side code from riding your session. You need both, because the two threats live on two different sides of the wire.

Why this is the boring part, and should be

The best thing a security model can be is uninteresting. You write a capsule, your AI writes a capsule, it deploys, and it runs next to a hundred others without you thinking about any of this. Multi-tenant by construction, not by a checklist someone has to remember to follow.

That is the deal a small cloud has to make to be worth using: run everyone's little apps together, cheaply, and keep them apart by default. Isolates plus a locked-down contract plus per-app origins are how fuast holds up its end.

Want to see a capsule of your own running behind that wall? Deploy one and share it with your team.