Skip to content

429: Maven Central index download limits⚓︎

Question⚓︎

I am receiving a 429 Too Many Requests response when trying to download the Maven Central index files from /maven2/.index/.

What are these limits, and how do I fix this?

What is the Maven Central index?⚓︎

Maven Central publishes a Lucene-format index that lists all available artifacts. This index is used by:

  • IDEs (NetBeans, IntelliJ IDEA, Eclipse with m2e) for offline search and dependency auto-complete
  • Offline build tools that need to resolve coordinates without making individual metadata requests
  • Third-party tools that build local artifact databases or search indexes

The full index (nexus-maven-repository-index.gz) is a large file — typically 400–600 MB compressed. Incremental update chunks are also published to the same directory.

The index is updated on a roughly two-week cycle. It does not reflect real-time additions; newly published artifacts appear in the index after the next scheduled rebuild.

What are the limits?⚓︎

Maven Central enforces per-IP download limits on index files. The full index is large enough that repeated downloads from a single IP add up quickly, especially when multiple developers or machines share the same egress IP or when a tool is configured to refresh the index on every startup or build.

How to fix this⚓︎

For individual developers⚓︎

Cache the index file and do not configure your IDE or tool to refresh it on every startup or build invocation.

  • In IntelliJ IDEA: the Maven index is automatically cached and only refreshed when you explicitly update it. If you have automated index updates turned on, turn them off.
  • In NetBeans and Eclipse m2e: check your Maven settings for automatic index update intervals and increase them or disable automatic updates.
  • The index only updates every ~2 weeks, so refreshing it more frequently than that wastes bandwidth and provides no benefit.

For teams behind shared egress⚓︎

If multiple developers or build machines share the same egress IP, each individual's index download counts against the same per-IP limit.

Use a repository manager such as Sonatype Nexus Repository or similar that:

  1. Downloads the index once from Maven Central
  2. Caches it internally
  3. Serves it to all developers and build machines from the internal cache

With this setup, Maven Central sees only one or two index fetches per refresh cycle from your entire organization, rather than one per developer or machine.

For tools that bundle index download⚓︎

If you maintain a tool that downloads the Maven Central index as part of its operation:

  • Use incremental update chunks, not full re-downloads. The /maven2/.index/ directory publishes incremental update chunks (nexus-maven-repository-index.NNN.gz) alongside the full index. After the initial full index download, fetch only the incremental chunks that post-date your last sync. This is far more bandwidth-efficient and avoids re-downloading hundreds of megabytes when only a fraction of the index has changed.
  • Keep track of the highest chunk number you have applied locally. On each sync, fetch only chunks with higher numbers.
  • Only fall back to a full index download when your local index is too far out of date to be updated incrementally (i.e., the earliest available chunk is newer than your last applied chunk).

What about incremental update chunks?⚓︎

The /maven2/.index/ directory also contains incremental update chunks (nexus-maven-repository-index.NNN.gz). These are smaller files but are covered by the same directory-level limit.

If you are fetching incremental chunks frequently:

  • Check whether the chunks you are requesting still exist. Old incremental chunks beyond a certain age are no longer served (a 404 response indicates the chunk is no longer available).
  • Fetch the full index if your local index is too far out of date to be updated incrementally.
  • Cache chunks locally the same way you cache the full index.

Still need help?⚓︎

If you continue to see rate limit responses after addressing your caching behavior, see 429: Contact support for what to gather and how to reach us.