A local tool, a shared release

A useful plugin often starts small: a reading list, a project tracker, a place to prepare a brief. You make it for the work in front of you. Sharing it should pass along the tool, with a clear boundary around the work you have already put into it.

That boundary shapes Hay’s plugin flow. There is editable source, there is the copy installed in a workspace, and there is a release someone else can install. Each has a different job.

Keep a place to make changes

A source project is a folder with a manifest and self-contained HTML. You can edit it, put it in Git, review changes, and build a package from it. A personal interface created in Hay can also be exported into this form.

The installed copy is saved inside a Hay workspace. It has that workspace’s records and permissions. Changing a file in the original source folder does not silently change the code running there. An update is a deliberate step.

Share the tool without packing up the workspace

The sharing flow exports installed code and its manifest. Saved notes, documents, conversations, sources, credentials and permissions stay in the workspace. The recipient imports a plugin file, reviews access, and starts with their own records.

This is a code boundary, so code still deserves a review. Text deliberately embedded in HTML or JavaScript is part of the exported tool. A workspace export is a different thing and should not be used as a shortcut for sharing a plugin.

Give a release a stable identity

For a direct handoff, a plugin file is enough. A registry adds discovery and a place to find new versions. Its catalog points to versioned packages with exact sizes and SHA-256 digests.

Released bytes should stay put. When a plugin changes, give it a newer version and add a new artifact. Hay can then distinguish the installed release from an available update. Updates from the same recorded registry preserve records, retain saved views, and ask the user to review capabilities again.

A digest tells Hay that a download matches the selected catalog. Hay’s account-backed publishing service separately checks that a release belongs to the signed-in publisher’s namespace. Neither check guarantees code safety or verifies a publisher’s legal identity.

Prepare first, publish deliberately

Hay can prepare a static registry folder with a catalog and immutable artifacts. That output can be hosted on one HTTPS origin and connected as a custom registry. Saving the folder does not upload it.

The direct-publishing flow adds a Hay account, shared across the workspaces on a Mac, and a personal publisher handle. The account is required to use the app, while workspace records remain local. A public release uses the publisher’s handle and a plugin name, without renaming the local copy or moving its saved records.

The service routes at accounts.hay.so and plugins.hay.so are deployed with D1 storage. The free-plan setup uses a verified external email sender. A real inbox code has now verified account sign-in, followed by an owned public release, release-history checks and sign-out. The first release is Documents 0.1.1 under halil.documents; its public artifact was also installed with Hay’s production downloader and installer into a fresh disposable workspace with empty records and no grants. A prepared local folder is still different from a published release.

If you are building a tool to share, start with the plugin quickstart. If you already have one, the sharing guide walks through the export, and registry hosting covers the release files.