obsidianmd/obsidian-releases: what Obsidian actually downloads

Two unrelated jobs share one repository

obsidianmd/obsidian-releases does not hold the Obsidian application code. It hosts public releases of Obsidian together with the community plugins and themes directories that the app consults. Obsidian is not open source software, and this repository explicitly does not contain its source code, so the only route offered for changing the editor is the plugin system documented at https://docs.obsidian.md. Release tags v1.14.4, v1.14.5, and v1.15.0 were cut on 2026-10-05, 2026-10-22, and 2026-11-02, and the most recent push landed on 2026-11-02. For anyone tracking whether Obsidian ships updates, the tag list is the signal. For anyone tracking whether a plugin is still listed, the commit date is.

Plugin search reads three fields and stops there

Obsidian reads its plugin list from community-plugins.json at the repository root, and the name, author, and description fields are what it uses for searching. Nothing else in that file is indexed. When a user opens a plugin's detail page, Obsidian pulls manifest.json and README.md from the plugin author's own GitHub repository, so the listing stays small while the detail view is assembled from somewhere else entirely. The consequence is about discoverability. A plugin whose README explains its keywords, its data handling, or its platform support cannot be found by searching for that text, because search on the registry side stops at three fields. Authors who want to be found by anything other than their own name have to put those words into the description itself.

manifest.json is version discovery, not the installed payload

The manifest.json sitting in a plugin's repository has one job here: it figures out the latest version. The files a user installs are fetched from the plugin's GitHub releases rather than from the repository branch, and at install time Obsidian looks for a release tagged identically to the version inside manifest.json. Those two values have to be edited in lockstep. If the version inside the manifest moves ahead of the published tag, there is no release for the app to pull, while the manifest still advertises the newer number to everything that reads it. For authors that makes a version bump a two step operation spread across the manifest and the release.

versions.json decides what an older app gets instead

When a plugin's manifest.json requires an Obsidian version higher than the one running, Obsidian consults versions.json to find the latest plugin version compatible with the current build. That fallback is why plugins keep installing on machines that have not updated in months. The cost is that the build a user receives can be older than the one the author treats as current, and the version number alone does not reveal that the app made the substitution. The README does not document what happens when versions.json carries no entry for the running app, nor who is responsible for keeping that file complete, so authors have to reason about that case from their own release history instead of from a stated rule.

Three files get written into your vault

An install downloads manifest.json, main.js, and styles.css, the last one only if it exists, and stores them in the proper location inside the vault. The payload is therefore the author's own build, not anything this repository hosts or inspects, which puts the trust decision on the reader of the detail page rather than on the directory. The repository root also carries plugin-review.md, community-plugin-stats.json, community-plugin-deprecation.json, and community-snippets.json, files that the README does not explain, so the review and statistics trail visible from here amounts to the file names themselves. Users weighing an install are reading text fetched from the author's repository, with no review summary served from this side.

No issue tracker, and no documented removal rule

This repository does not accept issues. Bugs in a plugin belong in that plugin's own repository, and questions about core Obsidian go to the community at https://obsidian.md/community instead. For users that means a malfunctioning plugin cannot be reported by filing anything here, and the report has to reach an author who may not be watching that tracker. The root also holds community-plugins-removed.json and community-css-themes-removed.json, which record what left the directories, but no stated criteria explain what moves an entry into them or how long review takes. The single maintenance tool in the repository is prettier, pinned in devDependencies and driven by one script:

{
  "name": "obsidian-community-releases",
  "scripts": {
    "format": "prettier --write \"**/community*.json\""
  },
  "devDependencies": {
    "prettier": "3.5.3"
  }
}

The script exists to keep the community JSON files consistently formatted, and it touches nothing else in the repository.

Announcing a release is manual and role gated

Once a plugin or theme is admitted, telling anyone about it is a manual step rather than a feed. The first public release can be announced in the forums showcase at https://forum.obsidian.md/c/share-showcase/9 and on the Discord server at https://discord.gg/veuWUTm in the channel #updates, and posting in that channel requires the developer role, which is granted through a separate Discord permissions link. Beta before listing is an explicitly supported path: BRAT, referenced from https://obsidian.md/plugins?id=obsidian42-brat, lets you hand an early working version to testers before submitting officially. The consequence is that a first release carries no scheduled announcement, and the Discord half of it depends on a role grant whose timing this repository never describes.

Editorial conclusion

Plugin authors should treat this repository as a registry contract: match the release tag to the version in manifest.json, keep versions.json current, and publish before announcing anything. Users deciding whether an install is trustworthy should read the plugin's own releases and README rather than the listing, since the directory stores no plugin code and files no issues on anyone's behalf.

Frequently asked questions

Official sources

1. Issues
2. obsidianmd/obsidian-releases on GitHub
3. Project website
4. README
5. Releases