Runtimes: Docker & WebAssembly

An engine declares one or more runtimes. Verentis selects the best available runtime for each run: Docker for server-side execution, or a client-compatible WebAssembly runtime for eligible browser runs.

Docker (server-side)

The general-purpose runtime: any language, packaged as a container image.

spec:
  runtimes:
    docker:
      image: ghcr.io/you/engine:1.0.0
      pull-policy: IfNotPresent

• Best for: arbitrary languages and dependencies, heavier workloads, anything that needs a full OS userland.
• Trade-off: cold-start latency when a container must be pulled and started.

WebAssembly (client-side)

Run a WASM module in the browser for instant execution — no round-trip to the server.

spec:
  runtimes:
    wasm:
      module: https://cdn.example.com/pyodide/pyodide.js
      runtime: pyodide
      adapter: ./browser/dist/pyodide-runner.js
      client-compatible: true

The adapter is an engine-owned worker that implements the client warm/run protocol. The platform loads it generically and ships none itself — the deliberate symmetry with docker.image. This is how a third-party browser engine plugs in its own execution worker.

Reference the worker manifest-relative (./…) and bundle it in your package (packaging.files) — installed packages resolve it to a child of the manifest node (e.g. /applications/my-engine/browser/dist/pyodide-runner.js). Loose manifests may also use an absolute workspace path or an HTTPS URL.

• Best for: instant, interactive execution (e.g. running a Python snippet inline) with zero server latency.

Choosing & combining

You can declare both and let the platform pick. A common pattern is Docker for full server-side runs plus client WASM for instant in-browser previews.

Next