Publish an execution engine

This is the end-to-end recipe for shipping an execution engine to the marketplace: from a working, locally-registered engine to a signed, moderated, installable listing. It assumes you have already built the engine and understand the engine manifest — here we focus on packaging and publishing the two engine runtimes: a Docker image (server-side) or an in-browser WASM adapter (client-side).

1. Install the CLI and sign in

npm install -g @verentis/cli
verentis login --token <identity-token>
verentis whoami

2. Become a publisher and register a signing key (once)

verentis publisher create --name acme --display-name "Acme Inc."
verentis keygen               # Ed25519 keypair; registers the PUBLIC half; signs every pack

Same one-time setup as for an app — your publisher name (acme) prefixes the engine (acme/my-engine), and the private key never leaves your machine. You can also register a public key by hand on the developer portal → Signing keys page — it accepts an OpenSSH ssh-ed25519 … line, a PEM public key, or the raw base64. (Details: Publish an app.)

3. Pin your runtime artifacts

An engine version is immutable, so it must reference immutable artifacts:

4. Write the manifest

Scaffold, or reuse your existing *.engine.yaml:

verentis init --kind engine --name my-engine

Fill in the engine spec and the packaging section:

api-version: verentis.io/v1
kind: ExecutionEngine

metadata:
  name: my-engine
  display-name: My Engine
  description: What it runs, in one line
  icon: lucide:terminal
  version: 1.0.0
  author: Acme Inc.

spec:
  runtimes:
    # Server-side: a pinned, immutable image
    docker:
      image: ghcr.io/acme/my-engine:1.0.0
      pull-policy: IfNotPresent
    # Client-side: the adapter is BUNDLED and referenced manifest-relative
    wasm:
      adapter: ./browser/dist/runner.js

  # Which files this engine makes runnable
  file-types:
    - pattern: text/x-acme
      extensions: [".acme"]
      priority: 100

  execution-modes:
    - request-response          # add long-running / scheduled / event-driven as needed

  resources:
    cpu: "500m"
    memory: "512Mi"
    timeout: 120

  permissions:
    - node.file.read            # the FEWEST scopes the engine actually uses

packaging:
  publisher: acme
  files:                        # bundle the WASM adapter (and any assets it needs)
    - "browser/dist/runner.js"
  encryption: none

See the engine manifest reference and Runtimes for every field.

5. Pack and verify

verentis pack                          # → my-engine-1.0.0.vpkg  (digested + signed)
verentis verify my-engine-1.0.0.vpkg

pack digests manifest.yaml and every bundled file (your WASM adapter), signs the digest document (DSSE / Ed25519), and emits a single .vpkg.

6. Publish

verentis publish my-engine-1.0.0.vpkg --visibility Public

First publish creates the listing (default visibility is Private — pass --visibility Public to list it publicly). Every upload lands as Submitted and enters moderation.

7. Moderation → Published

A reviewer inspects the requested permissions, the runtimes (which image/adapter you ship), and the resources limits. On approval the marketplace countersigns and the version becomes Published and installable. Rejections come back with notes — fix them and publish a new version (versions are immutable — see Versioning).

8. Try the install

verentis install acme/my-engine --workspace <workspaceId>

The engine installs to /applications/my-engine (with its bundled adapter as children). Upload a matching .acme file into that workspace and Run it — Verentis launches your Docker image or the in-browser WASM adapter, hands it a scoped token and the run context, and collects the result.

Recap

Next