AiHummer
English
Sign inAccount
v1.1.x
{ }Swagger

Publishing a plugin

v1.1.x · updated 2026-07-19

Built a plugin with the Plugin SDK? You can publish it in two ways:

  • Private (for yourself) — side-load into your instance. The artifact never leaves it.
  • Community (for everyone) — publish through your personal cabinet at my.aihummer.ru, app-store style: upload the build, fill the store page, pass review, and it lands in the signed community catalog that every instance can install from.

Analogy: installing a .vsix by hand (private) vs publishing to an app store (community).

[!WARNING] Community plugins cannot be installed right now — this is not a connectivity problem. The key that signed the community catalogue has been retired; until a new key ships, signature checking rejects those entries. Separately, third-party code is not yet run as a service on your server: until an isolated runtime exists, only integrations that run on their own side and connect over the network are allowed.

What you will see: after you press Install the usual “installing” message appears, but the plugin never shows up in the installed list. The reason for the refusal goes to the gateway log — open Logs in the admin panel.

What does work today:

  • plugins by AiHummer from the official catalogue — they install as usual, they carry a different, valid signature;
  • an MCP server over HTTP — connected as a zero-code tool source, the code stays on your side;
  • an OpenAPI-spec integration — the same, with no service to install.

Side-loading your own plugin passes the signature check, but it will only run as a remote MCP over HTTP or an OpenAPI integration; a build that has to be started as a service on this same server is refused.

Private mode — side-load into your instance

Use this when only you need the plugin: an internal connector, a custom integration, a test build.

Steps

  1. Package and sign the bundle:
    aihummer plugin package ./my-plugin
    aihummer plugin sign --key author.key --manifest ./my-plugin/manifest.json my-plugin-1.0.0.tar.gz
  2. Upload it to the instance one of two ways:
    • Admin UI → Plugins → “Upload plugin” — drag the bundle; or
    • CLI:
      aihummer plugin publish --private --instance https://your-instance \
        --token <admin-token> my-plugin-1.0.0.tar.gz
  3. Under the hood this is POST /v1/admin/modules/upload (multipart, integrations:write): the artifact lands in the instance blob store (AIHUMMER_BLOB_DIR) under a blob: ref, and a catalog row is registered with origin = local-private, visibility = private.
  4. The plugin appears in the marketplace tagged Private and installs via the normal path — sandboxed systemd unit + health gate.

Trust: the pinned key and the trust store

Private artifacts must be signed. When you upload a plugin signed with an unknown key, the Admin UI prompts you to approve the author’s key into the instance trust store (one click). Once approved, the signature is verified on every install and update.

  • Artifacts from the official source verify against the registry key pinned in core — trusted by default, no extra step.
  • Private artifacts verify against keys in the instance trust store.
  • Unsigned bundles are rejected — except in dev mode for local iteration: AIHUMMER_PLUGIN_DEV_UNSIGNED=1.

[!WARNING] AIHUMMER_PLUGIN_DEV_UNSIGNED=1 disables signature verification and is meant only for local development. Never enable it on an externally reachable instance.

Community mode — publish through the personal cabinet

To make a plugin available to every instance, publish it from your personal cabinet at my.aihummer.ru, the same way you publish an app to an app store. You upload the build, fill in the store page, and send it for review; an automated AI check runs first, then a human moderator makes the final call, and on approval the artifact is signed and published to the community catalog.

The full, step-by-step walkthrough is on Submit a plugin. In short:

  1. Build & package your plugin with the SDK (aihummer plugin package) — the artifact is a signed .tar.gz carrying its manifest.json.
  2. Open «My plugins» in the cabinet and create a submission: upload the artifact, fill the store metadata (name & descriptions in RU + EN, version, icon, screenshots, category, optional donation link, changelog) and declare the capability manifest.
  3. Send for review. An automated AI review checks the submission against the review policy (security, manifest correctness, completeness, content), then a human moderator reads the report and decides. The automation never publishes on its own.
  4. On approval the artifact is signed and published to a separate community-catalog.json on the CDN. Every instance that has added the community source sees the plugin; core trusts it via the pinned registry key — no per-operator trust step needed.

[!NOTE] The old public publishing flow has been retired; the personal-cabinet flow above — “My plugins” — is the single community publishing path. Community plugins are free; you may add an optional donation link.

[!NOTE] First-party plugins (Einstein, SIP, Bitrix24, pocket-agent, os-client) are not published this way — they ship on their own AiHummer CI pipeline and land in the pinned official catalog. The personal-cabinet flow is for community (third-party) plugins.

Moderation

Every community submission goes through an automated check (completeness, the capability manifest, signature and a security scan), then an AI risk review, and finally a mandatory human review by the AiHummer team. Neither the automation nor the AI ever publishes on its own — the decision is always a moderator’s, and nothing reaches the catalog without their approval. A published plugin later found to be malicious or broken can be revoked and dropped from the catalog on the next sync.

The community catalog as an extra source

Community plugins are published to a separate community-catalog.json that does not overwrite the curated first-party catalog. An instance adds it as an extra source in Plugins → Sources (or POST /v1/admin/modules/catalog/sources). See Install & updates and Overview & tiers.

Plugin lifecycle (App Store)

The marketplace works like a real App Store — each plugin has an identity (a permanent slug + author) under which it ships versions.

Versions & updates

An update ships as a new version of an already-published plugin: the same slug, its own changelog, its own review and moderation. Only one version may be in review at a time — you submit the next one after the current gets a decision. When a new version is published, the previous one is marked superseded, and the catalog + every instance move to the new one.

Scheduled publishing

After a moderator approves it, the author controls the release: publish now, or schedule it for a specific time — the plugin goes live at the appointed moment.

Unpublishing

  • Pause — temporarily hide the plugin: it drops out of the public catalog and off instances (on the next sync), but is retained and can be re-published at any time.
  • Delist — remove the plugin from the marketplace for good.

As soon as a plugin is unpublished (paused or delisted), its entry is removed from community-catalog.json, and instances stop showing it on the next sync.

Authorship

A plugin is published under your display name (e.g. your studio’s name) — or anonymously. The public catalog and the instance Web UI show the chosen name or “Anonymous”; your real email/id is never exposed.

Developer stats

Each plugin has aggregate stats: downloads, installs, active instances and uninstalls, plus a daily chart. Aggregate figures only — no per-instance data is exposed to the developer.

Publishing reward

For each plugin you publish for the first time, your AiHummer subscription gets one free month (granted once per plugin).

Where next