obsidianmd/obsidian-releases: what the repository actually contains

What obsidian-releases is, and what it is not

The name invites a wrong assumption. This repository does not hold the source of Obsidian. The README says so directly: Obsidian is not open source software and this repo does not contain the source code. What it holds is distribution and cataloguing. Desktop builds are published here as releases, and the community plugin and theme directories live here as JSON. The repository also does not accept issues. Plugin problems go to the plugin's own repository, and questions about the app itself go to the community forum.

The audience is therefore narrow and specific. Plugin and theme authors use it as the submission endpoint: the README links to separate submission guides for plugins and themes under docs.obsidian.md. Tooling authors use it as a machine-readable index of what exists in the ecosystem. Someone who wants to read Obsidian's internals, patch it, or file a bug against the core app is in the wrong place, and the README tells them so rather than leaving them to discover it.

The JSON files that make up the directory

The repository root is the whole design. There is no build step, no server, and no database. The catalogues are flat JSON files committed to master: community-plugins.json for plugins, community-css-themes.json for themes, community-snippets.json for snippets. Alongside them sit the removal ledgers, community-plugins-removed.json and community-css-themes-removed.json, plus community-plugin-deprecation.json and community-plugin-stats.json.

That split is the interesting part. A plugin that disappears from the main list does not simply vanish; there is a separate file recording removals, and another recording deprecation. For anyone auditing the ecosystem, those ledgers are the only place the history is visible. The package.json is minimal: a name, a single format script, and prettier pinned as the only devDependency. The format script runs prettier over the community JSON files, which is the whole quality gate the repository imposes on its own data. Everything else is review policy, documented in plugin-review.md and the developer policies.

How Obsidian resolves a plugin at install time

The README describes a fetch sequence that is worth reading closely, because it explains why plugin repositories must be structured a particular way. Obsidian reads the plugin list from community-plugins.json. The name, author and description fields are used for searching. When a user opens a plugin's detail page, Obsidian pulls manifest.json and README.md from that plugin's GitHub repository.

Installation is a second, separate step. Obsidian looks for a GitHub release tagged identically to the version inside manifest.json, then downloads manifest.json, main.js and styles.css if present, and stores them in the vault. The manifest in the repository is used only to determine the latest version; the actual files come from the GitHub release. Compatibility adds one more lookup: if the manifest requires a newer Obsidian version than the running app, versions.json in the plugin repository is consulted to find the newest compatible release. This means a plugin author who tags a release differently from the manifest version breaks installation, and one who omits versions.json breaks installation for users on older app builds.

Installing Obsidian and listing the directory

Obsidian itself is not installed from this repository. The README points to obsidian.md and the community forum for the app; this repo hosts the public releases and the directories. If you want the catalogue as data, clone it and read the JSON. The package.json defines exactly one script, so the local workflow is short. The only command the repository itself declares is this one:

npm run format

That script is defined as prettier --write "**/community*.json", which rewrites the community JSON files in place. Run it on a clean working tree if you want to see what it changed. The devDependency it relies on is pinned as prettier 3.5.3.

To inspect the plugin list without running anything, open community-plugins.json at the repository root. The README notes that the name, author and description fields are the ones Obsidian searches, so those are the fields worth indexing if you are building anything on top of the file. There is no documented CLI for querying the directory; the JSON is the interface.

Where the repository stops being useful

The README documents the plugin list schema only partially. It names name, author and description as the searchable fields and stops there. The remaining keys in community-plugins.json, and the entire shape of community-plugin-stats.json and community-plugin-deprecation.json, are not described in the README at all. Anyone consuming those files is reading an undocumented schema that can change between commits.

The repository is also not a support channel, by design. It does not accept issues. If a listed plugin is broken, the README routes you to that plugin's own repository, and if the app is broken, to the community forum. That is a reasonable boundary for a distribution repo, but it means the directory cannot tell you whether a listed plugin still works. A plugin can be present in community-plugins.json and effectively abandoned, and the file will not say so. The deprecation and removal ledgers are the closest thing to a signal, and they record a decision rather than a diagnosis.

The last push to master was on 2026-09-20, and the most recent release listed is v1.13.8 on 2026-08-21. Those dates describe repository activity, not the quality or maintenance of any individual plugin in the list.

Alternatives and how they differ

The obvious alternative is not another directory but the plugin repositories themselves. If you need to know whether a specific plugin is maintained, its own GitHub repository is the only source: this repository records that a plugin is listed, not when it was last updated. The trade is coverage against freshness. community-plugins.json gives you the whole catalogue in one file with a consistent shape; the individual repositories give you commit history and release cadence but require one request per plugin.

A second alternative is the in-app plugin browser. It reads the same JSON and resolves the same manifest and release files, so it is the same data through a different interface. The difference is that the browser is the supported path for installation, while reading the JSON is the supported path for analysis. If your goal is to install a plugin, use the browser. If your goal is to answer questions about the ecosystem as a whole, the JSON is the only form that lets you do it offline.

Licence, contributions and the cost of staying current

The repository does not state a licence in the files listed at its root, and the README is explicit that Obsidian itself is not open source. The plugin and theme entries are metadata about third-party work, each governed by its own repository's licence, not by anything here. Treat the JSON as an index of pointers rather than a grant of rights, and check the individual plugin repository before redistributing anything.

Contributions arrive as submissions, not pull requests against app code. The README links to the plugin and theme submission guides and requires conformance with the developer policies. There is also a cla.md at the root. For a plugin author, the upgrade cost is the tag discipline described above: manifest.json version, GitHub release tag, and versions.json have to stay consistent, or installation fails for some or all users.

For a consumer of the data, the cost is tracking an undocumented schema. The only maintenance machinery in the repository is the prettier format script, which normalises formatting rather than validating meaning. Nothing in package.json validates that a new field is documented, so a consumer parsing community-plugins.json should pin to a commit and diff before upgrading rather than assuming the shape is stable.

Editorial conclusion

Adopt this repository as a data source if you are building tooling over community plugins or themes, or if you are publishing a plugin and need to understand the submission path. Do not adopt it if you want Obsidian's source code: the README states plainly that Obsidian is not open source and that this repo does not contain it, and issues filed here are not accepted. Before relying on any field, verify it against the live community-plugins.json and community-css-themes.json on master, because the README documents only the name, author and description fields as search inputs and leaves the rest of the schema to the JSON itself.

Frequently asked questions

Official sources

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