Submit your extension — bRRAIn Docs

How to publish an extension to the bRRAIn Marketplace, from eligibility through review and listing.

Submit your extension

Anyone can build and submit a bRRAIn Marketplace extension. This page is the publisher's guide.

Prerequisites

Before you can submit:

  1. A bRRAIn account with confirmed email and MFA enrolled.
  2. A bRRAInUserID claimed (your public publisher identity). See ID Registry: Claim your ID.
  3. An active Exchange / Marketplace submitter seat subscription. This is a small annual fee that covers identity verification and submission infrastructure.
  4. A signed publisher agreement including the revenue-share terms.
  5. Stripe Identity verification completed for payouts.

You'll be walked through 1–5 the first time you click Submit.

Build your extension

Extensions are independent Go (or Python, or Node — we're language-agnostic) services that:

  • Speak the bRRAIn Platform SDK over loopback HTTP/JSON to the brain pod.
  • Mount their HTTP routes under a single path prefix you declare in the manifest.
  • Spawn as a child process under your subscriber's brain-pod supervisor.
  • Use the bRRAIn Platform SDK to read and write the Vault, call integrations, and dispatch notifications.

The SDK gives you typed access to:

  • Operator environment configuration (OAuth client IDs, tokens).
  • Integration registry and per-vendor typed actions.
  • Vault read and write.
  • Audit logging.
  • Notifications.
  • LLM access (via the per-organization Handler).
  • Policy checks.

See the Platform SDK reference for the SDK contract.

Manifest

Every extension ships a manifest.json declaring:

  • slug, version, and binary path.
  • listen.protocol and listen.port_env (which env var your binary reads to learn its assigned port).
  • routes — the URL prefix(es) you mount under. Typically /api/apps/<slug>/.
  • platform_sdk.min_version — the SDK version your code is compiled against.
  • platform_sdk.consumes — the SDK sub-clients you use (e.g., integrations.registry, vault.read, notifier).
  • scopes_required — the explicit scopes the customer will be asked to approve.

The supervisor in each subscriber's pod validates the manifest and refuses to start an extension whose manifest is malformed or whose declared scopes don't match what the customer approved.

Tarball format

Bundle the binary, manifest, VERSION file, and any static web assets into a tarball:

apps-<slug>-<version>.tar.gz
├── bin/
│   └── <slug>
├── manifest.json
├── VERSION
└── web/
    └── (your static assets)

You then upload the tarball to bRRAIn's deployment-asset storage (we provide signed URLs as part of the publisher portal). The pod-side supervisor pulls from those storage URLs at install time.

Important — extensions are deployed from our servers, never from GitHub or any other public code host. This is a hard requirement. See Source & deployment policy for the rationale.

Submission flow

  1. Open marketplace.brrain.io/submit.
  2. Pick + New extension (or + New version if you're updating an existing one).
  3. Fill in the listing form:
    • Name, tagline, synopsis (used in dropdowns and listings).
    • Long-form description (markdown supported).
    • Banner image (1600×600 PNG; this is your visual identity in the catalog).
    • Screenshots (4–8 images of your extension in use).
    • Category and subcategories.
    • Pricing model (free / subscription / per-seat / metered).
    • Scopes required (auto-pulled from your manifest).
  4. Upload your tarball.
  5. Add a documentation URL (typically your page at docs.brrain.io/marketplace/extensions/<slug> — let us know if you want that page provisioned).
  6. Submit for review.

Review

Our review team checks:

  • Listing copy is clear and not misleading.
  • Screenshots accurately represent the extension's UI.
  • Manifest matches the declared scopes.
  • Tarball signature verifies.
  • Initial smoke test against a sandbox brain pod succeeds.
  • The extension respects bRRAIn security boundaries (no scope-escalation attempts, no plain-text secrets in logs, no out-of-process Vault access).

Standard review SLA is 5 business days. First-time publishers may take longer because we do an additional identity check.

We may request changes. Common feedback:

  • Tighten scope declaration to what the extension actually uses.
  • Improve error messages surfaced to the user.
  • Add explicit consent messaging for any non-obvious data flows.
  • Tighten the long-form description.

Approval and listing

Once approved:

  • Your extension is listed. It appears in search and category browsing within minutes.
  • Marketing optionally features it in the dropdown slider rotation if it fits a current theme.
  • You start accruing installs. Subscription revenue starts on the first install.
  • Payouts follow the schedule in Billing & licensing.

Updating

To publish a new version:

  1. Bump the version in your manifest and VERSION file.
  2. Build a new tarball.
  3. Open the publisher portal → your extension → + New version.
  4. Upload the tarball.
  5. Add release notes (markdown).
  6. Submit. A short re-review runs (24–48 hours typical).

Once approved, existing installs see the Update available badge. They control when they apply.

Delisting

You can delist an extension at any time. Existing installs continue to function on their pinned version; new installs are blocked. We email all current subscribers with reasonable notice (30 days for paid extensions; 7 days for free).

We can delist for cause if an extension is found to violate the publisher agreement or compromise customer security.

Support

As a publisher, you commit to a baseline of support:

  • A documented support email or portal.
  • Response within 5 business days for free extensions, 1 business day for paid.
  • A working contact for security issues that's monitored 24/7.

Repeat support failures factor into your trust badge and into prominence in catalog ranking.

Where to next