Launch a VS Code Extension for Free: Marketplace, Open VSX and the Token Change
Launch a VS Code extension by publishing it with the vsce command-line tool under a publisher id, then repeating the upload on Open VSX so editors built from VS Code’s open-source code can install it too. The Marketplace page is your README, so write that first. Microsoft’s publishing page says Azure DevOps global personal access tokens retire on 1 December 2026 and recommends trusted publishing from GitHub Actions, so set up that route before your first release.
What is different about a product that lives in the editor?
Your users are already looking at a code file when they find you. They open the Extensions view, type a word and scan the results, so the name, the first line of the description and the icon do most of the selling. A blog post cannot rescue a listing that reads like every other “formatter” in the results.
The other difference is that publishing is a command, not a form. You package the extension into a .vsix file and publish it with vsce, the command-line tool Microsoft documents for packaging, publishing and unpublishing. That makes a release repeatable and scriptable, and it means the launch can be rehearsed on your own machine long before anyone sees it.
Do you need both the Marketplace and Open VSX?
Plan for both, because the editors that share VS Code’s code do not all read the same catalogue. Open VSX is an open registry run by the Eclipse Foundation, and its publishing wiki lists a separate path. A developer using one of those editors will never see your Marketplace listing, and an extension missing from their registry is simply absent.
| Visual Studio Marketplace | Open VSX | |
|---|---|---|
| Account | A publisher, managed through Azure DevOps services | An Eclipse account, then a signed Publisher Agreement |
| Identity for uploads | A token, or trusted publishing from GitHub Actions or Azure Pipelines | An access token |
| Name space | Your publisher id | A namespace you create |
| Extra step | None named on the publishing page | Extension scanning after upload |
Do the Marketplace first, since most of your readers will use it, and add Open VSX once the first version is stable. The upload is the same .vsix, so the second registry is an hour of paperwork, not a second project.
What does the README need to do?
The publishing page says the README.md at the root of the extension becomes the content of the Marketplace page. Treat it as a landing page with a job: show the extension working in the first screen, name the command or shortcut that starts it, then list settings. Put an animated capture above the fold, since people scan an editor listing the way they scan a store shelf.
The tooling is strict about images, and a launch-day failure on this is avoidable. Microsoft’s page says the icon in package.json may not be an SVG, and that image addresses in the README and the changelog must be https URLs, with SVGs allowed only from trusted badge providers. Run the packaging step and read the warnings a day early. The VS Code Marketplace listing requirements page tracks the full set, and a ready README template gives you the order of sections.
- First line: what the extension does, in the words a developer would type into the search box.
- A GIF or short clip of the result, not of the settings panel.
- One command or keybinding that gets a first result in under a minute.
- A changelog that starts at 0.1.0, so the page does not look abandoned on day one.
What is the credential change, and why do it before launch?
Microsoft’s publishing page says the Marketplace uses Azure DevOps for authentication, hosting and management, and carries a notice that global personal access tokens in Azure DevOps retire on 1 December 2026. It recommends publishing without stored long-lived secrets, and documents a trusted publishing route from GitHub Actions and one from Azure Pipelines using Microsoft Entra ID. It also says other CI providers are not supported for trusted publishing. The page appeared to be a work in progress when we read it, so confirm the steps against the live version.
The practical advice is simple. If you plan to ship updates after launch, which you will, build the release workflow around trusted publishing now. Otherwise your first patch release, probably on the busiest day of your life, is the day you discover your token stopped working.
What can you do in ten days?
- Days 1 and 2: register the publisher, settle the extension name and id, and package a rough version locally to see the page the README will produce.
- Days 3 to 5: write the README and record the clip. Install the packaged file in a clean profile and follow your own instructions exactly.
- Day 6: wire a release workflow with trusted publishing, then publish a 0.1.0 with the
--pre-releaseflag the page documents, to test the path end to end. Pre-release and regular versions must differ, so your public launch is a higher number. - Day 7: do the Open VSX paperwork: Eclipse account, publisher agreement, token, namespace.
- Day 8: hand the
.vsixto three developers who did not build it and watch for the first thing they misread. - Days 9 and 10: publish 1.0.0 to both registries, then announce.
Where do you announce it?
Open with places that read code. A Show HN post needs a way to try the thing without a sign-up, and a published extension has exactly that, so the Show HN playbook is a natural second stop. Then post in the community of whatever language or framework your extension serves, as a short note on the problem rather than a link drop. The list of places for VS Code extensions goes further.
To get a public page with a followed link to your listing, launch your product here: verify one email address, press publish, and it is live. Builders browsing the developer tool ideas are the audience that tends to open an editor extension link. Nothing here can promise installs, so tag the link and count them yourself.
What should you look at after release?
The publisher dashboard shows installs, so compare them with the days you posted. For a signal that survives the first spike, add one line to your issue template asking how people found the extension. Ten answers are enough to see which announcement carried weight, and the issues themselves will show whether the README promised more than the extension does.
If you want a second opinion on the idea before you invest more, the developer tool ideas guide lists gaps other builders have named, and the MVP scope planner helps you cut a first version to one command.
Frequently asked questions
Is it free to publish a VS Code extension?
Microsoft’s publishing page describes creating a publisher and using vsce, and we found no fee mentioned there. Open VSX asks for an Eclipse account and a signed agreement. Confirm both before relying on this, since terms change, and note that a listing alone brings no installs.
What is Open VSX and should I publish there?
Open VSX is an open registry operated by the Eclipse Foundation, used by editors that are built from VS Code’s open-source code but do not use the Microsoft Marketplace. Publish there if your users might work in such an editor. It is the same package file and a short account setup.
What changes on 1 December 2026?
Microsoft’s publishing documentation says global personal access tokens in Azure DevOps are retired on that date, and recommends trusted publishing from GitHub Actions or Azure Pipelines. If your release process stores a token, move it to the documented trusted route before then. We read the page on 13 November 2026, so check it again.
Why was my README image rejected when packaging?
The publishing tool checks image rules: the icon in package.json cannot be an SVG, and README and changelog images must use https addresses and cannot be SVGs unless they come from trusted badge providers. Convert the icon to PNG, host images over https, and re-run the package command.
How do I get my first installs?
Make the Marketplace page clear enough that a search result converts, then announce where developers read: a Show HN post, a language community, and a free launch board. Tag each link and compare the install counts after each post. Nobody can promise a number of installs.
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.