Publish to Hay

Direct publishing sends a code-only release to the Hay publishing service using the account signed into the desktop app. Choose Public marketplace · Everyone for public discovery or Personal registry · Only you to keep the release private to your account. It is different from exporting a local file or preparing files for a custom registry.

Before your first release

Sign in or create your Hay account and add the optional plugin you want to publish. If you chose a handle after email verification, that same profile is ready for publication. If you skipped it, open Account settings / Hay account in the app, Choose a handle on your web account page, or the profile form in Plugins / Share & publish. Enter Display name and Handle, review their public identity and permanent-handle notice, then choose Save profile. Setup is optional for using Hay, but required before public or private publication.

The handle is permanent in version 1: 3–32 lower-case letters or digits with single internal hyphens, starting with a letter. Choose it carefully.

The account service owns publisher identity. Changing a manifest’s author text does not grant ownership of another publisher’s namespace. Current publishing is personal; there is no organization or team selector.

Review the release

Open Plugins / Share & publish and choose the installed plugin.
In Publish to Hay, choose Public marketplace · Everyone or Personal registry · Only you, then a stable plugin name and release version.
Select Review publication. Check the destination and audience, plugin ID, author, version, requested capabilities, byte count and SHA-256 digest. Expand the code and manifest to review what will leave the Mac.
If the release is ready, select the confirmation for that destination: I reviewed this code and want to make this release public. or I reviewed this code and want to publish it to my private registry.
Choose Publish public release or Publish private release and wait for the matching receipt.

Plugin names are 1–48 lower-case letters or digits with single internal hyphens, starting with a letter. The full published ID must fit within 80 characters. Release versions use canonical major.minor.patch numbers without leading zeroes, with each component at most nine digits.

Only the installed code and manifest are included. Live records, documents, conversations, sources, credentials, granted capabilities, and previous-version snapshots are excluded. Content deliberately written into HTML or JavaScript remains part of the code, so review the source before publishing.

Publishing is a network action. A local export or a prepared registry folder has not been uploaded. Treat a release as published only after the service returns a successful release result.

Identity and ownership

The published ID combines your publisher handle and plugin slug, for example your-handle.little-notes. Publishing creates that release identity without renaming the local plugin or moving its records. Hay keeps the publication receipt alongside the installed plugin. The server checks the authenticated account’s ownership before accepting a release.

An account cannot publish into another account’s handle by changing a plugin ID or request body. A published release has a concrete version, exact byte count, and SHA-256 digest. Namespace ownership does not verify a publisher’s legal identity or guarantee code safety.

Release updates

The accepted release appears in Your published releases for the selected destination. Public and private histories are separate; switching the destination does not move a release or change its visibility. If a response is interrupted, refresh that list before retrying: the server may already have accepted the release.

Keep an existing release immutable. Publish changed code with a newer version rather than replacing a released ID/version with different bytes. Retain older releases so catalog consumers can verify or restore the original artifact.

Installation remains a separate action. Publishing a release does not grant capabilities to its users or change another workspace’s records. Registry updates retain their source, version, view, and review checks.

Read personal registries for private access boundaries and the marketplace guide for public discovery and reviewed install links. Neither path automatically updates a workspace or grants capabilities.

You can still use Export plugin file, Export source folder, and Prepare registry files for direct handoffs and self-hosted catalogs. A custom static registry does not need the Hay publishing service to serve its catalog and artifacts, although the desktop app itself requires Hay sign-in.

The registry hosting guide covers self-hosted release files. The registry contract describes the read-only catalog format.

API and hosting

The publisher API documents authenticated requests and release receipts for integrations. The account service guide covers deployment, durable storage and email delivery. These account operations are not plugin SDK methods.

Service availability

The default account/API origin is https://app.hay.so, and the public catalog remains at https://plugins.hay.so. Legacy account routes stay compatible. Earlier live inbox-code, publication, artifact, history and sign-out checks used the legacy account host with shared D1 storage; the default-origin move has a separate verification record. Hay’s production downloader and installer also installed the live artifact into a disposable fresh workspace with empty records and no grants. The first public release is halil.documents 0.1.1. Read the operator verification record for the exact scope.