Publishing to the marketplace · Verentis Developer

The Verentis marketplace is how customers discover and install third-party extensions. Listing your app, engine or file bundle there puts it in front of every workspace, with one-click install.

The publishing flow

verentis pack ──► verentis publish ──► Submitted ──► moderation review ──► Approved + countersigned ──► Published
                                                   ↘ Rejected (with notes)

Become a publisher

Onboard your account once: verentis publisher create --name acme --display-name "Acme Inc.". Your publisher name prefixes every package you ship (acme/my-app).

Generate a signing key

verentis keygen creates an Ed25519 keypair, registers its public half with your publisher profile, and signs everything you pack from then on. Private keys never leave your machine.

verentis pack builds a .vpkg — a gzip tarball carrying your manifest, every auxiliary file it references (schemas, engine workers, bundle content), per-file digests, and your signature. See Packaging.

Publish

verentis publish my-app-0.1.0.vpkg uploads the version to the registry. The first publish creates the package listing; every upload lands as Submitted and enters the moderation queue.

Moderation

A reviewer inspects your manifest — requested permissions, capabilities, sandbox and oauth settings are what they judge, so keep them minimal and legible. On approval the marketplace countersigns your package and the version becomes Published and installable. Rejections come back with notes; fix and publish a new version.

How installation works

Installing writes your package into the customer's workspace VFS as a manifest node with children: the node at /applications/my-app is your manifest, and bundled files normally become its children (e.g. /applications/my-app/schemas/report.schema.json). Application spec.install[] directives may place selected payload elsewhere in the workspace. Everything you've learned about manifests, resolution, scopes and consent applies unchanged — relative references (./schemas/…, ./worker.js) resolve to child payload automatically.

An extension that works when you drop its manifest into a workspace works identically when installed from the marketplace.

Visibility: public and private packages

Not every package is for everyone. Each package is Public (any workspace can discover and install it) or Private — visible only to accounts and workspaces you explicitly grant. Private packages are how proprietary work is distributed through the same pipeline: manage grants from the developer portal (or keep a package private and grant a single customer).

Pricing

Packages default to free. You can attach a price plan (one-off, subscription, or usage-based) from the developer portal; customers then need a purchase or entitlement before they can download or install. Billing integration is rolling out — plans can be configured today and entitlements are enforced at install time.

Trust & signing

Every submitted package should carry your developer signature (packs are signed automatically once you've run verentis keygen; publishers with registered keys must sign). On approval the marketplace adds its countersignature — installers can verify both. Third-party extensions still run fully sandboxed; signatures are a trust and integrity signal, not a sandbox bypass.

Sensitive payloads can additionally be encrypted end-to-end and installed sealed — see Packaging.

Publish an application

Step-by-step: a hosted web app → signed, published, installable listing.

Publish an execution engine

Step-by-step: a Docker image or WASM adapter → signed, published listing.

Packaging your extension

The .vpkg format, the packaging manifest section, and the pre-publish checklist.

Versioning & updates

Ship changes without breaking installs.