v0 Can Now Reuse Your Private Component Library

v0 can now use the private component library your team already paid to build, so a prototype can start with the real components instead of copies that engineers replace later. Vercel shipped the credential path at 17:00 UTC on September 18, 2026: give v0 an NPM_TOKEN or NPM_RC through a shared Development or Preview environment variable, and it can install the package without exposing the credential to the model or writing it to the sandbox filesystem.

The change is small. The handoff is not.

A private npm package is just JavaScript or TypeScript distributed through a registry that checks who is allowed to download it. Teams use private packages for design-system components, tokens, authentication helpers, analytics wrappers, and internal utilities.

Until this release, that registry check was a hard break in the v0 workflow. A public package could install normally. A private component library needed a workaround such as uploading an archive, or the prototype used new components that looked close enough for review. The second path felt fast during the demo and created a replacement job when the code reached the real repository.

The new v0 path moves authentication to the edge of the sandbox. v0 runs the repository's existing package manager in Vercel Sandbox. When the install request leaves for the private registry, Vercel applies the credential at the network boundary. The model and agent cannot read the value, and the value is not written into a local .npmrc file.

That distinction matters. The package enters the build. The secret does not enter the prompt or filesystem.

Package access still does not teach v0 how your system should be used. It can fetch a Button component and still choose the wrong variant, omit a provider, or miss a theme wrapper. That is why the package should travel with current docs, examples, and a real consumer app. The wider operating pattern in How to Give Coding Agents a Design System still applies: code carries repeatable mechanics, while guidance carries judgment.

The budget line is component replacement

The business consequence is not a faster package install. It is the chance to remove a separate rebuild between prototype approval and production work.

When v0 invents a lookalike component, the prototype and the product have different identities. Engineering has to replace imports, remap props, restore theme context, retest states, and explain why the approved screen changed. When v0 starts with the real package, the handoff can become review and refinement instead of reconstruction.

Here is a worked assumption, not a Vercel benchmark. Say one prototype used to need a 4-hour component-replacement pass. The team values engineering time at $100 per hour. If credential setup and validation take 1 hour, the modeled time avoided is 3 hours, or $300.

That saving is not guaranteed. A broken package setup, missing provider, or weak usage guidance can consume the same 3 hours somewhere else. Measure the repository diff and correction time on your own component, then keep or reject the workflow from that result.

Teams using only public packages are not affected. Neither are teams making disposable concept screens that will never enter a repository. The change matters most when an approved v0 prototype is expected to become maintained software.

Choose the credential by where the package lives

The simple rule is NPM_TOKEN for private packages on registry.npmjs.org and NPM_RC for routing. Do not add both as a fallback. The private-dependencies documentation says NPM_RC wins when both exist, which can make a stale custom configuration hide a valid npm token.

Set it up with the smallest useful permission

1. 1

   Choose one real package

   Start with a component already used in the production repository. That gives you a known import, a known visual result, and a real handoff to inspect. A demo-only package proves that authentication works, but not that the workflow removes rework.

2. 2

   Create the shared variable

   In Vercel, select the team, open Settings, then Environment Variables. Add NPM_TOKEN or NPM_RC as a shared variable and scope it to Development, Preview, or both. Mark it sensitive.

   The v0 docs require a Vercel Developer role or higher to manage this setting. The token itself should have read access to every private package the project installs, and nothing broader than the registry requires.

3. 3

   Route a custom registry

   For GitHub Packages, Vercel documents this NPM_RC value for the sample @acme scope:

   @acme:registry=https://npm.pkg.github.com/
   //npm.pkg.github.com/:_authToken=${GITHUB_PACKAGES_TOKEN}

   Store GITHUB_PACKAGES_TOKEN as another shared variable. NPM_RC can expand ${VAR} references during installation and gives the referenced value the same credential protection. Use the equivalent registry URL and token variable for JFrog Artifactory.

4. 4

   Check the v0 integration

   Open Settings, then Integrations in v0 and find npm. v0 links supported shared variables automatically. Ask it to install and render the one component you chose, then confirm that the preview uses the expected styles, provider, and behavior.

5. 5

   Inspect the repository handoff

   Send the result to the real repository. Review package.json, the lockfile, the import path, provider setup, global styles, and the source diff. Run the repository's existing checks. A working preview is useful evidence, but the handoff is complete only when the branch still uses the approved component cleanly.

Four teams that can use this tomorrow

A SaaS product team building a dashboard

The product designer can prototype a new billing flow with the same private components the frontend team already ships. The payoff is not prettier generation. It is an approval conversation around the actual Button, Table, and Modal behavior, followed by a smaller source diff.

A design-system lead preparing v0 for the company

The lead can add the private package before a Design Systems 2.0 import, then give v0 the source repository, one real consumer app, and current usage docs. v0 builds a starter and pauses for review before saving the system. The lead can catch fonts, providers, tokens, and deprecated component patterns once, before every later chat inherits them.

An agency platform lead managing several registries

The agency can use NPM_RC to route organization scopes to the right registry instead of copying a token into each prototype. The payoff is a controlled credential setup and fewer client-specific lookalikes. The agency still needs separate access boundaries and a review process for each client's package.

An enterprise frontend team on GitHub Packages or JFrog

The platform team can let v0 install the same internal dependencies as the imported repository. The payoff is a more honest preview: package resolution, theme setup, and imports fail during the prototype instead of after handoff. If policy blocks shared credentials, the documented .tgz route remains the smaller pilot.

Access and price are two separate bills

The private-package docs do not name a paid v0 tier or a separate add-on for this feature. They name a permission gate: the person managing the shared variable needs a Vercel Developer role or higher. Vercel's role documentation places the team-level Developer role on Pro and Enterprise plans.

That is separate from the current v0 plans. Free is $0 per month with $5 in monthly credits and a 7-message-per-day limit. Plus is $30 per user per month with $30 in monthly credits per user and $2 in daily login credits per user. Business is $100 per user per month with the same listed credit amounts and training opt-out by default. Enterprise is custom. A legacy Premium plan remains $20 per month in the docs, but it is being sunset and is not available to new users.

Vercel Pro has a $20 monthly platform fee, one deploying seat, and $20 in monthly usage credit. Additional Owner or Member seats are $20 per month each. All of these published prices are in US dollars before tax.

For a worked stack, one v0 Plus seat and the Vercel Pro platform fee add to $50 per month before tax and usage. That is not a minimum price for this feature. The release documentation does not say both paid plans are required, so check your existing account and role before upgrading anything.

The honest limits

Private package access removes one wall. It does not turn a component library into a complete design system, make generated code production-ready, or keep an existing project updated when the package changes.

There are practical boundaries:

• Shared Environment Variables do not support branch-specific values.
• NPM_RC overrides NPM_TOKEN when both are present.
• A token must cover every private package the project installs, including private dependencies pulled by the package you chose.
• The credential can be protected while the generated implementation is still wrong.
• Providers, global CSS, fonts, tokens, component states, tests, accessibility, and review still belong in the handoff.

The security promise is narrow and useful: v0 does not expose the credential to the model or agent, and it does not write the credential to the sandbox filesystem. Your company still decides whether a registry token may be used in this workflow, how narrowly it is scoped, and how it is rotated.

The Monday move

Act this week if your team already has a private component package and v0 prototypes regularly become repository work. Wait if the security owner has not approved a read-only registry credential. Use the .tgz path for a contained pilot if credentials cannot be shared. Ignore the release if you use only public packages or your v0 work stops at disposable concepts.

On Monday, import one real private component. Put the smallest read-only credential in Development, confirm the npm integration, make v0 render the component, and hand the result to the repository. Check the dependency, lockfile, import, provider, visual state, and source diff. If that one component survives the handoff without a lookalike replacement, the workflow has changed. Then measure the hours before you expand it.

For the next practical platform change and the business math behind it, join the newsletter.