How to Launch an Obsidian Plugin for Free: GitHub Release, Directory, Forum

Which files does the directory read from your repository?

Obsidian’s developer documentation for submitting a plugin (read on 13 November 2026 from its public docs repository) asks for three files in the root of the repository. The README says what the plugin does and how to use it, and an excerpt of it is shown on your listing, with relative image links rewritten to resolve against the repository, so screenshots committed to the repo will display. The LICENSE says how others may use the code. The manifest describes the plugin.

The directory reads the manifest at the head of your default branch, so what you commit is what it processes. Two rules in it matter on day one: the plugin id must be unique among all published plugins, and it cannot contain the word “obsidian”. Pick an id you will not want to change later.

If you started from one of Obsidian’s template repositories, the guide says you can skip the step of publishing to GitHub. Otherwise the reviewers need the source to be public, which is the whole premise of the directory.

Why does the release tag have to match the manifest?

Because that is how installation works. When someone installs your plugin, Obsidian downloads main.js, manifest.json and, if you have one, styles.css from the GitHub release whose tag equals the version in your manifest. A mismatch leaves the directory entry with nothing valid to download, and it is an easy stumble on this route.

1. Set version in manifest.json to a semantic version in the form x.y.z, such as 1.0.0 for the first release.
2. Create a GitHub release whose tag is exactly that version.
3. Attach main.js and manifest.json, plus styles.css if the plugin has styles, as binary files on the release.
4. Only then add the plugin to the directory.

The docs include a page on releasing with GitHub Actions, which turns the tag-and-attach routine into one push. It is worth setting up before your second release, when you will be tired of doing it by hand.

What does the automated review ask you to fix?

After you submit, the guide says the plugin is reviewed automatically and that the directory shows guidance for anything to correct. Your plugin will not be installable from inside Obsidian until errors from that review are resolved. You fix them by updating the repository and publishing a new release with a higher version number. You can edit the description and press Publish at any time.

The plugin guidelines show what reviewers look for, and they are specific enough to check yourself in an hour.

• No `innerHTML`, `outerHTML` or `insertAdjacentHTML` with user-supplied text. Build elements with the DOM helpers instead.
• Clean up on unload. Event listeners and other resources your plugin creates must be released when it is disabled.
• Sentence case in the interface. “Template folder location”, not “Template Folder Location”, and no word “settings” in section headings inside the settings tab.
• Quiet console. By default the developer console should show errors only.
• Rename the placeholders. The sample plugin’s MyPlugin and SampleSettingTab class names should become yours.
• Mobile. The guidelines include sections on Node and Electron APIs and on lookbehind in regular expressions, so check how the plugin behaves on mobile before you claim it works there.

What happens to updates after the first approval?

You only submit the first version. After it is published, users download new releases directly from GitHub inside Obsidian, so an update is a new tag and attached files, not another review of the listing. That removes the usual fear of shipping fixes in launch week, and it shifts the care onto your release routine: a broken main.js on a fresh tag reaches users at once.

Keep a short changelog in the release notes so the people who update can see what changed. If you want a ready structure, the changelog template has one.

A one-week plan

Where do Obsidian users hear about a plugin?

The guide names two places for announcements: the Share and showcase category of the Obsidian forum, and the #updates channel on Obsidian’s Discord, which needs the developer role to post in. Lead with the problem in note-taking terms, such as “find notes you forgot linking to”, and attach a short clip of the plugin working on a real vault.

Add a public page that points to the repository by choosing to launch your plugin on this board. It costs nothing, takes one verified email, and gives you a followed link to the repository or the listing. Note-taking tools sit close to the productivity ideas other builders post, and where to launch Obsidian plugins lists more venues. If you want your first ten testers to be honest, feedback on an MVP explains how to ask without leading them.