What happened

v0, Vercel’s AI app builder, can now install packages from private npm registries and custom registries while it generates your app. npm is the standard catalog most JavaScript and TypeScript projects pull reusable code from; a private registry is the same idea, restricted to packages your company hasn’t published publicly, like an internal design system or component library. Vercel’s changelog entry says the credentials come from “shared environment variables,” settings you save once in your Vercel project and that your code can read automatically, instead of typing a password or key into each v0 session by hand.

There are two ways to set it up. NPM_TOKEN covers private packages hosted on npm’s own registry, npmjs.org. NPM_RC is for anything more custom, like an organization’s own package scope on GitHub Packages, or a private registry run through a service like JFrog Artifactory. Both get added as shared environment variables in your Vercel project, scoped to Development and/or Preview, the pre-launch environments Vercel uses for work in progress and shareable test links, as opposed to Production, the live environment your real users hit. Vercel says credentials can be marked “sensitive,” and that v0 never exposes them to the underlying model or writes them to the sandbox filesystem it generates code in.

Why it matters

Before this, if your app depended on an internal component library or a private design system package, v0 couldn’t install it. You’d have to build around public packages only, then wire the private ones in yourself later. That gap is real friction for teams that already standardized on shared internal tooling before adopting v0.

The setup also introduces a real credential to protect, so it’s worth being deliberate about it. A Vercel shared environment variable is visible, in plain text, to anyone with access to that scope in your project’s dashboard, unless you mark it sensitive. Sensitive marks a variable so its value is hidden in the dashboard after you save it. If you skip that step, any teammate who can view your Development or Preview environment settings can read your npm token directly, not just use it. That’s a bigger exposure than most people intend when they’re just trying to get a build working.

The scoping options Vercel lists are Development and Preview, not Production. If your workflow expects this credential to also be available when your app actually deploys to production, check that assumption before you rely on it. The changelog doesn’t mention a production option, so don’t assume one exists.

Who should care

Anyone building with v0 on a codebase that depends on private or internal packages, and anyone on a team where more than one person has access to the Vercel project’s environment variable settings.

What builders should do next

When you add NPM_TOKEN or NPM_RC, check the “sensitive” box in the same step, before you save. Don’t add it first and go back later. Then confirm it’s working from inside v0 itself: go to Settings → Integrations, where Vercel says you can view the integration’s status.

If your npm registry lets you issue a token scoped to read-only access on just the packages v0 needs, use that instead of a token with full publish or account-wide access. Vercel’s changelog doesn’t require a scoped token, but the practical risk of a leaked token you can only read with, and only for the packages you actually need, is much smaller than one that can also publish.

The bottom line

This closes a real gap for teams building on private tooling, but it does that by asking you to store a credential somewhere new. Marking it sensitive and checking the scope you granted it takes less than a minute. Skipping that step doesn’t just risk a broken build. It risks a token sitting in plain view of everyone who can see your project’s settings.

End of article