verdaccio on master installs a next-9 prerelease that needs Node.js 24

master installs a next-9 prerelease that needs Node.js 24

Read the version banner at the top of the README before anything else. This branch is the development one: version 6 requires Node.js 22 or higher and is maintained in the `6.x` branch, while this `master` branch requires Node.js 24 or higher. The install command it gives is pinned to a prerelease tag:

npm install -g verdaccio@next-9

That tag is `next-9`. The most recent published releases are v7.0.2 on 2026-10-26 and v7.0.1 and v7.0.0 on 2026-10-25, and the last push to the repository was 2026-11-01.

A reader who copies the command from this README gets a pre-release build on a Node.js 24 floor, whether or not that is what they meant. The project also notes that contributing guidelines may differ by branch, so the two lines are maintained as separate tracks rather than as one with a stable tail. Pick the branch first, then install.

Five install paths, and the Docker tag is a nightly build

Three global package managers, one image and one chart. The global installs resolve the same package under different flags:

yarn global add verdaccio@next-9

pnpm i -g verdaccio@next-9

The container path pulls a tag built from the tip of master:

docker pull verdaccio/verdaccio:nightly-master

A `nightly-master` tag carries no version number you can pin, so a deployment that tracks it changes without a release you chose. The Helm route is the one backed by a named chart:

helm repo add verdaccio https://charts.verdaccio.org
helm repo update
helm install verdaccio/verdaccio

Every path converges on the same three things, which the container command line spells out: a `verdaccio` binary, a config file, and a listen address.

The published image listens on every interface over plain HTTP

The Dockerfile is short enough to read as a specification. It builds on `node:26-alpine`, installs `openssl` and `dumb-init`, creates `/verdaccio/storage`, `/verdaccio/plugins` and `/verdaccio/conf`, and copies a config from the repository at `packages/config/src/conf/docker.yaml` to `/verdaccio/conf/config.yaml`. The environment it sets decides your security posture:

ENV VERDACCIO_APPDIR=/opt/verdaccio \
    VERDACCIO_USER_NAME=verdaccio \
    VERDACCIO_USER_UID=10001 \
    VERDACCIO_PORT=4873 \
    VERDACCIO_PROTOCOL=http \
    VERDACCIO_ADDRESS=[::]

Two values in that block matter. `VERDACCIO_PROTOCOL=http` means the image terminates no TLS itself, and `VERDACCIO_ADDRESS=[::]` binds every interface rather than loopback. Exposing port 4873 to a network without a proxy in front of it serves the registry over cleartext from every address the host has.

The process runs as UID 10001, a dedicated `verdaccio` user with no login shell, and `/verdaccio/storage` is the single declared volume, so that path is the state you must persist. `/verdaccio/conf` is created in the image but is not a declared volume, which means a config edit inside a running container is lost when the container is recreated unless you mount over it.

The repository's compose file builds from source and reads the port from the environment

`docker-compose.yaml` at the root is a developer artifact rather than the deployment story the published image tells:

version: '2.1'
services:
  verdaccio:
    build: .
    container_name: verdaccio
    environment:
      - VERDACCIO_PORT
    ports:
      - $VERDACCIO_PORT:$VERDACCIO_PORT
    volumes:
      - verdaccio-storage:/verdaccio/storage
volumes:
  verdaccio:
    driver: local

`build: .` means Compose compiles the registry from the checked-out source through the multi-stage pnpm build in the Dockerfile, so the first start includes a full install and build rather than a layer download. That is a different artifact from `verdaccio/verdaccio:nightly-master`, and worth keeping straight when you compare what is running in development with what ships.

The port comes from the environment with no default anywhere in the file, and the root carries a `.env` file. Run Compose without that variable set and the port mapping has nothing to publish. The `volumes` block declares `verdaccio` on the `local` driver, while the service mounts `verdaccio-storage`, so the two names do not match.

The built-in store is a tiny database, and object storage is a plugin

Verdaccio describes itself as a zero-config-required local private npm registry that comes with its own tiny database, which is the decision that separates it from a hosted service: nothing external has to be running before your first publish. On top of that store it proxies other registries such as npmjs.org and caches what it downloads, so a second machine on the same network installs from the cache instead of the public registry.

The cache has a stated reason to exist, and the README names three public npm incidents it is meant to blunt, linking to write-ups of a single developer breaking Node, Babel and thousands of projects, packages that suddenly disappeared, and a registry returning 404 for a package that had been installed before. Chained uplinks let several registries answer from one endpoint, and a modified third-party package can be published locally under the same name to override the public one.

Everything past the built-in store is a plugin. Amazon S3 and Google Cloud Storage support arrive through community-made plugins, and writing your own starts from a Yeoman generator:

npm install -g yo
npm install -g generator-verdaccio-plugin

That is where operational cost lands. The default is the built-in tiny database.

The e2e matrix is the compatibility claim you can check

Compatibility is tested rather than asserted, and the matrix is specific. End to end CLI tests run in CI through the separate `verdaccio/e2e-tests` repository using the `@verdaccio/e2e-cli` tool, on Node.js 24 and 26, against npm 10, 11 and 12, yarn modern 3 and 4, pnpm 10 and 11, plus the latest bun and deno.

That table is the honest answer to whether your toolchain is covered. npm 9, Yarn 1 and any pinned older pnpm sit outside it, and bun and deno are only exercised at whatever version is latest, so a release on their side is untested here until the matrix moves. The repository carries `cypress.config.ts`, a `cypress/` directory, `vitest.config.mjs` and the `@verdaccio/e2e-ui` package, so the web interface has its own test layer above the CLI runs.

For the registry's headline use, the README points at create-react-app, mozilla neutrino, pnpm, storybook, babel.js, angular-cli and docusaurus as projects that boot it for end to end testing, where the claim is a registry that can be booted in a couple of seconds and is fast enough for CI.

Volunteer-run, with no funding set aside for security research

The funding section is unusually direct about capacity. Verdaccio is run by volunteers, nobody works on it full-time, donations start at $1 per month, and the README states there is currently no funding available for contributions or security research. The root directory backs that up with FUNDING.yml, a SECURITY.md, a security.txt, CONTRIBUTING.md, CODE_OF_CONDUCT.md and an AGENTS.md.

For an organisation deciding whether to point builds at it, that sentence is the one to read twice. An internal registry is infrastructure, infrastructure attracts vulnerability reports, and this project says in its own README that it has no money set aside for that work. The response path exists as files in the repository; the staffing behind it does not exist yet.

The licence is MIT, with LICENSE at the root, so running it internally or modifying it carries no copyleft condition. The code is TypeScript in a pnpm workspace under `packages/`, translations are handled through crowdin.yaml, and dependency updates run through renovate.json.

Editorial conclusion

Verdaccio fits a team that needs private packages, a local cache in front of npmjs.org, or a registry that boots fast enough for CI runs, on a single host with a persistent volume. It does not fit an organisation that needs a funded security response or multi-region storage without first writing a plugin, because the README states there is no funding available for contributions or security research. Before installing, decide the branch, since the command on master pulls verdaccio@next-9 and requires Node.js 24 while the 6.x line requires Node.js 22, then check whether the HTTP port 4873 is reachable beyond your network boundary.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. verdaccio/verdaccio on GitHub