Submitting to the Community Registry

Community listings go to studiobrain-community (the repo is still named studiobrain-community-plugins). That repo is one public registry with two indexes:

Do not PR community plugins or community data into studiobrain-templates. That repo is official data only.

Marketplace is the only store UI. CatalogSync does not already merge these indexes into the official catalog.

Where does it run?

Plugin index requirements

Runtime: WIT Component + panels

• Ship a StudioBrain WIT Component (plugin.wasm) for desktop and mobile (wasmtime Cranelift / Pulley).
• Ship panels as static HTML/JS. Those are what cloud users see inside StudioBrain.
• If you need a server on cloud, host it yourself and document the URL. We will not run it.
• Native Python / Lua / backend/routes.py is rejected.

Desktop-only community plugins are allowed (Component, no cloud Worker to begin with). They appear on desktop/mobile Marketplace, not as a cloud Worker. Cloud may still show panels if you include them.

network:local is rejected unless the listing is desktop-only (environments: ["desktop"]). Cloud never grants it.

plugin.json

Do not require a cloud Worker platform. Cloud community is panels / author backend.

No secrets

No hardcoded API keys or tokens. Use settings for user-provided credentials.

Size limits

Trust tier

Community listings have no Verified badge. Users always see consent. Partner / vendor promotion is a separate program (partners@studiobrain.ai) and still does not turn community WASM into a Worker on our account.

Submit a plugin

1. Fork the registry

Fork studiobrain-community-plugins (studiobrain-community).

2. Add a plugins index entry

{
  "id": "my-plugin",
  "name": "My Plugin",
  "version": "1.0.0",
  "description": "Does something useful with entities",
  "author": "your-github-username",
  "license": "MIT",
  "repository": "https://github.com/you/studiobrain-my-plugin",
  "download_url": "https://github.com/you/studiobrain-my-plugin/releases/download/v1.0.0/my-plugin.zip",
  "icon": "Puzzle",
  "category": "development",
  "surfaces": ["desktop", "mobile", "cloud-panel"],
  "min_studiobrain_version": "2026.8",
  "featured": false
}

3. Release the zip

cargo component build --release
# copy Component → plugin.wasm
zip -r my-plugin.zip plugin.json plugin.wasm frontend/ assets/ README.md

Upload the zip as a GitHub Release asset. Use that URL as download_url.

4. Open the PR

PR against main. Describe the plugin and link the release. CI re-runs on each push.

Submit catalog data

Add a row to catalog/index.json (templates, rules, skills, layouts, packs, providers, abilities, flows, canvas). That CONTRIBUTING section is separate from Submit a plugin. The payload is files users copy into a project. There is no Worker and no Component.

Official data still goes to studiobrain-templates only. Community data stays on this registry.

CI

Typical checks:

• Index schema, unique id, semver, allowed category.
• download_url is reachable HTTPS.
• Archive has plugin.json and, for plugin listings, a Component at the declared entry.
• No backend/*.py / *.lua guests.
• Size limits.
• Manifest id / name / version match the index.
• No network:local on community.
• Catalog-data entries do not include a Worker or a .wasm guest.

Review

Automated CI is enough to merge a listing. Featured status is a later, optional human review (does what it says, no obvious abuse, theme-compliant panels, README).

Updates and removal

• New version: new GitHub Release + PR that bumps version and download_url.
• Installed projects may show Update available.
• Removal: PR that deletes your index row. Already-installed project copies stay until the user uninstalls.

Best practices

• IDs like acme-notes beat my-plugin.
• Keep the Component small (wasm-opt).
• Document that cloud will not run a Biloxi Worker.
• Document settings (where to get API keys).
• Semver for breaking changes.
• Screenshots of panels.

Next steps

• Architecture
• Creating Plugins
• Permissions
• Examples