On WordPress, a plugin is something you download and trust with your entire site. On emDash, plugins come from a registry designed on different principles: the publisher owns the record, the code runs in a sealed box with only the permissions you approve, and no single company can quietly take a plugin over. This piece explains what that means for an owner deciding what to install, without the protocol detail.
How it differs from WordPress
WordPress's plugin directory is one of the great achievements of open-source software: tens of thousands of plugins, free to install, covering almost anything a site might need. That openness has a cost, and owners pay it in maintenance and risk rather than money. emDash keeps the idea of a shared catalogue, which you can browse in the emDash plugin directory, but changes the terms on which a plugin enters your site. The differences are easiest to see side by side.
| Question | WordPress plugin directory | emDash registry |
|---|---|---|
| What can a plugin touch? | Everything the site can | Only the permissions you approve |
| Who holds the plugin's record? | The directory | The publisher, in their own account |
| How do you know the code is genuine? | You trust the download | Signed release, checked before install |
| What happens on an update that wants more access? | Nothing special | It waits for you to approve the new permissions |
| Can the directory remove a plugin? | Yes, centrally | The default catalogue can hide it; the signed release still exists |
What happens when you install
From the Registry section of the admin, you choose a plugin and a release, and emDash shows a consent screen listing exactly what that release asks for. Before that screen appears, emDash has already verified the release against the publisher's signed record and checked the downloaded code's checksum, name, version and requested permissions. If anything fails, installation stops.
Permissions are specific. A plugin might ask to read content, to change redirects, or to send requests to a named list of outside services. Approving one authorises exactly that and nothing more, and the isolation is enforced by the platform, not left to the plugin's author. The caution still applies: an approved permission is real. A plugin allowed to change redirects can redirect your visitors, so install only from publishers you trust.
When an update arrives that asks for more — a new permission, a new tool for AI agents, or a page that becomes public — emDash holds it until you approve. Uninstalling removes the code but keeps the plugin's stored data unless you choose to delete it.
Security by design
Plugins are where most WordPress security problems start: the emDash team cites a Patchstack whitepaper that attributes 96% of WordPress security issues to plugins. The reason is structural rather than a matter of careless authors. A WordPress plugin runs with the full authority of the site, so a single flaw in any one of them exposes everything.
emDash starts from the opposite assumption. A registry plugin runs in its own isolated runtime and receives nothing it has not declared and you have not approved. The platform, not the plugin's author, enforces the boundary.
| Protection | What it means for an owner |
|---|---|
| Capability gating | A plugin that did not ask to read content, send email or reach the internet simply has no way to do so |
| Named outside services | Network access is limited to the hosts the plugin listed at install; a request anywhere else fails before it leaves the sandbox |
| No access to the site's secrets | Sandboxed plugins cannot see environment variables, the file system or the site's platform bindings |
| Private storage | Each plugin's data is its own; one plugin cannot read another's records or settings |
| Resource limits | On Cloudflare, each call is capped at 50 milliseconds of processing and 10 outside requests, with a 30-second ceiling, so a faulty plugin cannot stall the site |
| Signed, checked releases | Code is verified against the publisher's signed record before it is installed |
| Consent on change | An update that asks for more access waits for your approval |
The model has honest limits, and they are worth knowing. Permissions are broad rather than fine-grained: a plugin allowed to write content can edit any entry, not only its own. Plugins added in the site's own configuration, as opposed to installed from the registry, run inside the site with full trust and none of these protections. And isolation contains damage; it does not make an untrustworthy publisher trustworthy. The practical rule is the same as for any supplier: grant only what the job needs, and prefer publishers with a history.
Extending a plugin with an AI agent
On WordPress, a plugin that does nine-tenths of what you need leaves three options: live with the gap, pay a developer, or install a second plugin to fill it. On emDash, a fourth option has become realistic. Most plugins in the directory are published under open licences such as MIT, and every emDash project ships with instructions written for AI coding agents, covering how plugins are built, which hooks exist and how they are tested, alongside a documentation server that agents can query directly.
In practice, a site owner can describe the missing feature to an agent such as Claude Code, Codex or Cursor and have it implemented in a working project, then reviewed and deployed. There are three sensible ways to do it.
A small plugin of your own that reacts to the same events — a publish, a form submission, a schedule — and adds the behaviour you need. The original stays untouched and keeps receiving updates.
Where the licence allows, copy the plugin and change it directly. Quickest for deep changes, but you take on its maintenance and lose upstream updates unless you merge them in.
Propose the feature to the publisher, with the code. Everyone benefits, and you keep receiving updates without carrying a fork.
This publication works this way. Its newsletter and editorial plugins were written with an AI coding agent against emDash's plugin interfaces, and each change goes through review and a preview deployment before it reaches the live site. The same permission model applies to a plugin you write yourself: declare only what it needs, and the platform holds it to that.
Who decides what is listed
The registry is built on the AT Protocol, the open network behind Bluesky. Publishers release plugins from their own accounts, and emDash runs the default catalogue, the emDash plugin directory. That catalogue is moderated: new listings are screened automatically for harmful or deceptive content, and anything flagged goes to a person for review. Moderation can hide a listing from the default catalogue; it cannot alter the release or transfer the plugin, and anyone can run another catalogue over the same publications.
For an owner, the practical point is resilience. A plugin's existence does not depend on one company's goodwill, and its identity and history travel with its publisher.
The cost and the catch
Registry plugins need a sandbox runner. On Cloudflare that is a Dynamic Worker, which requires the Workers Paid plan; on a self-hosted server it is a separate runtime process. A site on the free plan can still use plugins registered in its own configuration, which run inside the site without that isolation. That is how this publication runs its forms and newsletter. The trade is deliberate: configuration plugins cost nothing extra but are trusted fully; registry plugins cost a few dollars a month and are contained.
The registry is also young. Its record format is still marked experimental, and the catalogue is small next to WordPress's. Judge it on its design and its trajectory, not its size.
The options you have
- Running a WordPress site that works. The registry's security model is one of emDash's strongest arguments, but a young catalogue is a real limitation. List the plugins you depend on and check what exists today; see what is emDash for the wider picture.
- Commissioning a new site. Decide early whether the site needs registry plugins. If it does, budget for Workers Paid; if not, configuration plugins keep the free plan available. Costs are in what an emDash site costs to run.
- Running an agency. Publishing your own reusable plugins to the registry is a credible way to productise expertise, and the publisher-owned model means the work stays yours. Extending open plugins for clients, with an AI agent doing much of the implementation, is a service in its own right.