You need one when an allowlist is not enough: you ship internal extensions, work in restricted or air-gapped networks, or want to rehost public extensions after your own verification. For most small teams an allowlist is simpler. Per Microsoft's docs the private marketplace is currently available to GitHub Enterprise customers.
Definition
A private extension marketplace lets an organization host extensions on its own infrastructure and surface them inside the normal VS Code extensions view. The documentation lists features including self-hosting internal extensions, upstreaming public extensions from the public Marketplace even where internet access is restricted, allow lists, rehosting public extensions so the organization can apply its own verification, support for air-gapped environments, and deployment as a stateless Docker container. Rollout uses group policy on Windows and macOS.
Two limits from the docs are worth noting. Connecting from VS Code Server or VS Code for the Web is not supported, and users must sign in with an eligible GitHub account to use it.
Allowlist or private marketplace?
| Need | Allowlist | Private marketplace |
|---|---|---|
| Limit which public extensions can be installed | Yes | Yes, through allow list |
| Distribute internal extensions | Awkward | Designed for it |
| Work offline or air-gapped | No | Yes, through rehosting |
| Verify extension contents before anyone installs | Not directly | Yes, you rehost reviewed copies |
| Effort to set up | Low: a policy value | Higher: a service to run and update |
| Pin versions | Yes | Yes, you control what is hosted |
The allowlist control, extensions.allowed, is available from VS Code 1.96 and can be deployed through an organization policy. It decides what may be installed. It does not give you a copy of the extension that you verified.
Questions that point toward a private marketplace
- Do you build internal extensions that must not be public? Self-hosting gives them a proper distribution path with updates.
- Are some developer environments cut off from the internet? Rehosting is the documented route.
- Do auditors or customers expect that you verify third party code before it runs on developer machines? Rehosting reviewed copies gives you a place to apply that review.
- Do you need to see what is installed and when updates arrive? A service you run gives you logs the public service does not.
- Do you have someone to run it? It is a stateless container, but it is still a service with an owner, patches and uptime.
What it does not fix
A private marketplace moves trust to you. If you rehost an extension without reviewing it, you have moved the same risk to a new location with your name on it. The review process is the control, and the marketplace is how you enforce it.
It also does not change what extensions can do once installed. The extension host has the same permissions as the editor, so review remains essential.
A staged path
Start with the allowlist and an approved list. Add internal extension hosting when you have a real internal extension to ship. Move to rehosting when a customer, an auditor or a network restriction gives you a reason.
Where Safeguard fits
Safeguard's SBOM and dependency scanning can check the npm packages inside extensions you build before you publish them to a private marketplace. Try the free scan at gold.safeguard.sh/scan.
Quick check
Does a private marketplace make extensions safe?
No. It lets you control distribution and apply your own verification. Safety depends on the review you do before rehosting.
Can it work offline?
The documentation describes rehosting public extensions with support for air-gapped environments.
Sources
- Manage extensions in enterprise environments, Visual Studio Code documentation
- Extension runtime security, Visual Studio Code documentation
Last reviewed: 19 October 2026.
