Managed runtime for AI-generated code

AI writes it.
Onyx runs it.

Describe what you want. Claude Code generates the service. Onyx deploys it — sandboxed in WebAssembly, zero-trust by default, with strictly typed interfaces that AI can reliably generate against.

Join the waitlist See how it works

terminal

$ onyx deploy "resize uploaded images to 800px wide"

→ Generating service interface (WIT)...
→ Writing WebAssembly module...
→ Validating capability declarations...
✓ resize-images deployed
  Runtime: Onyx Wasm sandbox
  Capabilities: [blob-read, blob-write]
  Endpoint: https://resize-images.onyx.run

The problem

AI can generate code. But where does it run?

No boundaries

Generated code runs with full system access by default. One prompt, and the service can read your filesystem, call arbitrary APIs, or exfiltrate data.

No contract

AI generates against vague interfaces. When the shape changes, nothing catches it. Integration breaks silently at runtime, not at generation time.

No automation

Every generated service needs manual review before deployment. The loop from prompt to production requires humans at every step.

How Onyx solves it

A runtime built for the AI-native stack

WebAssembly isolation

Every service runs in its own sandboxed Wasm module. Modules cannot access host resources unless you explicitly declare a capability. No shared memory, no filesystem, no surprises.

Strictly typed interfaces

Services define their contracts in WIT — the WebAssembly Interface Type format. AI generates against a precise, machine-readable schema. The stricter the interface, the better the output.

Zero trust by default

Modules declare exactly what they need: blob storage, outbound HTTP, a database connection. Nothing else. Capabilities are auditable, versioned, and enforced at the runtime boundary.

Prompt to production

Describe what you want. Onyx generates the WIT interface, writes the module, validates capabilities, and deploys — all in one step. The AI loop is fully automated.

The developer experience

From description to deployment in one step

Describe your service

Tell Onyx what the service should do in plain English. "Process incoming webhooks and store event payloads." That's the entire input.

Interface is generated first

Onyx generates a WIT contract — input types, output types, declared capabilities. Claude Code writes implementation against that strict contract, not a loose prompt.

Validated and deployed

The Wasm module is validated against its declared capabilities. If the code tries to access anything it didn't declare, deployment fails — not production.

onyx deploy output

$ onyx deploy "process webhooks and store event payloads in postgres"

// Generating WIT interface
interface webhook-processor {
  record event {
    id: string,
    source: string,
    payload: list<u8>,
  }
  process: func(event: event) -> result<string, string>;
}

// Declared capabilities
  capabilities: [postgres-write]
  allowed: true

// Compiling + validating
  Module size: 48 kB
  Capability check: pass

✓ webhook-processor v1 deployed
  https://webhook-processor.onyx.run

Built on open standards

WebAssembly W3C standard sandbox

WIT / Component Model Bytecode Alliance spec

WASI Capability-based syscalls

Claude Code AI code generation

Deploy your first AI-generated service

Onyx is in private beta. Join the waitlist and we'll reach out when access opens.

AI writes it.Onyx runs it.