Site Plugins
Add focused capabilities to a Boomlink site while keeping each plugin isolated, configurable, and scoped to that site.
Quick Answer
Boomlink plugins are site capabilities with declared settings, lifecycle behavior, and storage boundaries. An AI assistant can list, inspect, and configure them through Boomlink MCP.
Contact and Newsletter are first-party examples. They let a site offer visitor forms through ready-made part workflows and site-scoped data.
| Stage | What happens |
|---|---|
| Discover | List the plugins available to a site and inspect each plugin before changing its settings. |
| Configure | Enable a plugin and provide settings that match its declared configuration schema. |
| Use | Publish the site and let the enabled plugin handle its own routes, data, and visitor workflow. |
First-Party Plugins
Start with the plugin that matches the visitor workflow your site needs.
Contact
Adds a contact workflow whose messages stay within the site-scoped plugin data model.
Newsletter
Adds a newsletter signup workflow with confirmed opt-in behavior.
Configure a Plugin
Describe the result you want, then let your AI assistant inspect the plugin contract before changing settings:
"Enable the Contact plugin for this site and show me the settings I need to review"
Your assistant can discover the plugin, inspect its configuration, and apply a valid site-scoped update.
Ask your AI assistant to list the plugins available for the site.
Inspect the selected plugin to see its capabilities and settings.
Configure the plugin, review the site preview, and test the visitor workflow before publishing.
Storage and Isolation
Plugin data is scoped to the organization and site behind the plugin gateway. Published site activity uses the site's main data context, while authoring sessions remain isolated from that published context.
Each plugin owns its workflow and declared data contract rather than exposing a shared response-management surface. Review the selected plugin's contract before deciding how the site should handle visitor data.
Isolation is the reason plugins can be added without the conflicts a shared-runtime plugin system creates. Two plugins on the same site never share a table, a settings namespace, or a request handler, so enabling one cannot change the behaviour of another and removing one cannot strand the data belonging to the rest. That also means a plugin's records travel with the site rather than with the platform: the rows live in the site's own embedded database, and the site's data endpoint reads them with a site API key.
Two consequences are worth planning for. Configuration is per site, so a plugin enabled on one site is not enabled on the others in the same organization, and each site keeps its own settings. And because authoring sessions are isolated from the published data context, submissions captured by a live site do not appear in a preview, which is what keeps test entries out of your real records.
Available MCP Tools
Use the plugin tools to discover the current site state before applying a configuration change.
list-site-pluginsget-site-pluginconfigure-site-plugin