The first JavaScript runtime that isolates every end user.
Every other JavaScript runtime pins work to a per-core heap and runs many end users through it. DataVec draws the isolation boundary one level finer — around each connection — so no two end users ever share a heap. It’s the property that makes the security and the efficiency claims on this page true at the same time.
Every other runtime
One shared heap per core
V8 isolates · Node · Deno · Bun
User A
User B
User C
shared heap · one CPU core
Shared blast radius.A bug or a leak in one request can reach another user’s data in the same heap, and one runaway request stalls the others sharing that core.
DataVec
One isolated process per connection
a memory-walled virtual kernel process · per end user
User A
own heap
User B
own heap
User C
own heap
Contained blast radius.Each end user gets a hardware-walled process with no cross-connection heap and no shared globals. A crash or compromise is reaped with that one connection — it never spreads across your traffic.
Same resident, always-warm pool of processes either way — the difference is where the wall sits: around the core, or around each end user.
Compiled to C. Caged by the kernel. Blind to your secrets.
The first question about compiling JavaScript to C is “how is that secure?” — but the thing protecting you was never the language. It’s the cage around it. On DataVec that cage is kernel-enforced and tighter than the V8 process you run today: your Worker can’t make a syscall it wasn’t granted, and your secrets never enter it at all. Compiling to C confines your code harder than the runtime you came from, not less — and per-end-user isolation draws a boundary no other JavaScript runtime does.
Your Worker can’t make a syscall it wasn’t granted
Every Worker runs under Syscall User Dispatch with a narrow, kernel-enforced allow-list. Try to open a file, spawn a process, or dial a socket it wasn’t granted and the kernel traps it and reaps the process — there’s no library policy to bypass.
Least privilege at the OS
Each Worker is pledged to a minimal set of operations and unveiled to only the exact paths it needs. Its filesystem and capability surface is cut to near-zero before a line of your code runs — the OpenBSD security model (pledge and unveil), enforced on Linux.
Your secrets never enter your code
Database passwords, API keys, and per-upstream tokens live in the host. It attaches them to requests on your Worker’s behalf — your JavaScript never holds a secret it could log, exfiltrate, or redirect to another host. A compromised Worker can’t leak what it never sees.
Capabilities are off until granted
SQL, object storage, email, outbound fetch, and AI streaming are denied by default and enabled per service. Least privilege is the default, not an opt-in. Revoke a capability and the Worker’s await fail-closes instantly — no redeploy.
Every end user runs in their own isolated process
This is a first for a JavaScript runtime. Every other runtime — V8 isolates, Node, Deno, Bun — multiplexes many users through one shared heap per core; a bug or a leak in one request can reach another user’s data in that same heap. DataVec gives each connection — each end user — its own memory-isolated virtual kernel process: a hardware-walled micro-heap, no cross-connection heap, no shared globals. Within a connection the handler and its pooled database session are reused across requests — no per-request startup — and a crash or compromise is contained to that one end user’s process and reaped, never spreading across your traffic. A syscall violation reaps only that connection; the others are untouched. If the virtual kernel itself panics, the whole kernel restarts.
You never hand-write the C
The JS→C lowering is content-addressed, API-grounded, and behaviorally gated — a faithful, tested lowering of your JavaScript over bounded region allocation, not arbitrary C. You get C’s speed without ever touching C’s manual-memory footguns.