EmDash CMS Plugins
Last updated
EmDash plugins extend what the CMS and its sites can do, but there is more than one plugin model. Sandboxed plugins can be discovered and installed through the EmDash plugin registry when the site has the required sandbox environment. Native plugins instead form part of the Astro application and are installed through its project configuration.
That distinction matters for website owners and hosts because installation, permissions, updates and deployment responsibilities are different.
What is an EmDash plugin?
A plugin extends EmDash with additional behaviour or tooling. Depending on the plugin format, that can happen inside a restricted sandbox or as code loaded directly by the site's application.
Plugins are separate from themes. A theme supplies the website project, routes, presentation and starting content structure. A plugin extends behaviour within or around that project.
Sandboxed plugins
Sandboxed plugins run in a separate runtime provided by a configured sandbox runner. Their access is limited through declared capabilities rather than giving the plugin unrestricted access to the entire site process.
Sites with the appropriate sandbox configuration can browse the supported EmDash registry, review a plugin and its requested permissions, then install it through the EmDash administration interface.
This makes a registry plugin closer to an installable CMS extension than a change to the site's source repository, although the hosting environment still needs to support the sandbox infrastructure.
Native plugins
Native plugins run inside the same process as the Astro application. They can support capabilities that need deeper application integration, but that also means they belong to the website's deployed code.
Installing or changing a native plugin therefore requires an application deployment rather than only an administrator action in the CMS. A managed host needs to decide which native integrations it can support safely across customer sites.
How does the EmDash plugin registry work?
The official registry is the supported catalogue for sandboxed plugins. Administrators can search published packages, inspect information about the publisher and release, review requested permissions and install a selected version when the site's sandbox support is configured.
Updates repeat verification and permission checks. A change that expands what a plugin can do may require fresh approval rather than silently gaining new access.
The discovery side of the registry can also support external directories and search experiences, which creates room for the wider EmDash ecosystem to catalogue available extensions.
What should you check before installing a plugin?
- Who published it?
- What permissions or capabilities does it request?
- Does it need sandbox infrastructure or an application deployment?
- Is it compatible with the EmDash and application version you run?
- Who will be responsible for future plugin updates?
An extension ecosystem is useful precisely because plugins can do more than the base CMS. That extra capability is also why installation and update boundaries matter.
How plugins fit into managed EmDash hosting
A managed host can support plugins without turning every customer site into an unrestricted custom application. The useful model is to define which plugin formats and capabilities the managed platform supports, then keep deployment and recovery behaviour predictable.
DashHarbor also plans an optional EmDash-native integration for managed features such as recovery and safe updates. The actual protection engine remains outside the CMS so recovery does not depend on the plugin or editor being healthy.
For the wider design ecosystem, see EmDash themes. For managed application changes, see EmDash updates.