Launch a Raycast Extension for Free: Your Launch Is a Pull Request
Launch a Raycast extension by opening a pull request: running npm run publish authenticates you with GitHub and opens one against Raycast’s public extensions repository, where the team reviews it and, once accepted, publishes it to the Raycast Store automatically. Prepare with npm run build, an MIT license, a 512 by 512 icon that works on light and dark themes, and a title written to Raycast’s naming rules. Announce after the merge.
Your launch is a pull request
Raycast’s publishing page puts it in one sentence: run npm run publish in the extension directory and the script opens a pull request in the raycast/extensions repository after you sign in with GitHub. The team reviews the pull request and asks for changes where needed. When it is accepted and merged, the extension is published to the Raycast Store automatically. There is no separate submission form and no store dashboard to learn.
Two practical details come from the same page. The publish command squashes your commits and their messages, so if you want your history preserved, fork the repository and open the pull request by hand, which the page describes as the alternative. And if anyone else edits your extension on GitHub, npm run publish fails until you run npx @raycast/api@latest pull-contributions to merge their changes in.
The checks that fail first
Raycast’s “prepare an extension for the Store” page is a checklist written by the reviewers, and most of it is mechanical. Work through it before you publish, because each miss costs a round trip with a person.
- Author: your Raycast account username in the
authorfield ofpackage.json. - License:
MITin thelicensefield. This is a requirement, not a suggestion, and it has consequences covered below. - API version: the latest Raycast API version, and a
platformsfield that matches what the extension needs if it uses platform-specific features. - Dependencies: installed with npm, with
package-lock.jsonincluded in the pull request, because Raycast’s build server uses npm and wants to match your versions. - A distribution build: run
npm run buildlocally, which type-checks and builds for distribution, then open the extension in Raycast and try it.npm run lintcatches style problems that the automated GitHub checks will also run. - Third-party terms: read the terms of service of any service your extension calls.
The icon has its own rule: a PNG at 512 by 512 pixels that looks right on both the light and dark themes. Raycast offers an icon maker and a template for it. Switch your theme in preferences and look at the icon on both before you submit.
Naming is part of the review
Few launch platforms review wording, and this one does. The same page asks for titles in the Apple Style Guide convention, so “Hacker News” and not “Hacker news”, and says the extension title should tell a person browsing the Store what it does. A one-command extension should be named close to that command.
| Item | Preferred | Avoid |
|---|---|---|
| Extension title | A specific noun phrase, such as “Emoji Search” | A generic word on its own, such as “Converter” or “Utils” |
| Command title | Verb then noun, such as “Create Task” | Noun then verb, such as “Task Create” |
| Title words | Nouns over verbs where it reads naturally | Articles inside command titles |
| One-command extension | A title close to the command, such as “Notion Search” | The bare product name, which suggests more than it does |
Write the one-sentence description last and show it to someone who has never heard of your idea. It is what appears in the Store’s list, so it has to work without a screenshot beside it.
What does publishing in the open repository commit you to?
The extension lives in Raycast’s public repository under an MIT license, so anyone can read, copy and adapt your code. That suits small utilities and integrations, and it does not suit a product whose value is in secret logic. If the clever part has to stay private, keep it behind a service your extension calls, and say plainly in the description that the extension needs an account.
It also changes how you think about support. Because contributors can send changes, your extension may receive pull requests after launch, and the page tells you what to do when they do. Decide now whether you want that, and say so in the README.
A two-week schedule
- Days 1 to 4: build the one command that matters most, and use it yourself every day.
- Days 5 and 6: the metadata pass: author, license, platforms, lockfile, icon, titles and description.
- Day 7:
npm run build,npm run lint, thennpm run publish. Read the pull request page for automated check results. - Days 8 to 13: answer reviewer comments the same day they arrive; prepare a short screen recording of the command in use.
- Day 14, after the merge: open Manage Extensions in Raycast, find your extension and copy its link with the shortcut the docs give, then announce.
The docs add a candid note that the team is still working out its guidelines, so treat the schedule above as an estimate and not a promise. A review that is slow is not a signal about your idea.
Where do Raycast users hear about extensions?
The people who use Raycast are people who like to shave seconds off a task, and they trade tips in communities of their own, which the docs point to for questions. Share a short clip in the place where you asked for help while building, and describe the workflow, not the feature: “search my bookmarks without leaving the keyboard” beats “a bookmark extension”.
Because the code is open, a Show HN post fits well: people can read it and try it. A public page on this board adds a followed link to your Store page. You can launch it free with one verified email and no queue, and then browse the productivity ideas other builders have posted to see what workflow gaps are still open. The places for Raycast extensions list more, and the developer tool playbook is a close cousin when your extension serves coders.
Frequently asked questions
How do I publish a Raycast extension?
Run npm run build to validate it, then npm run publish. The script asks you to sign in with GitHub and opens a pull request in Raycast’s extensions repository. After the team accepts and merges it, the extension is published to the Raycast Store automatically.
Does a Raycast extension have to be open source?
The extension is published through a pull request to Raycast’s public repository, and the preparation page asks for the MIT license in package.json. In practice your extension’s code is public. Keep proprietary logic behind a service that the extension calls.
What icon size does the Raycast Store need?
Raycast’s preparation page asks for a PNG at 512 by 512 pixels that looks good on both light and dark themes. It suggests checking the icon after switching theme in Raycast’s appearance preferences, and provides an icon maker and template to help.
How long does Raycast review take?
We could not find a stated review time on the pages we read. The publishing page says the team reviews the pull request and requests changes when required, and that it is still updating its guidelines. Reply to feedback quickly, since your own turnaround is the part you control.
Written by Post your build ideas with AI assistance and edited for this site. Where a page names another product, the facts came from that product’s own pages on the date shown above; terms change, so check them before you rely on them. About the publisher.