How a private npm registry works
An npm registry answers package metadata and tarball requests. Publishing sends a package version to the registry; installing asks the registry for a matching version and downloads its tarball. A private registry adds authentication and authorization to those requests, so a package name alone is not enough to retrieve its contents.
Your package manager still runs the familiar commands: npm publish and npm install. The key changes are the registry URL and the credentials attached to that URL. A scoped package such as @acme/sdk can resolve from a private host while public dependencies continue to resolve from the public npm registry.
Separate publishing from installing
Publishers need permission to create versions. Consumers only need to read metadata and tarballs. Use separate credentials for those jobs. A CI publisher key should have the smallest registry and package scope needed for its release. A customer's download key should be read-only and limited to the packages that customer may install.
With PrivateNPM.com, publishers can reserve a scope on the shared registry or create a separate private registry on a verified domain. A download key belongs to one registry and can cover selected packages, one owned scope, or all your packages in that registry. Keys can be rotated or revoked without changing the package name. See the full feature list.
A basic rollout
- Choose a package scope and registry URL. Decide whether a shared scope or a separate registry namespace fits your names.
- Create a publisher key for a person or CI pipeline and publish the first version.
- Create read-only credentials for each team, integration, or customer that needs to install it.
- Put the scope's registry URL and token environment variable in the consumer's
.npmrc. - Verify an install in a clean environment, then document how to rotate and revoke access.
For the exact configuration, follow the .npmrc guide. If you are deciding where the service should run, read the self-hosting checklist.