Omarchy Plugin Marketplace: A Community Review Gate With Explicit Limits

What This Marketplace Actually Solves

The Omarchy Plugin Marketplace solves a discovery problem, not a security problem. It gives Omarchy users a single, community-curated index of plugins, each tied to a public GitHub repository that must contain a manifest, README, and license. The target user is an Omarchy adopter who wants to find plugins without scraping GitHub search or trusting a random repository. The project is independent of Omarchy and 37signals, per the disclaimer, so it is a community layer on top of an existing tool. The README is explicit that the marketplace does not provide downloads, installations, or verified votes. It catalogs, and it routes submissions through a review workflow. That is the scope, and it is narrow.

The Submission Workflow: Issues, Not Pull Requests

Submitting a plugin starts with a GitHub issue, not a pull request. The README links to a submit-plugin issue template, and the process requires a fresh exact-commit scan and an explicit approved-and-verified maintainer decision before anything is listed. This is a deliberate design choice: the marketplace treats the issue tracker as the front door, which keeps the review trail public and auditable. The submission guide, SUBMISSION.md, and the security policy in SECURITY.md are the two documents a prospective submitter must read. The requirement for a fresh scan at a specific commit means the maintainers review a known snapshot, not a moving target. That is a meaningful control, but it only applies at submission time, as the security notice later makes clear.

Two Verification Paths, One Exact Commit Rule

Once a plugin is listed, the verification form offers two routes. The first is to verify the currently listed snapshot, which accepts only the exact recorded SHA. The second is to publish a newer upstream commit, and that path keeps the current snapshot unchanged until the new target passes compatibility validation, the Automated Security Baseline, explicit maintainer approval, testing, and deployment. The asymmetry matters: a newer-commit request does not silently overwrite the listed version. If the new commit fails any step, the old snapshot remains live. This is a sound conservative design, and it is the strongest part of the workflow. The verification guide, VERIFICATION.md, explains display states and required values, but the README does not give the full state machine, so adopters should read that guide before relying on any listed status.

Engagement Metrics: What the Numbers Do Not Mean

The marketplace displays anonymous aggregate detail views, successful command copies, and hearts. The README is unusually precise about what these are not: they are not downloads, installations, unique people, verified votes, rankings, or security signals. Event bodies contain only the catalog plugin ID and a fixed action type, and the marketplace stores no accounts, cookies, IP addresses, user-agent strings, command text, or repository URLs in D1. This is a privacy-conscious design, but it also means the metrics are shallow. A heart is not a recommendation, and a command copy is not an install. For a user deciding whether to trust a plugin, the metrics are nearly useless. The project deserves credit for stating this directly, because most marketplaces blur that line.

The Security Baseline: Honest About Its Limits

The security notice is the most important paragraph in the README. It states that community plugins execute as unsandboxed code and may access or modify files, settings, credentials, and network resources. The marketplace performs limited automated checks on the identified commit and may conduct manual review, but these are not a security audit, certification, endorsement, or guarantee. Worse, the current install and update commands clone mutable upstream HEAD, so even a verified plugin can change after review unless the installed version is explicitly pinned to the reviewed commit. This is a genuine failure mode: a plugin can pass the baseline at commit A, then the maintainer pushes a malicious commit B, and the marketplace listing still points at the repository. The README tells you to review the source code and report suspicious plugins via the private security report form. That is the right advice, but it puts the burden entirely on the user.

Running It: Commands and Config From the README

The README does not provide installation commands for the marketplace itself, because the marketplace is a website and an issue-driven process, not a local tool. What it does give are the concrete actions a user takes: submit a plugin via the issue form, choose a category and one to three tags, and follow the CLI and AI submission guide in SUBMISSION.md. For verification, a user opens the verify-plugin form and selects either the listed snapshot (exact SHA only) or a newer commit. The underlying infrastructure is Cloudflare D1, mentioned in the privacy section, which suggests the site runs on Cloudflare Workers and D1 as the database. There are no config keys or CLI commands in the README beyond the submission and verification forms. If you want to run your own instance, the repository layout is JavaScript, but the README does not describe a build or deploy process. That is a gap for anyone who wants to self-host.

Alternatives and the Real Trade-off

The closest alternative is the Omarchy Theme Website by limehawk, which the README credits as inspiration for the marketplace structure and submission workflow. That project focuses on themes, not plugins, and it is a different repository with its own review process. The difference in approach is that the theme site is a direct source of curated themes, while this marketplace adds a verification layer on top of external repositories. Another alternative is simply using GitHub search or a personal allowlist of plugin repositories, which skips curation entirely but also skips the baseline checks. The trade-off is trust versus control: the marketplace offers a community vetting process, but it cannot enforce what upstream maintainers do after review. For a user who wants a lightweight index with a paper trail, this project works. For a user who needs a guarantee of safety, no marketplace can provide that, and this one does not pretend to.

Maintenance, License, and the Cost of Keeping Up

The repository is licensed under MIT, with a separate NOTICE.md for marketplace and third-party rights. That is a permissive license, so you can fork or reuse the code with minimal legal friction, but the README does not describe a release process or a changelog, and no recent releases were retrieved. The maintenance cost appears to be manual: maintainers must review submissions, run scans, and approve or reject verification requests. The reliance on GitHub issues means the process scales only as fast as maintainer attention. The security baseline is automated, but the final decision is explicitly a human one. For a project like this, the long-term risk is review backlog: if maintainers stop responding, the marketplace stagnates, and the listed plugins age. The MIT license means you could take over, but the domain and the D1 instance are not in the repo. Before adopting this as a dependency, check the issue tracker for response times and the last verified commit dates. The README gives you the workflow; it does not promise the workflow will be fast.

Editorial conclusion

Adopt the Omarchy Plugin Marketplace if you run Omarchy and want a community-curated index with a clear, issue-based submission and verification workflow. Do not adopt it as a security gate: the README states plainly that checks are not audits, and current install and update commands clone mutable upstream HEAD, so a listed plugin may change after review. Before installing anything, verify the exact commit SHA, read the plugin source, and pin to a reviewed snapshot if the tooling allows. The marketplace itself is honest about its limits; your own process must be just as honest.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository