Getting Started

Documentation

Deploy a standard project — a static site plus one or more JavaScript/TypeScript edge Workers — and DataVec compiles your Workers to native C and serves everything from a dedicated instance. No JS runtime ships to the edge. Fuller reference material is expanding; the API surface is on the reference page.

How a deploy works

Connect a Git repository from the console. At deploy time, DataVec:

clones your repository,
runs bun install && bun run build to produce your static site,
transpiles every handlers/*.js to native C and links them into the edge server,
serves it all from a dedicated instance at https://<your-slug>.apps.datavec.com.

Connect a repository

Project layout

A minimal project is a static site plus one Worker:

public/index.html   → your static site (built to dist/ by "bun run build")
handlers/hello.js   → an edge Worker, mounted at /api/hello
package.json        → the build script

Each Worker is a standard export default { async fetch(request, env) { … } } handler. Platform capabilities are provided through env bindings.

Platform bindings

HTTP & routing

Standard fetch / Request / Response, plus edge routers like Hono, Elysia, and itty-router.

env.DB — embedded SQLite

The Cloudflare-D1 API — prepare(sql).bind(...).first() / .all() / .run() — for in-process app data with no per-request reconnect.

env.SQL — Postgres wire

Query a managed SQL database over the PostgreSQL wire protocol, via named prepared statements, from an isolated sandbox.

env.BUCKET — object storage

S3/R2-compatible object storage (key → bytes): get, put, list, and delete blobs from a Worker.

env.CONVERSATION — AI streaming

Live model-token streaming: stream(url, prompt) resolves to a readable token stream for AI gateways.

WebSockets

Native RFC 6455 WebSockets over HTTP/1.1 and HTTP/2, inbound and outbound.

Crypto

Standard Web Crypto (crypto.subtle) compiled to native code — digests, HMAC, AES, ECDSA, RSA, Ed25519.

SSE & streaming

Server-sent events and chunked streaming responses, the AI-gateway shape included.

API reference

Security model

How a compiled Worker is confined

Compiling to C does not widen your attack surface — it runs inside a sandbox stricter than a V8 isolate. The security boundary is the process cage, not the language, and every Worker is confined the same way regardless of what it compiles from:

Syscall confinement.Each Worker runs under Syscall User Dispatch (STRICT mode) with a narrow kernel-enforced allow-list. A syscall it wasn’t granted — opening a file, spawning a process, dialing the network — traps and the process is reaped. This is enforced by the kernel, not a library policy.
pledge + unveil. Every Worker is pledged to a minimal operation set and unveiled to only the exact paths it needs, cutting its filesystem and capability surface to near-zero before your code runs.
Host-held credentials. Database passwords, API keys, and per-upstream secrets live in the host. When a Worker uses env.SQL, fetch(), or a pinned secret, the host attaches the credential on the Worker’s behalf — your JavaScript never holds it, so it cannot be logged, exfiltrated, or redirected to another host.
Fail-closed capabilities. Every binding (env.SQL, env.BUCKET, env.MAILTX, outbound fetch, env.CONVERSATION) is denied by default and granted per service. Revoke one and the Worker’s await fail-closes instantly — no redeploy.
Process isolation. One isolated OS process per request over a bounded memory region — no cross-tenant heap and no shared globals, so a crash or compromise is contained to a single reaped process.
Verified lowering. The JS→C build is content-addressed, API-grounded, and behaviorally gated: the emitted C is a faithful, tested lowering of your JavaScript over bounded region allocation — you never hand-write C, so you never inherit its manual-memory footguns.