Verentis

Manifests

Manifests: the contract

The shared manifest envelope used by every extension, and the conventions for naming, versioning and YAML keys.

A manifest is how you describe an extension to Verentis. It's a small YAML file using a Kubernetes-style envelope shared by every extension type.

The envelope

api-version: verentis.io/v1   # manifest schema version
kind: Application             # Application | ExecutionEngine | Bundle
metadata:                    # identity & display
  id: smart-editor
  name: Smart Editor
  description: A Monaco-powered editor for text and structured files
  icon: file-code
  version: 0.1.0
  author: Verentis
  labels:
    category: editor
spec:                        # kind-specific configuration
  # ...
marketplace:                 # optional catalog presentation
  # ...
packaging:                   # optional .vpkg build configuration
  # ...
api-versionstring
Required

The manifest schema version. Use verentis.io/v1.

kindstring
Required

The package type: Application, ExecutionEngine, or Bundle. Determines how spec is interpreted and how an installed package is registered.

metadataobject
Required

Identity and display information — see below.

specobject

Kind-specific configuration. Applications and execution engines use it; a plain Bundle may omit it. See the app manifest and engine manifest references.

marketplaceobject

Optional catalog presentation: logo, hero, gallery images, README, changelog, and supporting assets. See Packaging.

packagingobject

Optional .vpkg build configuration such as publisher, payload globs, exclusions, and encryption policy. See Packaging.

metadata

idstring
Required

The manifest's only identifier (lowercase kebab-case). For packages it is used for the marketplace, dependencies, resolution, registration and updates. Don't change it across versions. A manifest without it is rejected with metadata.id is required; the removed package-id key is rejected with metadata.package-id is no longer supported; use metadata.id.

namestring

Human-friendly name shown in the UI and marketplace. Optional; displays fall back to id. The removed display-name key is rejected with metadata.display-name is no longer supported; use metadata.name.

descriptionstring

A short summary of what the extension does.

iconstring

An icon name used in listings.

versionstring

Semantic version of the extension (e.g. 1.2.0). Drives updates and marketplace listings.

authorstring

The publisher.

labelsmap<string,string>

Free-form key/value labels for categorisation (e.g. category: editor).

annotationsmap<string,string>

Machine-readable extension metadata used by optional platform integrations.

YAML key conventions

Manifest keys are hyphenated (mime-types, file-types, json-schema, api-version, pull-policy, allow-scripts). Lists use standard YAML sequences. Booleans are true / false.

Names are identity

metadata.id is the extension's permanent identity. Changing it is treated as a different extension, not an update. Bump metadata.version to ship changes; keep id stable.

One registry, many kinds

Any YAML file with a valid kind + identity envelope is treated as a manifest and registered. Every kind, package or not (scripts, triggers, schedules, webhook receivers, policies, documents), is identified by metadata.id and labelled by the optional metadata.name. Apps and engines simply differ in their kind and spec. This is what lets the platform discover, register and govern every extension type uniformly.

Next

App manifest reference

Every field in an *.app.yaml spec.

Engine manifest reference

Every field in an *.engine.yaml spec.