Documentation

How a deploy works

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

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

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   → a 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.

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 next call to it fails at once — no redeploy.
• Virtual-kernel isolation, per connection. Your app stays loaded in resident processes (one per core), and each connection — each end user — runs in its own memory-isolated virtual kernel process inside them: its own heap, not a new OS process, with no cross-connection heap and no shared globals. Every request on a connection runs in that same process, with its database session already open, and a crash or compromise is contained to that virtual kernel process and reaped.
• Checked translation. Your JavaScript is translated into C that allocates only from bounded regions, and each build is checked against how the JavaScript behaves (how the compiler works). You never write C, so you never inherit its manual memory management.