Should I upgrade to Verdaccio 6 now?
Decide whether to upgrade your private npm registry now as Verdaccio 6 changes auth and runtime assumptions used by older CI environments.
Blockers
- requires_version: package/verdaccio-6 → runtime/nodejs-18
- npm 9+ defaults to web login, which is not supported for Verdaccio; automation must avoid that path or force --auth-type=legacy.
- Verdaccio 5.x fails to start if the .verdaccio-db secret is still 64 characters long.
- Lock-in via format/legacy-aes-signature
- Lock-in via protocol/jwt
Who this is for
- cost-sensitive
- small-team
- enterprise
Candidates
Upgrade to Verdaccio 6 after standardizing on Node.js 18+ and non-web auth flows
Verdaccio's official installation docs for the 6.x line require Node.js "v18 or higher" and show a 6.0.0 startup example; as of 2026-03-27, that makes Node 16-era registry hosts and maintenance jobs an immediate blocker. Official npm setup docs also say npm 9+ splits `login` and `adduser`, defaults to web login, and that web login is not supported for Verdaccio, so automation must avoid that path or force `--auth-type=legacy`. Verdaccio's configuration docs still default API tokens to a legacy AES-based signature, while JWT is optional if you want expiration behavior. This path fits teams that can update the registry host runtime and CI auth conventions in one pass.
When to choose
Use this when you can require Node 18+ everywhere that actually runs Verdaccio and your CI can move away from interactive or web-based npm auth assumptions. It is the cleaner long-term choice if you also want to adopt JWT-based API tokens instead of relying on legacy non-expiring signatures.
Tradeoffs
You get onto the supported major line and remove the need to preserve older host runtimes, but you may break old admin scripts, Docker images, or CI jobs that still expect Node 16 or npm login behavior from older CLIs.
Cautions
Do not treat the upgrade as only a server package bump. If your automation uses `npm login` on npm 9+ without `--auth-type=legacy`, or if you still publish to npmjs.org with pre-2025 classic tokens, those workflows can still fail after the Verdaccio upgrade.
Stay on Verdaccio 5.31.x temporarily and harden token compatibility first
As of 2026-03-27, Verdaccio's configuration docs state that Verdaccio 5.x on Node.js 22 or higher will fail to start if the `.verdaccio-db` secret is still 64 characters long. The same docs say `security.api.migrateToSecureLegacySignature` is available since v5.31.0 to rotate that secret to 32 characters automatically, but rotating it invalidates previously generated tokens. Verdaccio also documents that JWT is optional and that legacy API token signing remains enabled by default, so a hardened 5.31.x deployment can be used as a short bridge while you update CI and registry auth flows. This option minimizes change if your actual blocker is old automation rather than missing 6.x features.
When to choose
Use this when older CI images, scripts, or plugins still depend on pre-Node-18 assumptions and you need a controlled migration window. It is the safer choice if the main operational risk is token invalidation or auth-flow breakage rather than staying on the previous major version for a bit longer.
Tradeoffs
This avoids a rushed major upgrade and gives you time to rotate secrets deliberately, but it prolongs reliance on legacy token behavior and keeps a second migration still ahead of you.
Cautions
Secret migration is not transparent: Verdaccio docs explicitly warn that updating the secret invalidates previously generated tokens. Also, if your pipelines still use npm classic tokens for npmjs.org publishing, that cutoff already happened on November 19, 2025, so holding on Verdaccio 5 does not preserve those external workflows.
Try with your AI agent
$ npm install -g pocketlantern $ pocketlantern init # Restart Claude Code, Cursor, or your MCP client, then ask: # "Should I upgrade to Verdaccio 6 now?"