Skip to content

I already have a repository manager⚓︎

If you already have a repository manager and are still seeing 429 Too Many Requests responses, the repository manager itself is usually not the source of the problem.

In the cases we see most often, the issue is "shadow downloads": traffic from builds, tools, scanners, containers, or automated CI jobs that are not actually using the repository manager. Those requests still go directly to Maven Central, often from the same corporate NAT, cloud NAT gateway, VPN, CI provider, or shared egress point as the rest of your organization.

From Maven Central's perspective, rate limits apply to the traffic seen from that source. If direct downloads and repository-manager traffic share the same outbound IP or egress path, then excessive direct traffic can affect everything behind that path, including teams and builds that are correctly using the repository manager.

We try to limit the impact on repository managers wherever possible, because repository managers are part of the solution. But when uncached direct traffic and repository-manager traffic share the same egress path, it is not always possible to separate them reliably at the edge.

The goal is to find and corral that shadow traffic so it flows through the repository manager you already have.

Look beyond the build⚓︎

Do not limit the investigation to Maven, Gradle, SBT, Bazel, or other build tools. Anything in your environment that tries to analyze, resolve, inspect, enrich, scan, or understand Java components may be generating Maven Central traffic.

We sometimes see third-party SCA tools, SBOM generators, container scanners, dependency analysis tools, or vendor platforms repeatedly downloading the same dependency trees thousands or tens of thousands of times per day. That traffic may not appear in normal build logs, and it may not flow through your repository manager unless those tools have been explicitly configured to use it.

Another frequent pattern is cluster provisioning for data analysis. Some data, analytics, and compute clusters download large Java dependency sets, such as Apache Spark or Hadoop, each time new clusters or nodes are provisioned. Because this activity can happen repeatedly and automatically, it can escalate quickly and generate significant Maven Central traffic before anyone thinks to look beyond the application build.

In one real investigation, we found a fleet of these data clusters repeatedly downloading the same set of roughly 1,000 Java dependencies about 80 million times per week. This is one example of many patterns we see — the root cause in your environment may look quite different — but it illustrates how traffic that has nothing to do with application builds can dominate what Maven Central sees from your network.

What to look for⚓︎

Start by assuming that some meaningful portion of your dependency traffic is bypassing the repository manager.

Common sources include:

  • CI jobs with default Maven, Gradle, SBT, Bazel, or other package manager settings
  • Container builds that fetch dependencies during image creation
  • Third-party SCA, SBOM, dependency analysis, or container scanning tools
  • Security scanners or vendor tools that resolve artifacts independently
  • Developer machines using default public registry configuration
  • Temporary build agents or ephemeral runners that do not inherit standard settings
  • Legacy projects with checked-in build configuration pointing directly to Maven Central
  • Automation scripts, plugins, or vendor tools that fetch artifacts outside the normal build path

How to investigate⚓︎

Compare what your repository manager is designed to do with the traffic Maven Central is seeing from your network.

Repository managers cache artifacts by design. Once an artifact has been downloaded, later requests should normally be served from the repository manager cache rather than downloaded again from Maven Central. Even a new or empty repository manager should only need to fetch each artifact once, and normal metadata refresh behavior should not generate the repeated, high-volume download patterns that trigger these limits.

That is why the most useful investigation usually starts outside the repository manager. Look for systems, tools, scanners, CI jobs, containers, data clusters, or automation that are reaching Maven Central directly instead of using the repository manager. The traffic that matters is often the traffic that never reached the repository manager in the first place.

Network operators should look for direct traffic to Maven Central's canonical repository endpoints:

  • repo1.maven.org
  • repo.maven.apache.org

These endpoints resolve to the same Maven Central repository service. repo.maven.apache.org is a CNAME for repo1.maven.org, so traffic to either name should be treated as direct Maven Central access.

Useful checks include:

  • Review outbound traffic from the affected NAT gateway, proxy, firewall, or CI environment.
  • Search DNS, proxy, firewall, and egress logs for requests to repo1.maven.org and repo.maven.apache.org.
  • Compare CI job configuration against your expected repository manager settings.
  • Check whether build agents are provisioned with the correct settings.xml, init.gradle, mirror configuration, or equivalent package manager settings.
  • Inspect container builds, scanner configurations, data cluster provisioning, and other automation separately from normal application builds.
  • Ask third-party vendors whether their tools can be configured to use your repository manager or internal proxy.

What to change⚓︎

Once you find direct traffic, route it through the repository manager consistently.

The most effective fixes are usually configuration and enforcement changes:

  • Provide standard build images or templates with repository manager settings already configured.
  • Configure Maven mirrors, Gradle repositories, and other package manager settings centrally.
  • Remove direct Maven Central URLs from project templates and legacy build files.
  • Ensure ephemeral CI runners receive the same repository configuration as long-lived build agents.
  • Configure scanners, SBOM generators, SCA tools, and supply chain tools to use the repository manager where supported.
  • Use network policy, proxy rules, or firewall controls to prevent accidental direct access from managed environments.

What this usually is not⚓︎

In the investigations we have done so far, we have not seen a case where the root cause was the repository manager itself.

Every time, the problem has been traffic that bypassed the repository manager: a build job, scanner, container process, data cluster, vendor tool, developer machine, or other automated system reaching Maven Central directly.

That matters because tuning the repository manager will not fix traffic that never goes through it. Before assuming the repository manager is misbehaving, first identify whether all significant consumers of Java components in your environment are actually configured to use it.

Still need help?⚓︎

If you have investigated shadow traffic, made configuration changes, and are still seeing 429 responses, see 429: Contact support for what to gather and how to reach us.