Raycast Extensions: The Monorepo That Feeds the Raycast Store

What This Repository Actually Is

The raycast/extensions repository is the single source of truth for every extension listed in the Raycast Store. Raycast itself is a launcher that lets you control tools with a few keystrokes, but this repository is not the launcher. It is the collection of extensions, plus documentation and examples for building new ones. If you have used Raycast and installed an extension, that extension's code lives here. The README states that the repository contains all extensions available in the store, which makes it a rare example of a commercial product open-sourcing its entire extension catalog under the MIT license.

Who This Is For and the Problem It Solves

The repository solves a distribution and collaboration problem. Without it, extensions would be scattered across individual projects, and users would have no central place to discover or install them. For developers, it solves the question of where to put an extension once it is written. The answer is here. The target audience is anyone who wants to extend Raycast, from a hobbyist scripting a personal workflow to a team shipping an internal tool. The README points to the developer documentation at developers.raycast.com as the starting point, and the repository itself serves as both a codebase and a reference. If you are not a Raycast user, this repository has little direct value, because the extensions are useless without the Raycast runtime.

How the Repository Is Structured and How Extensions Get In

The repository is a monorepo written primarily in TypeScript, with the default branch named main. Each extension is a directory containing its own source code, assets, and a manifest that Raycast reads. The exact structure of that manifest is not described in the README, but the pattern is clear from the project's purpose. Extensions are not pushed directly to the store; they are submitted to this repository. The README instructs contributors to read the Community and Extension guidelines and the Acceptable Use Policy before submitting. This implies a review process: someone at Raycast reviews the code, checks it against the guidelines, and then merges it. Once merged, the extension becomes available in the store. That is a meaningful distinction from a typical open-source repository where anyone can fork and publish freely. Here, the repository is the gatekeeper.

Getting Started: Commands, Docs, and the Onboarding Path

The README gives a short onboarding path. It directs you to developers.raycast.com to get started with the API. There are no installation commands in the README, no npm install or yarn commands, and no CLI setup instructions. The repository itself is meant to be browsed, not run as a single application. To contribute, you would clone the repository, find the directory for an existing extension or create a new one, and follow the patterns you see there. The README also mentions example templates on the developers site that should help you get started. For a developer familiar with TypeScript and React, the examples are the practical entry point. The lack of a quick-start command in the README is worth noting; the actual setup steps live on the external documentation site, not in the repository.

The Submission and Review Process: A Real Constraint

This is where the repository diverges from a typical open-source project. You cannot simply publish an extension on your own. The README is explicit about following guidelines and the Acceptable Use Policy, and it directs feedback and issues to GitHub issue templates. That means Raycast controls what enters the store. For a developer, this is a double-edged sword. On one hand, it provides quality control and a consistent user experience. On the other hand, it means your extension may be rejected if it does not fit Raycast's vision, and you have no independent distribution channel. If you want to build an extension for internal use only, you can still use the repository as a reference, but you may not need to submit it. The review process is a genuine limitation if you value full control over your code's release cycle.

Licensing and Community Dynamics

The repository is licensed under MIT, which is permissive and allows reuse, modification, and distribution with attribution. That is a positive for developers who want to learn from existing extensions or borrow code. However, the MIT license applies to the code in the repository, not to the Raycast API itself. The API is proprietary, and the repository is a collection of clients for that API. So you can copy an extension's code, but you cannot reimplement the Raycast runtime without Raycast's permission. The community aspect is also notable: the README links to a Slack community and encourages joining to share extensions and debug bugs. This suggests a collaborative environment, but it also means that support is community-driven rather than guaranteed by a formal support contract. For a team evaluating this for internal tooling, the MIT license is a low barrier, but the dependency on Raycast's proprietary platform is the real cost.

Alternatives: Building Your Own Launcher or Using a Different Store

If the Raycast model does not fit, the alternative is to build your own launcher or use a different extension ecosystem. For example, Alfred has its own workflow format and store, and it is a closed-source application with a different extension model. The key difference is that Alfred's workflows are distributed independently, not through a central repository owned by the vendor. Another alternative is to use a scriptable launcher like LaunchBar or a terminal-based tool like fzf, where you write shell scripts rather than React components. The difference in approach is fundamental: Raycast extensions are React-based and run inside the Raycast process, whereas Alfred workflows are often file-based and triggered by keyword inputs. If you want to avoid a vendor-controlled store, those alternatives give you more freedom, but they lack the integrated UI and keystroke-driven workflow that Raycast provides. The choice depends on whether you value a curated ecosystem over independence.

Maintenance and Upgrade Cost

The repository is actively maintained, with a default branch and a clear issue template for API feedback. The last push date is unknown, but the README references current guidelines and a live Slack community, which suggests ongoing activity. The maintenance cost for a contributor is tied to the review process: if you submit an extension, you may need to update it when the Raycast API changes, and you must keep it aligned with the guidelines. The repository itself does not have a release cadence; extensions are updated individually. For a user, the upgrade cost is low because the store handles updates. For a developer, the cost is higher because you must track API changes and resubmit. The MIT license means you can fork the repository, but forking does not give you a store. That is a boundary worth noting: the code is open, but the distribution channel is not.

Editorial conclusion

Adopt this repository if you are a developer who wants to publish an extension for Raycast and are comfortable with the platform's review and guideline process. Do not adopt it if you are looking for a standalone toolkit to build a launcher from scratch; this is tightly coupled to Raycast's proprietary API and store. Before contributing, verify that your extension idea fits the existing community guidelines and acceptable use policy, and check the issue templates to see how API feedback is routed. The repository is the definitive home for Raycast extensions, but it is not a general-purpose project; it is a curated collection with a clear owner.

Official sources

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