120 million plugin downloads later, Obsidian moved off GitHub. Paid plugins are now allowed.

Steph Ango (kepano) published “The future of Obsidian plugins” on May 12, the same day Obsidian launched Obsidian Community. The new site rebuilds plugin discovery, adds a developer dashboard, runs automated reviews on every submitted version, and permits paid plugins for the first time. The Hacker News thread hit 360 points within hours, with kepano taking comments through the night.

The backstory is the part that makes this a real change instead of marketing polish. Obsidian’s plugin ecosystem has been gated on a manual review queue since 2020, run out of a GitHub repository. The queue worked when there were 100 plugins. It broke when “coding agents accelerate the creation of plugins” pushed the queue past 2,300 pending submissions, kepano wrote in the post. Manual triage couldn’t keep pace, and the bottleneck made shipping a new plugin “nearly impossible,” in the words of multiple developers on the forum feedback thread.

What actually shipped

On May 12, the team rolled out five concrete pieces. Each is live as of launch day, with the legacy GitHub flow still working for one more transition window.

• Obsidian Community site replaces the GitHub-only directory. Discovery now runs through a native interface with browsing, search, and filtering. The site processed 2,300 queued submissions in the days before launch.
• Developer dashboard for submitting plugins, managing releases, and viewing the automated review output. Closed-source plugins are still not accepted; the dashboard still requires a public GitHub repository for every submission.
• Automated review pipeline built on an open-source ESLint plugin. Every plugin version is scanned for security and code-quality patterns. Reviews “typically complete within minutes,” per the blog post. Failures pull the version from search within 24 hours.
• Safety scorecards on every project page. The disclosures plan covers what plugins access (network, filesystem, clipboard). Verified-author badges sit alongside the scorecard. Users can flag plugins they suspect of misbehavior.
• Three commercial tiers. Free, Optional payments (unlock features), and Paid (the primary feature is gated). Obsidian Community provides no payment infrastructure; developers route billing through their own processors.
• Existing plugins keep compatibility. No migration is forced. The new flow only governs submissions and version updates from May 12 forward.

Why this lands now

Two pressures collided. The first is volume. Obsidian’s plugin ecosystem crossed 100 million total downloads earlier this year, and kepano tweeted the milestone of 120 million in the blog post. A volunteer-driven manual queue can’t intake at that rate, especially as LLM coding tools cut the time-to-first-plugin from days to an afternoon.

The second is the AI-generated-content question, which is hanging over every distribution channel right now. RPCS3 publicly banned undisclosed AI pull requests this week on the maintenance burden argument. Obsidian’s response is mechanically the opposite: scale the review pipeline to match the inflow rather than gate the inflow itself. Both projects are answering the same question with different answers, and which one is right will probably be visible inside 12 months.

The HN comment thread mostly asked about the third pressure: security. Obsidian plugins run with the full permissions of the host application, which means filesystem access, network access, clipboard, and the entire DOM tree of the vault. The automated review catches obvious malicious patterns; it can’t read intent. Kepano’s response on HN acknowledged the gap and said a permissions model is in development but being phased to avoid breaking the existing 4,000+ plugin base. That’s an honest answer and also an admission that the safety scorecard is a UX hedge against a runtime that hasn’t been hardened yet.

What developers should plan for

If you maintain an Obsidian plugin, three changes affect your release cadence.

First, the review is now in the loop before users see your update. Plugins that pass scan within minutes; flagged ones go to manual review. Kepano said in HN comments that false positives are showing up (one plugin was flagged for containing “3” in its name). The fix path is the plugin-dev Discord channel.

Second, the safety scorecard is going to surface what your plugin actually does. If your plugin reads files outside the vault, calls home to a tracking endpoint, or imports a heavy third-party package with unclear provenance, the scorecard will show it. The honest move is to audit your own dependency tree before users see the disclosures and ask questions.

Third, the paid-plugin option opens the door to charging for a license without leaving the directory. The constraint that surprised some commenters is that closed-source still isn’t allowed: you can ship a paid plugin, but the source has to be public on GitHub. That’s a real limitation for plugins built around proprietary algorithms, and it’s likely to push commercial vendors toward an external dual-license posture (public AGPL or similar, plus a paid commercial license).

The bigger picture

Obsidian’s move makes it the second app-platform vendor in 2026 to rebuild its plugin distribution layer in response to the LLM coding wave. Panic banned generative-AI art and audio from the Playdate Catalog on May 3 from the opposite direction: refuse the slop at the door, accept the manual review cost. The Bazaar/Marketplace shape is going to be a 2026 theme across every major plugin host, including Figma’s, JetBrains’, and VS Code’s, all of which are publicly wrestling with similar inflows.

The interesting choice in Obsidian’s design is the absence of AI in the review pipeline itself. An ESLint-based scanner is auditable, reproducible, and free to operate. An AI-based reviewer would be faster at pattern recognition but harder to defend when it rejects a developer’s plugin and harder to scale within the Obsidian team’s headcount. The decision to keep the gating mechanism deterministic is the part that doesn’t get enough credit in the launch coverage.

What this means for you

If you use Obsidian, the immediate effect is that the plugin directory is going to grow faster and the bad ones should fall out of search faster. Watch the safety scorecards before installing anything new. Stop trusting a plugin’s GitHub star count as a proxy for safety; it never was a good signal, and the new directory makes that explicit.

If you maintain a plugin, get on the developer dashboard and submit your next release through it. The legacy GitHub flow still works for now, but the new path is where the discovery surface lives. Audit your dependencies before the safety scorecard makes them public.

If you’re shopping for a note-taking app and Obsidian’s plugin ecosystem was the reason you held off, the answer to “are the good plugins discoverable and the bad ones flagged” is “more than it was a week ago.” It’s still not “yes, with strong sandboxing.” Whether that’s good enough depends on what you’re storing.

If you run an IT team that already deploys Obsidian to staff, the policy.json work kepano floated last year on disabling community plugins and themes via command-line flags hasn’t shipped yet, but it’s the lever you’ll want once Obsidian Community starts surfacing paid plugins inside the in-app browser. Plan for a clearer plugin-allowlist control in the next few months, and treat the safety scorecards as a stopgap, not a security boundary. The Obsidian team has been honest that the runtime is unchanged; the discovery surface is what’s been rebuilt, and the responsible move is to keep auditing what your users install until the sandboxing roadmap lands.