Publish and version

A plugin is a Git repository

Push the plugin's folder to a Git repository the edge can reach over HTTPS. The edge fetches exactly one commit, packs it and serves it to the nodes; nodes never reach Git.

One repository can also hold several plugins, each in a folder with its own oz0-plugin.yaml; operators install one with plugin install --path. A private repository works too, with a token the tenant keeps as a secret. See Install and update.

Versions

• version in oz0-plugin.yaml is a semantic version, such as 1.4.0. It is for people.
• Release tags are v1.4.0. plugin install without --ref takes the highest vX.Y.Z tag, compared as numbers, or the default branch when there is none.
• The commit is what actually installs. Every install is locked to one.

Bump version, commit, tag and push:

git commit -am "ops-tools 0.2.0"
git tag v0.2.0
git push --tags

Then install the new tag, or let plugin update resolve a branch again:

orchestrator-zero plugin install https://github.com/your-org/ops-tools --ref v0.2.0
orchestrator-zero plugin update ops-tools

Lock your dependencies

• Commit uv.lock. The node builds the plugin's environment with uv sync --frozen, so it installs exactly what you locked.
• Pin packages: pypi:name==1.2.3, npm:name@1.2.3. Unpinned packages are pinned by the edge at install time, but pinning them yourself means you know what runs.

Say what you need

requires:
  oz0: ">=0.4"                       # the Orchestrator Zero versions it works with
  platforms: [linux/amd64, linux/arm64, darwin/arm64]
  secrets: [GITHUB_TOKEN]            # tenant secrets its processes need

platforms lists os/arch pairs from linux, darwin and windows with amd64 and arm64; empty means every platform.

Keep it neutral and small

One plugin per concern is easier to roll out and roll back than one plugin with everything. Put your company's models, rules and services in your own plugins; the core never needs to change for them.