Best Practices: Proxy Repositories

Repository Manager | Reading time: 5 minutes

Is this article helpful?

In this guide:


As part of a Nexus Repository Manager (NXRM) Health check workshop, we review the NXRM configuration and provide detailed recommendations on how to better optimize your repository instance. There are a number of recommendations regarding proxy repositories that are fairly universal to any production instance. We will go through the most common ones here.

What is a proxy?

As a quick review, access to proxy repositories is a primary use-case when using a universal artifact repository like NXRM. They allow systems to automatically fetch artifacts from an array of remote repository formats and cache the artifacts locally. They reduce network traffic and build times when artifacts are requested again. They provide reliability to builds for when public repositories go down or remove required artifacts.

Routing Rules

Routing rules are incredibly useful tools that are often overlooked. Administrators can use routing rules to limit requests to external repositories to only the artifacts that are needed from that proxy. Routing rules can help with dependency confusion like attacks against an organization’s internal namespace. Routing rules will speed up access times for group repositories by limiting requests to only the proxies where the components should be fetched.


  • Use routing rules on all proxy repositories.
  • For public repositories, BLOCK access to internal namespaces to prevent dependency confusion attacks.
  • For other repositories, only ALLOW access to the namespaces that are required from that repository.
  • Learn more: intro routing, nexus groups, namespace confusion, help documentation

Replicate your Proxies

Geo-diverse teams often create proxies from a centralized artifact server to replicate artifacts to their own local NXRM instances. One issue is how long it takes to download those proxied artifacts during the build. Without a prefetch method, there can be a significant delay in accessing remote artifacts which can sometimes cause the build to fail. In these cases, it may be better to use the Repository Replication feature to push artifacts from the central server directly to remote hosted repositories instead of using proxies. When that is not possible, the following configurations to proxies should be taken into consideration.


  • Avoid using large group repositories where many remote proxies are configured. Keep group repositories to only the proxies that are needed for the build.
  • Take care when proxying remote group repositories to avoid circle references between proxies. This happens when a proxy is made against a remote group repository which may also include a proxy to the source repository.
  • Repository webhooks are used to trigger prefetch scripts to pull the artifacts through the remote proxy though they are not nearly as reliable as the built in replication capability. We would suggest using a queuing method to capture the requests and managing the download externally.

Validate your Proxies

During the healthcheck audit, it is common that organizations don’t know why some proxies are configured or who uses them. Every active proxy in a group repository will add to the time it takes to resolve dependencies. For this reason, the best practice is to regularly review proxies if they are still needed and take offline the proxies that are not actively being used. Administrators should document which projects or teams are using the proxy and any components they require. A best practice would include a software bill of materials which tracks the artifacts used in their built artifact.


  • Consider special groups repositories for teams that need their own proxies to avoid affecting the performance of everyone else.
  • Remote proxies should use HTTPS to protect against man-in-the-middle attacks.
  • Audit that proxy URLs are valid and their remote authentication is correct.
  • If a proxy will be permanently offline, consider exporting and reimporting it as a 3rd-party hosted repository.
  • Avoid duplicate proxies to the same source as they should be reused with group repositories.
  • In group repositories the order of repositories matters. Keep the hosted repositories first while the proxies to follow. Searching hosted repositories is far quicker and helps avoid looking in external proxies for internal artifacts.
  • Review proxy caching intervals to improve response times, kb article

Cleanup your Proxies

A common request is to remove all vulnerable components from proxies to make a golden repository of open-source that developers can use. This ideal is unrealistic because issues will eventually be found for any given open source project and components should not be removed from proxies while they are in active use in builds. Developers need timely access to new components with early feedback as to the risks in using them.

The most effective approach to this desired outcome is to set cleanup policies on proxies by the last downloaded date. Using Nexus Lifecycle, developers can identify vulnerabilities in their applications and stop using open-source software with known risk. These will no longer be used and downloaded so they will eventually be cleaned from the repository. Adding Nexus Firewall will help keep new components with known risk from automatically being downloaded into the proxy. This way development teams know immediately if a new project is not in compliance with AppSecs requirements.


  • Use Nexus Lifecycle to discontinue the use of components with known risk.
  • Use Nexus Firewall to limit components with known issues from being automatically adopted.
  • Use cleanup policies by the last downloaded date to remove unused components.

Talk to Us

Have more questions or comments? Learn more at, join us in the Sonatype Community, and view our course catalog at

And visit for all things Sonatype.