JavaScript at C-speed. Billed by the hour, not the request.
The first JavaScript runtime that isolates every end user. Every other runtime — V8 isolates, Node, Deno, Bun — multiplexes many users through one shared heap per core. DataVec gives each connection its own memory-isolated virtual kernel process: a smaller blast radius than any runtime you can buy, on hardware efficient enough to undercut self-hosting.
A full platform for high-volume JavaScript backends. Write JavaScript, deploy normally, and we compile it to optimized C, keep it resident in memory, and scale it for you — then bill you for the actual infrastructure it uses: VM-time, cost-plus. No per-request, per-duration, or bandwidth metering. A managed platform, priced like the servers underneath it.
Edge functions with cloud-function semantics.Your code terminates the request on the machine — no proxy tier in front, running at the network edge — but with the full runtime a cloud function gives you, not the stripped-down edge subset. And it’s fast on every axis at once: no proxy hop, native compiled C, resident with no cold start, lockless execution, and no GC pauses. By “edge” we mean exactly that — no proxy in front, not hundreds of global locations. We run multi-region, and we’re adding more.
You write the standard Web Worker API — fetch(request, env), Request/Response, Web Crypto — plus a static site. Built on native coroutine scheduling for massive vertical scaling.
Next.js Static Routing
Processes a complex nested endpoint router with custom JSON payload returns.
Compiled & resident
Compiling JavaScript into native C stateful coroutines yields direct machine execution speed.
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, isolating each end user, and reusing pooled Postgres and S3 object storage with no per-request startup.
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 its pooled Postgres session is reused across requests: isolation per end user, no per-request 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.
Same Worker API you write for
Cloudflare Workers
Deno Deploy
Vercel Edge
Fastly Compute
Netlify Edge
Per-user
Isolated per connection, not per core
Resident
No cold starts
Native C
Compiled execution
VM-time
Billed as infrastructure, cost-plus
Direct comparison & capabilities showcase
DataVec replaces virtualized serverless runtime layers with compiled execution. Explore our billing, API standard compliance, and supported frameworks below.
Billing & Cost Comparative Metrics
Comparing infrastructure-priced VMs vs utility-metered edge networks.
DataVec compiled C
Billing unit
VM-time, cost-plus
Starter bill
$17.00 / mo
Bandwidth fees
Included ($0)
Cold starts
None (resident)
Isolation
Per end user
Cloudflare Workers
Model
Metered requests
Starter bill
$5.00 / mo
Bandwidth fees
Free
Cold starts
V8 isolate warmup
Isolation
Shared per core
Vercel Edge
Model
Metered CPU + Seats
Starter bill
$20.00 / user / mo
Bandwidth fees
$0.15 / GB metered
Cold starts
Subprocess boot delay
Isolation
Shared per core
Coming from Cloudflare Workers or Vercel Edge.
You write the same handler you write there — export default { async fetch(request, env) } — against the same web-standard objects, and your bindings map straight across. Your repo builds the way it already does, then compiles to native code. Here is exactly what you get.
Binding map
| Cloudflare | DataVec | |
|---|---|---|
| D1 (SQL) | env.DB | same prepare().bind().first()/.all()/.run() shape |
| R2 (object storage) | env.BUCKET | get / put / list / delete |
| KV | env.KV | get / put / list / delete, with TTLs |
| Queues | env.QUEUE | send from a handler; a queue() entrypoint consumes |
| Durable Objects | env.DO | per-object storage — get / put / list / deleteAll, isolated per object id |
| Workers AI | env.CONVERSATION | streaming model tokens (SSE) |
| Hyperdrive / Postgres | env.SQL | managed Postgres over the wire protocol |
| WebSockets | websocket entrypoint | RFC 6455 + RFC 8441, in and out |
Locality
Elsewhere, “where does this live?” is decided for you, differently by each product. Here it is one choice you make per binding, in the same words every time — because the honest answer depends on how many machines your service runs on.
connectionLives in the connection and dies with it.
Per-end-user scratch and caching, inside the isolate that serves that one connection. No syscalls, nothing shared, nothing to clean up.
instanceDurable on this machine.
A SQLite file on the VM serving the request. Fast and durable — and when you run replicas, each has its own copy, so it is a cache rather than shared truth. That is the default, and we say so rather than letting you discover it.
serviceOne source of truth for the whole service.
A designated primary owns the data and every replica reads and writes through it — the scope a Durable Object is unique across. Promotion is deliberate and fenced: writes fail rather than letting two machines both believe they are primary.
A binding that asks for service-wide state and quietly gets per-machine state has been handed the wrong guarantee, so we refuse that rather than downgrade it silently. Durable Objects go further and require you to say the scope outright — the scope an object is unique across isits locality, and inheriting a default would mean “unique per replica,” which is not a Durable Object at all. That one refuses to start on a default rather than guess.
✓ Runs today
Your build, unchanged
we run bun install && bun run build on your repo — the same toolchain and dependencies you already use
fetch() over HTTPS
outbound requests from your handler, TLS included
Request / Response / Headers / URL
the same objects you write against today
Streams
ReadableStream, WritableStream, TransformStream — plus CompressionStream
Web Crypto
SHA-2 digests, HMAC, AES, and ECDSA P-256 — compiled to native code
Server-sent events
chunked + SSE streaming, the AI-gateway shape included
WebSockets
RFC 6455 over HTTP/1.1 and HTTP/2 (RFC 8441), inbound and outbound, Autobahn-tested
SQL + object storage
env.DB (D1-shaped), env.SQL (Postgres), env.BUCKET (R2-shaped)
Automatic TLS
point a domain at it; certificates are issued and renewed for you
◷ Coming next
Serialized execution for Durable Objects
an object’s storage is already isolated per id; the input gate that also serializes requests for one object is built and tested, and is being wired into dispatch now
Locality on every binding
each interface above is getting the full range of scopes to choose from
Timers and AbortController
landing as the runtime surface widens
✗ Not a goal
Node.js APIs. No fs, child_process, net, or native addons — same as Cloudflare Workers and Vercel Edge. If your code runs on their edge runtimes, it isn’t relying on these either.
Porting something specific and want to know where it stands? Ask us— we’ll tell you straight, before you spend a day on it.
The Compiled Edge Deployment Pipeline
Explore the pipeline phases to inspect how standard JavaScript code is compiled, linked, and hosted on our native edge network.
Visualizing compiler & runtime efficiency
DataVec replaces the virtualization stack — VM, language engine, garbage collector — with an M:N virtual kernel: a userland kernel, written in C, that isolates and memory-protects each connection in-process, with no language VM and no WebAssembly. Hover over the symbol map and stack diagrams below to inspect the design.
Source-to-Native Translation Showcase
At deploy time, the DataVec Builder translates your standard JavaScript into idiomatic native C, lowering each construct onto a hand-tuned native equivalent — so nothing interprets your code at runtime. A few of those mappings:
JavaScript Source
Compiled C Target
→ Hover over any JavaScript or C node above to inspect compiled symbols.
Virtualization Layer Comparison
Standard serverless stacks execution layers — a VM, a JIT engine, a garbage collector — each adding latency and cache pressure. DataVec compiles your service into a standalone virtual kernel daemon that aligns data layout with code layout, so it cache-misses far less and saturates cheaper hardware than a garbage-collected engine needs — and because it’s lockless and soft-real-time, there’s no GC pause and a flat latency tail.
DataVec compiled C
Single self-contained binary
No per-invocation cold starts
Virtualized Edge Isolate
Multi-layer runtime stack
Cold start on scale-up
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.
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.
Pick a VM size and your level of management
Choose a VM size, then choose how hands-on you want to be — a single server, reserved replicas, or auto-managed scaling. Every option ships the full platform and bills the same way: by VM-time, cost-plus. Your management level is your call; it doesn't change how you're billed.
Deploy in San Francisco · New York — same price in every region, your choice of location.
To launch: sign up (a one-time $1 verification), connect a Git repository(required — that's the app we build and run), and pick a size + region + management level. Your app builds and goes live at <name>.apps.datavec.comwith automatic HTTPS, and you're billed monthly for the VM-time it uses.
Spec your machine
Set the vCPU and memory you need; we match the DigitalOcean VM that meets it and price it cost-plus. No named tiers — you pay for the machine.
vCPU cores
1
Memory (GB)
1 GB
Need something bigger, dedicated CPU, or single-tenant hardware? That's a custom build — see Enterprise below.
Your machine
$17
/month
A dedicated 1-vCPU VM with 1 GB RAM and 25GB SSD — your app stays resident. That's one VM for a full month; you're billed for the VM-time you actually run, cost-plus, and your management level doesn't change it.
- Dedicated VM — your app resident in memory, no cold starts
- Custom domain registration + automatic HTTPS
- Full WebSocket & HTTP/2 protocol support
- Postgres wire connections in isolated sandboxes
- R2-compatible S3 object store worker
- Billed by VM-time, cost-plus — no per-request or bandwidth metering
vCPU
1
Memory
1 GB
SSD
25 GB
💎 Enterprise
— Custom
Dedicated hardware isolation, sizing beyond the standard machines, dedicated-CPU or memory-optimized families, single-tenant routing, and a premium SLA.
Synthetic metering vs. VM-time, cost-plus
Configure your monthly footprint. We estimate the metered bill on your current serverless platform, then size the DataVec VM that serves the same peak load at our published per-core throughput — priced as VM-time, cost-plus, with no per-request or bandwidth metering. Add reserved replicas for redundancy if you want; they're billed the same way, by VM-time.
Peak load ~3,472 req/s
Provisioned ~8,000 req/s
Cloudflare Bill
$976/mo
Metered utility pricing
DataVec VM-time
$17/mo
1 × 1 vCPU / 1 GB · 1 vCPU
Saves $959/month · $11,513/year
Illustrative estimate using vendors' published list prices as of June 2026 (AWS includes API Gateway; Cloudflare has zero egress). The DataVec figure is the real catalog price of the VM capacity needed to serve your peak throughput — assuming a 12× peak-to-average burst — at our published single-core rates, with headroom, billed as VM-time (cost-plus). VM plans include generous egress — we don't meter bandwidth. Reserved replicas for redundancy are optional and billed the same way. At very high volume, metered platforms are often negotiated down with committed-use discounts, so compare against your actual invoice.
Every VM bills the same way — VM-time, cost-plus — from a Business VM at $80/mo down to a $17/mo Starter VM. No per-request or bandwidth metering, and your management level doesn't change the unit.