Example - Multiple registries linked with upstreams

For certain organizations it may not be ideal to have a setup where a developer-facing Bytesafe registry is directly connected to the public registry or any other external registry. In these cases, adding one or more layers of registries between developer teams and the external registries may be beneficial.

One example of this may be organizations with specific security or license compliance requirements where you want to stay in complete control of what external packages are integrated into different projects across different teams.

Typically an organization needs to balance corporate security and requirements while allowing the development teams to be productive. In these scenarios teams may still want a dedicated registry for their development/testing while being able to share private package versions with other teams. The teams should also be able to pull new packages or package versions into their registry and generally internally be able to work with their registry and dependencies without the organizations security requirements being too much of a restriction.

By adding layers of registries as upstreams this can be achieved with Bytesafe!

Benefits of configuring a chain of registries:

• Added security, inserting a central point to control the flow of package versions (and enforce policies)
• Ensure the whole organization is working with the same package versions (private and public)
• Each layer only knows and interacts with the registries directly connected to it - simplifying users interactions with registries
• Centralize releases to the public registry
• Individual policies can be applied for each layer - freeze dependencies, block packages etc.

Example: Chains of registries, each with its own upstream

flowchart TD
  A(fab:fa-npm registry.npmjs.org) ---- | public registry upstream for the shared registry | B>Shared/Release registry];
 B ---- C(Development registry - Project 1 );
 B ---- D(Development registry - Project 2);
 B ---- E(Test / QA registry);   
  C <--> | install / publish | F[fa:fa-user Dev Team 1];
  D <--> | install / publish | G[fa:fa-user Dev Team 2];
  E <--> | install / publish | H[fa:fa-user Test / QA];

How it works - pull & push of packages when using chains of registries

In this case the private registries are only configured with the layers above it as upstreams. So what happens when a developer want to install a new package version, that is not available in the developers registry or its directly connected upstream?

Pulling packages using Bytesafe is a recursive action. The pull request action will be passed from registry to upstream registries until the package is found (or else it fails).

Although the developer’s registry is only configured with another private registry as a upstream, they are able to continue working using third party packages.

If the same developer wants to push a new package version, the developer only has to push the package to the layer above, where it can be distributed to other members. No need to share or keep track of credentials for the public registry or who has the right to publish a new package version. That responsibility is handled by the layer above. This gives much better control over what is published.

Configuring chains of registries

Setup of chains of registries in Bytesafe is simple:

1. Create required registries
2. Add a desired destination / source registry as upstream - for each registry
3. Optional - configure plugins and policies for each registry

The requirements of a user’s organization determines the amount of layers needed.

Adding plugins and policies

Using multiple registries linked with upstreams to structure the flow of packages between teams and the outside is especially powerful in combination with plugins and policies.

Examples include:

• Freeze policy - Freeze dependencies for a registry to ensure package version are the same for all users and for archiving dependencies
• Forward plugin - Auto forward packages published to a registry to its upstreams
• Block downstream policy - Reject push of packages into a registry - useful for registries that connect to external registries and you want to ensure your private packages (from other registries) are not made available in this registry

For more information and examples, read the section of the documentation on Plugins and Policies