# Eclipse Open VSX: self-hosting the VS Code extension registry > Open VSX is a vendor-neutral, EPL-2.0 extension registry that replaces the Visual Studio Marketplace for editors that cannot access it by terms of service. Running your own instance needs PostgreSQL 16.2, a six-node Valkey 9.1 cluster, and optionally TimescaleDB for download analytics. **eclipse-openvsx/openvsx** — An open-source registry for VS Code extensions - Repository: https://github.com/eclipse-openvsx/openvsx - Website: https://open-vsx.org/ - Stars: 2,055 · Forks: 364 - Language: Java - License: EPL-2.0 - Published: 2026-10-11 · Updated: 2026-10-11 · Language: en - Canonical page: https://hysenlabs.com/projects/eclipse-openvsx-openvsx ## What VS Code editors need when the Visual Studio Marketplace is off-limits The Visual Studio Marketplace is operated by Microsoft, and its terms of service restrict which applications can connect to it. Editors that are not VS Code itself, including Eclipse Theia and VSCodium, cannot legally pull from that registry. Open VSX covers that gap: it implements the same extension API surface, so editors that need an alternative can point at a compatible endpoint instead. Three components make up the stack: a Spring Boot server that stores extension data in PostgreSQL, a web application that resembles the VS Code Marketplace, and a command-line tool named ovsx for publishing extensions, which the README compares to vsce. A public instance runs at open-vsx.org and is operated by the Eclipse Foundation. Organizations that need a private registry, an air-gapped catalog, or a mirror of another registry can run the server themselves. The project is vendor-neutral and governed by the Eclipse Foundation. ## Server, web UI, and CLI each carry their own version tag The three components do not share a single version number. On 2026-09-10, three separate tags landed: v1.2.0 for the server, webui-1.2.0 for the web UI, and cli-1.2.0 for the CLI. Tracking them separately means a deployment updating only the server can stay on an older web UI version, as long as you know which tag refers to which artifact. The CLI is published on npm under the package name ovsx. For a self-hosted registry, publishing an extension means pointing the CLI at your own endpoint rather than open-vsx.org. The web UI ships as both a Docker image and a library that other projects can embed. Inside the webui directory there are two separate build artifacts: the library and the default frontend. Each has its own build commands, and the relationship between them is a build ordering constraint that matters whenever incremental builds are set up manually. ## Starting a local instance: Postgres, Valkey cluster, and database search without Elasticsearch The recommended path for development is to open the repository in Gitpod, which starts the Spring server on port 8080 and the web UI on port 3000 automatically. For local work, the Makefile provides three targets designed to run in separate terminals. This starts the backing services: ```bash make dev-env ``` The Makefile comment names what this brings up: PostgreSQL, the Valkey cluster with its admin UI, and Silo. It also states what it deliberately omits: Elasticsearch is absent from these profiles, and database search fills in instead, controlled by the property `ovsx.databasesearch.enabled`. Elasticsearch is not required to bring up a working local registry. ```bash make server ``` This calls `./scripts/generate-properties.sh` and then `./gradlew runServer`, starting the Spring Boot server on port 8080. ```bash make webui ``` This runs `yarn install --immutable` followed by `yarn dev`, serving the frontend on port 3000 through Vite. The docker-compose.yml sets both the PostgreSQL user and password to `openvsx` and uses that same value as the Valkey cluster password. PostgreSQL 16.2 runs on port 5432, and the six Valkey cluster nodes listen collectively on port 7000 in the healthcheck configuration. ## The web UI library must compile before the default frontend can build Inside the webui directory, two build artifacts exist side by side: a library and a default frontend that imports from it. The dependency is explicit in the developer documentation: 'The default frontend depends on the compiled library, so make sure to build or watch the library before you build or watch the default frontend.' For a one-time build, run these in order: ```bash yarn build yarn build:default ``` The first builds the library. The second calls Vite to build the default frontend. Running them in the wrong order produces a frontend build that references missing compiled output. For incremental work, the matching pair is `yarn watch` and `yarn watch:default`, each running continuously in separate terminals with the library watcher starting first. A third option, `yarn start:default`, starts an Express server to serve the compiled frontend on port 3000. That is distinct from the Vite dev server that `yarn dev` starts on the same port. The `make webui` Makefile target runs `yarn dev` directly and avoids the ordering issue for straightforward development, but contributors who set up their own build pipeline need to observe it. ## Download analytics require a second PostgreSQL database on port 5433 with TimescaleDB Open VSX isolates download analytics in a second database rather than adding them to the main registry store. The registry runs on `postgres:16.2`. The analytics database runs `timescale/timescaledb:2.17.2-pg16` on port 5433, in a database named `openvsx_timeseries`. A comment in the docker-compose.yml explains the reasoning: keeping analytics in a purpose-built image means the registry database never needs the TimescaleDB extension. This profile is not part of the default dev environment. The Makefile's `dev-env` target starts `db`, `valkey`, `valkey-admin` and `silo`. The timeseries profile is absent from that list, so analytics are off unless you add it explicitly. The compose file defines a volume named `postgres-timeseries-data` for its data, separate from the main registry volume. A minimal Open VSX deployment can skip this database entirely. Whether download counts can be backfilled if analytics are enabled later is not documented in the repository. ## Docker image paths split at v0.33.0 when the repository relocated The repository was transferred from eclipse/openvsx to eclipse-openvsx/openvsx during its history, and the Docker image paths changed at the same boundary. Images up to v0.32.3 are at `ghcr.io/eclipse/openvsx-server` and `ghcr.io/eclipse/openvsx-webui`. Images from v0.33.0 onward are at `ghcr.io/eclipse-openvsx/openvsx-server` and `ghcr.io/eclipse-openvsx/openvsx-webui`. The README marks this with an IMPORTANT notice and describes both paths as remaining accessible to ease migration. Because v1.2.0 is at the new path only, a compose file that still references `ghcr.io/eclipse/openvsx-server` and tries to pin v1.2.0 will either fail to pull or serve a stale image from the old organization rather than the expected image. Updating the version tag without also updating the image path is a silent failure mode the notice documents but the compose file does not guard against. The notice does not give a date for removing the old packages. ## OAuth callback URLs reset per Gitpod workspace, and production configuration sits in four separate files Testing GitHub OAuth in development requires a GitHub OAuth application whose callback URL points at the workspace. A script in the repository returns the current URL: ```bash server/scripts/callback-url.sh github ``` According to the README, this URL changes with every new Gitpod workspace, so the GitHub OAuth app registration needs updating each time. Credentials go into Gitpod environment variables named `GITHUB_CLIENT_ID` and `GITHUB_CLIENT_SECRET`, bound to the repository. For a production deployment, the server's configuration properties, admin roles and permissions, deployment options, and mirror mode each live in a separate file: doc/configuration.md, doc/permissions.md, doc/deployment.md, and doc/mirror.md. Those files are named in the README but their content is not reproduced there. A first-time deployer reading only the README has to open four additional documents to configure a production instance. Bug reports for the open-vsx.org public instance go to a separate repository, EclipseFdn/open-vsx.org, not to this one. The project communicates through a Slack workspace and has its own CODE_OF_CONDUCT.md, CONTRIBUTING.md, SECURITY.md, and CLAUDE.md at the repository root. ## Conclusion Open VSX suits organizations running Eclipse Theia, VSCodium or any editor that cannot connect to the Visual Studio Marketplace by terms of service, and teams that need a private or air-gapped extension catalog. Teams where every developer uses VS Code against the hosted Marketplace gain nothing by running this stack. Before deploying, check which Docker image path your version requires: images up to v0.32.3 are at ghcr.io/eclipse/openvsx-server, while v0.33.0 and later are at ghcr.io/eclipse-openvsx/openvsx-server, and updating the version tag without updating the image path silently delivers the wrong build. ## FAQ ### What is Eclipse Open VSX? Open VSX is an open-source, EPL-2.0 registry for VS Code extensions, designed as a vendor-neutral alternative to the Visual Studio Marketplace for editors that cannot connect to it by terms of service. A public instance runs at open-vsx.org, and the server, web UI, and CLI are available to self-host. ### Can Open VSX run without Elasticsearch? Yes. The development environment deliberately omits Elasticsearch and uses the primary PostgreSQL database for search instead, controlled by the property ovsx.databasesearch.enabled. The Makefile comment names this explicitly as a design decision for the dev profile. ### How do I publish an extension to Open VSX? Publishing uses the ovsx CLI, available on npm as the ovsx package. The README compares it to vsce for the Visual Studio Marketplace. For the public open-vsx.org instance, the README refers to the EclipseFdn/open-vsx.org wiki for publishing and management steps. ### What databases does Open VSX require? A standard deployment requires PostgreSQL 16.2 for the registry and a six-node Valkey 9.1 cluster for caching. TimescaleDB 2.17.2 is needed only for download analytics and runs as a separate database on port 5433; it is off by default in the development configuration. ### Can Open VSX mirror another registry? Yes. The README points to doc/mirror.md for running Open VSX in mirror mode, described as running the registry as a copy of another registry. Configuration properties for that mode, along with admin permissions and deployment options, are each in a separate file under the doc/ directory. ## Sources - [eclipse-openvsx/openvsx on GitHub](https://github.com/eclipse-openvsx/openvsx) - [License: EPL-2.0](https://github.com/eclipse-openvsx/openvsx/blob/main/LICENSE) - [Project website](https://open-vsx.org/) - [README](https://github.com/eclipse-openvsx/openvsx/blob/main/README.md) - [Releases](https://github.com/eclipse-openvsx/openvsx/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/eclipse-openvsx-openvsx