Create and test locally in PexarBolt Plugin Studio. Upload a .boltplugin exported by the desktop app or the standalone package tool. The package must include editable source.
.boltplugin
Plugins are free to download. Each release includes editable source under the platform-wide MIT license.
You do not need a public repository URL, screenshots, or a separate license choice.
Every active registered user can upload and submit plugins. No developer application or administrator approval of your account is needed. Existing members have the same access automatically. Public release still requires an independent administrator review.
Choose a .boltplugin from Studio's More options → Export plugin. The website keeps the runtime package unchanged and includes its packaged files as editable source. Fill in the description and release notes in the draft.
The check report identifies source imported from a runtime package. If the package contains compiled or bundled code, include the original development files inside the .boltplugin, for example under source/, before requesting review.
source/
Existing MIT licenses and third-party notices are preserved. If the package has no project license, the draft includes the platform's MIT license; uploading does not grant publication consent. You must own the necessary rights and confirm them before submitting. A conflicting project license is rejected.
npx bolt-plugin package ./my-plugin ./my-plugin.boltplugin
The website accepts only .boltplugin files. The host entry must be present, non-empty and readable UTF-8 source. Keep all implementation modules, schemas, projection declarations and license notices in the package. For compiled projects, include the original source under source/, build instructions and a dependency lockfile. Reviewers verify that this source corresponds to the runtime. ZIP files and .boltsubmission wrappers are rejected.
.boltsubmission
Use listing.json for descriptions, category, tags, setup, release notes, dependencies, and minimum App or firmware versions. It can remain in the runtime as an ordinary JSON file. Keep private values out of it.
listing.json
After upload, the release workspace opens with Details, Checks, and Package tabs. The package name, ID, version, icon, permissions, platforms and preview are read automatically. Identity fields describe the uploaded file and are not editable in the listing form.
Listing fields are read from packaged listing.json and supported metadata in plugin.json. Source package.json can supply a description and keywords. A README supplies a missing description; its first paragraph can supply a short description. A matching version section in CHANGELOG.md supplies missing release notes. Invalid optional metadata is reported for correction, without inventing compatibility requirements or release notes.
plugin.json
package.json
CHANGELOG.md
Each imported field identifies its source. Edit the values before saving. Fill missing details fills empty fields without replacing existing text. Rechecking or replacing a draft preserves your listing edits. Complete the short description, full description and release notes, review the checks, then confirm publication rights and select Submit for review. Analytics appear after a version is published.
When submission is unavailable, Complete before submitting lists the remaining requirements beside the button. Select an item to focus the affected field, publication-rights checkbox or package-check report. Required fields show their minimum lengths and current character counts. The list updates as you correct each item; package review notes alone do not block submission. Only one version of a plugin can be under review at a time.
Setup instructions, external requirements and minimum App/firmware versions are retained from package metadata. The release details form contains the plugin listing and release information; include any additional setup or requirements in the description.
Before export:
node_modules
For a compiled runtime, include the original development files in the .boltplugin package. Include build instructions and a dependency lockfile.
Uploading or replacing a draft starts these checks automatically:
The report lists passed checks, errors and notes, with affected files and suggested corrections. Errors must be fixed before submission. Replace the draft with the same plugin ID/version to run checks again; older findings and publication consent are reset. If the sandbox is unavailable or an integration needs the desktop host, the report explicitly requests manual review rather than claiming a pass.
Plugin code never executes in the website's API process. The checker blocks external network access and website cookies/storage. Sample operations do not access actual Dock hardware, user files or external accounts. Native projections receive static checks; device rendering still needs physical verification. Visual quality, source correspondence and real-service compatibility remain part of review.
You can also inspect the rendered screen and use the interactive preview before submitting.
An independent reviewer checks source, permissions, behavior, and compatibility claims. Authors cannot approve their own releases.
To correct a draft, use Replace draft package with the same ID and version. Checks run again. You must confirm license consent again.
Choose automatic publication after approval, or publish an approved release manually.
Both visibility settings require review. An unlisted release is not private.
Published runtime and source files cannot be replaced. Use a new version for code changes. A pending update leaves the current public release available.
To remove your plugin from distribution, open My plugins → your plugin → … → Unpublish plugin. Enter a reason and confirm. Only the owner can perform this action. It withdraws every published version, including unlisted versions, so old versions do not become the catalog default. Public detail pages, source, previews, downloads and new install links become unavailable. Existing installations remain on users’ devices. Pending and approved updates return to drafts, and any legacy pending listing changes are retired. The owner retains the files and version history. To publish again, upload a new version and submit it for independent review.
To withdraw just one faulty version, use Package → Withdraw this version. If a release fails, withdraw it. The previous eligible published version becomes the catalog default. Existing installations are not remotely downgraded.
All plugin information is reviewed together with a release. To change the description, category, tags, setup instructions, requirements or other listing fields, click Upload a new version in the existing plugin workspace, choose the updated .boltplugin, edit its draft information and submit it for independent review. Upload, checks, corrections and review submission all stay on this page; the new draft is selected in the version list. The package must retain the same plugin ID and use a new version number. The current published version stays unchanged until the new version is approved and published. Published listings cannot be edited separately; the former listing-only submission and review endpoints return HTTP 410.
Only the plugin owner can manage its releases. Administrators review submissions independently.
Export the package from Studio or local tools, then upload it in My plugins. Website upload, consent and review use your signed-in session and do not require a developer token.
The console reports views, downloads, reported installs, and favorites separately. A download does not prove installation or device usage.