Your Worker code, compiled to native C. Billed like the VM it runs on.
Deploy JavaScript Workers and a static site from your Git repository. We compile the Workers to C, keep them resident with no cold starts, scale them for you, and bill the VM-time they use, cost-plus. No per-request, duration or bandwidth metering.
Every end user isolated, at event-loop speed.Each connection runs in its own memory-isolated process for as long as it stays open, scheduled like an event loop, so one user’s bug or breach stays with that user.
You write the standard Worker API — fetch(request, env), Request/Response, Web Crypto — as you would for Cloudflare or Vercel. See what carries over
Light compute
1 round of JSON parse, filter, sort, stringify
6,698
requests/s on 1 × 1 vCPU VM
1.6 / 9.2 ms
p50 / p99 latency
Compiled C with no interpreter and no garbage collector: the request path is machine code end to end.
No cold start · no interpreter · no GC pauses
A new execution model for JavaScript infrastructure.
Under the familiar developer experience is a genuinely different engine — an M:N virtual kernel written in C. Your compiled app runs as memory-isolated virtual kernel processes (protected in-process, with no language VM and no WebAssembly) inside a small pool of always-resident OS processes — terminating the connection and isolating each one, so each end user keeps one process, with its SQL and object-storage sessions open, for every request the connection carries.
Compile at deploy time
The DataVec Builder converts JavaScript/TS Web Workers and WebSocket endpoints into optimized C before production traffic hits your VMs.
Resident, isolated per connection
The DataVec Runtime keeps your compiled app loaded — no spin-up. Each connection runs in its own memory-isolated virtual kernel process (in-process protection, not a new OS process), and keeps it, with its SQL session open, for every request the connection carries: isolation per connection, and no cold start.
Billed by VM-time
You pay for the actual infrastructure your app uses — VM-time, cost-plus — never per-request, per-duration, or bandwidth. Choose how much management you want: a single server, reserved replicas, or auto-managed scaling — with no effect on how you're billed.
Porting from
Cloudflare Workers
Vercel Edge
Per-user
Isolated per connection, not per core
Resident
No cold starts
Native C
Compiled execution
VM-time
Billed as infrastructure, cost-plus
The full picture, one page at a time
The home page carries the argument. Each page below carries the proof for one part of it.
How it works
Compile at deploy, resident at runtime
→
The pipeline that turns your JavaScript into native C, and the M:N virtual kernel that runs it with no cold starts.
Compiler
How your JavaScript becomes C
→
The curriculum the compiler learns from, how every build is checked, and how you read the C each change produces.
Isolation & security
Process isolation at event-loop speed
→
Every end user gets a memory-isolated virtual kernel process. Your code is caged by the kernel; your secrets never enter it.
Comparison & migration
Against Workers and Edge, and how to move
→
Billing, isolation, and cold starts side by side — and what porting from Cloudflare Workers or Vercel Edge takes.
Pricing
Billed by VM-time, cost-plus
→
Pick a VM size and your level of management. Estimate your bill against per-request platforms with the calculator.
Benchmarks
The numbers behind C-speed
→
Throughput, latency and cost per million requests, measured on DataVec and priced against Cloudflare Workers.