Skip to Content
DevelopersExtensions

Build Extensions

Extensions add focused capabilities to Lunaris projects. The app calls them extensions; source packages, manifests, and SDK APIs use plugin.

Start a plugin

Use the official creator from the Lunaris plugins repository :

npx @lunarisapp/create-plugin my-plugin
cd my-plugin
bun install
bun run typecheck
bun run build

The target directory must be new or empty. The scaffold derives initial metadata from the directory name; run npx @lunarisapp/create-plugin --help to see metadata overrides.

What an extension can add

The public @lunarisapp/plugin-sdk supports capabilities such as:

  • project content types and views;
  • scoped project data and collaborative documents;
  • actions attached to extension content;
  • sections for compilation workflows;
  • host-mediated HTTPS requests; and
  • MCP tools owned by the extension.

Use only public SDK entry points. Internal host APIs are reserved for Lunaris and do not carry the same compatibility guarantees.

Build and test

Before releasing a version, run the checks included by the scaffold:

bun test
bun run typecheck
bun run check
bun run build

The build validates the manifest, SDK compatibility, import boundaries, asset limits, and release-tag compatibility. It produces the self-contained plugin artifact expected by Lunaris.

External plugins run in sandboxed, opaque-origin frames and reach the host only through validated SDK capabilities. Keep the source public and document every use of workspace data or network access so reviewers and users can understand the extension’s behavior.

Publish through the registry

The curated plugin registry  publishes immutable artifacts by plugin ID and version. To submit a community extension:

  1. Host the plugin in a public GitHub repository.
  2. Set its manifest version.
  3. Tag that exact version without a v prefix, such as 1.0.0.
  4. Publish a non-draft GitHub release for the tag.
  5. Submit the plugin ID and repository through the registry repository .

Registry submissions are reviewed. Future releases are built from their exact GitHub tags, so published versions should be treated as immutable. Increase the manifest version for every update.

Use the repository’s canonical template  and curated examples as the current source of truth for project structure and release automation.

MCP