Plugin System Overview
StudioBrain’s plugin system lets you extend the application with custom UI panels, backend routes, entity tabs, creative tools, and AI integrations. Plugins are distributed through the Plugin Marketplace and run in a sandboxed environment that protects your data while giving plugins the access they need.
What Plugins Can Do
Plugins hook into StudioBrain at multiple levels:
| Extension Point | Description | Example |
|---|---|---|
| Sidebar panels | Custom UI rendered in the entity editor sidebar | Relationship graph, AI writing assistant |
| Entity tabs | Full-width tabs on entity pages | Version history, analytics dashboard |
| Standalone pages | Dedicated pages under /plugins/{id} | Kanban board, bulk export tool |
| Menu items | Entries in the Tools menu or context menus | “Export to PDF”, “Sync to Jira” |
| Backend routes | Custom REST API endpoints under /api/plugins/{id}/ | Webhook receivers, external service bridges |
| Event handlers | React to entity lifecycle events | Auto-tag on create, validate on save |
| AI integrations | Use the AI generation service for content creation | Character backstory generator, description enhancer |
| Field widgets | Custom form inputs in the entity editor | Gradient picker, map coordinate selector |
Plugin Runtimes
New plugins are a WIT Component. Desktop and Core load that Component with wasmtime. Official cloud plugins that need a guest are a Worker compiled at our deploy. Start at Getting Started. Native Python is not loaded by any current host. Lua still loads in one place only: the sandboxed mobile client host. It is not a Desktop or Core runtime, and it is not a path for new plugins.
WASM / WIT Component (current)
WebAssembly plugins run in a memory-safe sandbox. This is the runtime for new plugins. On Desktop and Core the guest is a WIT Component in wasmtime. On Cloud, an official plugin that needs a guest ships as a Worker we compile at deploy. Community Marketplace plugins must be a WIT Component. They are not loaded as native Python or Lua.
| Property | Details |
|---|---|
| Platforms | Cloud, Desktop, Core (self-hosted), mobile |
| Sandboxing | Full memory isolation. No host access unless explicitly granted via capabilities. |
| Performance | Sandboxed WebAssembly. Cold start depends on the host (wasmtime Cranelift on desktop and Core, Pulley on mobile, a Worker on cloud). |
| Languages | Rust WIT Component is the official proof path. Other languages that compile to the same WIT world are possible. Python via componentize-py and TypeScript via javy are not the proof path. |
| Distribution | Single Component binary. No host Python or Lua runtime. |
Python (not loaded)
Native Python plugins do not run. The Rust client host matches a Python manifest, logs that the Python runtime is not supported, and stores the plugin with no engine in the error state. Desktop (Tauri), Core (sb-plugin-wasmtime), Cloud, and mobile do not start a Python interpreter for a plugin. There is no consent dialog that turns it on.
A Python plugin kept for the desktop app will not load. Rebuild it as a WIT Component. Follow Getting Started.
Lua (mobile client host only)
Lua 5.4 still loads in the mobile client host (sb-client-plugins, mlua). On startup that app loads plugin directories, and a Lua manifest is compiled into a sandboxed engine. The sandbox removes io, os, debug, require, loadfile, dofile, and load. Lua does not get unrestricted filesystem or network access.
No other current host executes native Lua:
- The desktop Tauri app does not link this client host.
- Core’s wasmtime host does not execute native Lua.
- Cloud does not run Lua plugins.
Lua is not accepted in the Community Marketplace. Do not start a new plugin in Lua.
Native Python plugins are not loaded on Desktop, Core, Cloud, or mobile. Lua runs only inside the sandboxed mobile client host, not on Desktop or Core. Neither can be published to the Community Marketplace. New plugins are WIT Components. Follow Getting Started.
| Property | Python (native) | Lua 5.4 |
|---|---|---|
| Loaded today | No. Stored as an error, with no engine. | Yes, mobile client host only. |
| Desktop | No | No |
| Core (self-hosted) | No | No |
| Cloud | No | No |
| Sandbox | Not executed | In-process mlua. io, os, debug, and require are removed. |
| Marketplace | Rejected | Rejected |
| New plugins | No. Use a WIT Component. | No. Use a WIT Component. |
Where Plugins Appear
Plugins declare where their UI renders in the plugin.json manifest. The host application loads plugin panels into the appropriate slots:
+--------------------------------------------------+
| Entity Editor |
| |
| +------------------+ +----------------------+ |
| | Main Content | | Sidebar | |
| | | | | |
| | [entity fields] | | [plugin panels] | |
| | | | - AI Assistant | |
| | | | - Relationships | |
| +------------------+ +----------------------+ |
| |
| Tabs: Overview | Relations | [Plugin Tabs...] |
| +----------------------------------------------+ |
| | [plugin tab content] | |
| +----------------------------------------------+ |
+--------------------------------------------------+Panel locations declared in plugin.json:
| Location | Where it renders |
|---|---|
entity-sidebar | Right sidebar of the entity editor |
entity-tab | As a tab on the entity page |
entity-footer | Below the main content area |
page | As a standalone page accessible from navigation |
tools-menu | As an entry in the Tools dropdown menu |
Official vs Community Plugins
The Plugin Marketplace has two catalogs:
Official Plugins
Maintained by Biloxi Studios. Verified, tested against every release, and covered by StudioBrain support. Official plugins include creative tools (ComfyUI, Voice Forge), export plugins (PDF, Unity, Unreal), and integrations (Jira, Discord, Google Sheets).
Community Plugins
Created by third-party developers and submitted to the studiobrain-community-plugins repository. Community plugins must be a WIT Component. Native Python and Lua are rejected. They go through automated validation and optional manual review before appearing in the marketplace. See Community Submissions for details on the submission process.
Community plugins are not covered by StudioBrain support. Review the plugin’s source code, permissions, and author reputation before installing.
Platform Compatibility
Not all plugins run on all platforms. The platforms field in plugin.json declares compatibility:
| Platform | WIT / WASM | Native Python | Lua |
|---|---|---|---|
| Cloud (app.studiobrain.ai) | Official guest: a Worker compiled at our deploy. Community: a panel and/or the author’s own backend. | No | No |
| Desktop (Tauri app) | Yes. wasmtime Cranelift. | No | No |
| Core (self-hosted) | Yes. wasmtime. | No | No |
| Mobile | Yes. wasmtime Pulley for WIT Components. The client host can also load an extism WASM guest. | No | Yes. Sandboxed Lua 5.4 in the client host only. |
The marketplace does not offer native Python or Lua. Cloud users only see plugins that can run on Cloud. A Python manifest is not a Desktop or Core plugin.
Security Model
Plugins declare the capabilities they need in plugin.json. The host enforces these declarations at runtime:
- Auto-granted capabilities (entity_read, asset_read, ai_generate) are safe and enabled by default.
- Consent-required capabilities (entity_write, asset_write, http_request) show a permission dialog before the plugin can use them.
- Platform-restricted capabilities (file_read, file_write) are blocked entirely on Cloud.
See the Permissions Reference for the complete capability matrix.
Next Steps
- Using the Marketplace — Browse, install, and manage plugins
- Getting Started — Scaffold and build your first plugin
- Creating Plugins — Full plugin development guide
- Permissions Reference — Capability system details
- Host Functions API — WASM host function reference