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
  name: smart-editor
  display-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

namestring
Required

Stable machine identifier (kebab-case). Used for resolution, registration and updates. Don't change it across versions.

display-namestring

Human-friendly name shown in the UI and marketplace.

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 (display-name, 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.name is the extension's permanent identity. Changing it is treated as a different extension, not an update. Bump metadata.version to ship changes; keep name stable.

One registry, many kinds

Any YAML file with a valid kind + metadata.name envelope is treated as a manifest and registered. 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.