Signed plugins: how to grow an ecosystem without becoming the bottleneck

There is a predictable life cycle for developer tools that succeed.

In version one, the core team writes everything. The tool is small, the surface area is small, the team controls the quality. Things ship fast.

In version two, the demand outruns the team. Users ask for integrations the team did not anticipate. The team starts saying no — not because the integrations are bad ideas, but because the team cannot review and maintain every possible extension. A plugin system is announced.

In version three, the plugin system is open. Anyone can publish. The ecosystem fills with extensions of wildly varying quality. Some are excellent. Some are abandoned. Some are subtly broken. Some are malicious. The core team spends most of its time mediating disputes and removing bad actors.

This is roughly the story of every package registry on the internet. We watched it happen to npm, to PyPI, to Chrome extensions, to VS Code marketplace. We decided we wanted a different version three.

The constraint

Avery NXR generates code that ships to production. The output of a plugin is not a UI tweak — it is the auth system, the billing flow, the database schema. A malicious or careless plugin is not an annoyance. It is a vulnerability in every application built with it.

That raises the stakes. A plugin system for Avery NXR cannot have the same trust model as a plugin system for a text editor. The blast radius is too large.

At the same time, we are not going to be the gatekeepers. The point of a plugin ecosystem is that the community can extend the tool faster than the core team can. If every plugin has to be reviewed and approved by us, we are the bottleneck we set out to avoid.

The signed plugin model is our answer.

How it works

Every plugin published to the Avery NXR registry has a cryptographic signature tied to a verified publisher identity. When a user installs a plugin, the desktop app verifies the signature against the publisher's public key before the plugin can run.

This does three things.

It makes the publisher's identity unforgeable. A plugin claiming to be from Stripe, Vercel, or Linear can be verified — or rejected — before installation.

It creates a chain of custody. If a plugin is later found to be malicious, every install can be traced back to a specific signed release, which can be revoked instantly.

It separates "verified publisher" from "verified-by-us." The signature does not mean Avery NXR has reviewed the code. It means the publisher is who they claim to be, and they are willing to attach their identity to what they ship.

We are not the trust root. The publisher is.

What the user sees

When a user installs a plugin, the install screen shows the publisher's verified identity, the plugin's signature, the audit ledger entry the install will produce, and a short summary of what the plugin will modify in the user's project.

For plugins from individuals, that's the individual's name and GitHub identity. For plugins from companies, that's the company's verified domain. For plugins from organizations, the same. There is no anonymous publishing in this model.

A user who installs a plugin from a verified publisher knows three things. First, who wrote it. Second, that the bits they are running are the bits the publisher signed. Third, that if something goes wrong, there is an identity to revoke.

What the publisher gets

For plugin authors, the signed model is a feature, not a tax. It is the difference between "anonymous npm package with a typo-squatted name" and "verified plugin from a recognized author." For consultants, agencies, and tooling teams who want to build on Avery NXR, the signature is their reputation, attached to their work.

We expect this to matter most for what we are calling vertical plugins — packs of generators tuned for a specific industry. A plugin from a fintech compliance team might ship the auth, audit, and PII-handling generators that a fintech startup needs out of the box. A plugin from a healthcare team might ship HIPAA-aware versions of the standard generators. In both cases, the publisher's identity is the trust signal that lets a regulated team adopt the plugin without a six-month security review.

The thing we are explicitly not doing

We are not building a moderated marketplace. We are not approving plugins. We are not the App Store.

What we are doing is making it impossible to lie about who wrote what. Whether the plugin is good, useful, or trustworthy is up to the user to decide — but the question of who is responsible has a definitive answer.

The bet is that this is the version three of a plugin ecosystem that works. Identity at the root. No gatekeeper in the middle. The community extends the tool, the publishers carry their reputations, and the core team gets to keep building the core.