Private registry

What it means

A private registry is a package store that your organisation controls. It holds the libraries you write for internal use, and it can also act as a gateway to public ones such as npm, PyPI or Maven Central. Builds fetch packages from it rather than straight from the internet. Teams use products such as Artifactory, Nexus or a cloud provider's own package service for this.

It gives you one place to decide what may be installed. Internal names stay internal, public packages can be cached after review, and you can see and revoke who has access. That control is the whole value of the idea.

Why it matters

Without one, a build that asks a public index for a package name may get a surprise. If your internal package name is not taken on the public index, an outsider can publish one with that name. This is dependency confusion, and the build may pick the outsider's version. Fixing a mix-up like that after the fact is hard, because the harmful code has already run.

A registry also gives you a record of what went into a build, and a place to block a bad package for everyone at once. It supports supply chain security by shrinking the places a package can come from. It also lets you remove a package that proves harmful, in one place.

How it shows up

Configure each tool so internal names resolve only from the private registry. In npm, scopes such as @yourcompany/ can be pointed at a specific registry. In other ecosystems, use a single virtual repository, or exclude internal names from public sources.

Common mistakes are leaving the public index as a fallback for internal names, using one shared token for everyone, and never pruning old versions. Reserve your internal names on public indexes where you can, and review who can publish. See dependency confusion for the attack in full.