Skip to content

429: Operational and runtime artifacts⚓︎

Build dependencies vs. operational dependencies⚓︎

Maven Central is designed for build-time dependencies — the JARs, POMs, and other artifacts that a build tool resolves once, caches in a repository manager, and reuses across many builds. The typical pattern is: resolve the dependency, cache it, and never fetch it again for the same version.

Some artifacts published to Maven Central are used differently. Instead of being a build dependency, they are fetched repeatedly at runtime, during deployment, or during infrastructure provisioning — often as large binary archives that are unpacked and run as processes. Examples include server distributions, runtime tarballs, and application packages published to Maven Central for convenience but intended to be fetched on every deployment.

This pattern is called an operational dependency: the artifact is not a build input, it is a piece of running infrastructure that needs to be fetched repeatedly, often by many machines.

Why Maven Central limits this pattern⚓︎

Maven Central is infrastructure maintained on donated and internally funded resources. It exists to serve the open source development ecosystem — not to act as a general-purpose CDN, content delivery platform, or large-binary hosting service.

When an artifact is used as an operational dependency rather than a build dependency, the resulting traffic looks very different from ordinary development use:

  • The same large file is fetched hundreds or thousands of times across a fleet
  • Requests come from deployment pipelines, orchestration systems, and server startup scripts rather than build tools
  • Nothing is cached between fetches, because the machines doing the fetching are ephemeral or the cache is never configured
  • A single artifact can account for terabytes of bandwidth per month

This puts Maven Central in the position of absorbing infrastructure costs that belong to the artifact's publishers and consumers, not to the open source commons.

For that reason, Maven Central enforces per-IP and global download limits on artifacts that are consistently used this way.

If you are a consumer⚓︎

If you are hitting a 429 on a large operational artifact, the right fix depends on how you are fetching it:

Use the project's official distribution channel. Most projects that publish large operational artifacts also host them on a proper distribution platform — GitHub Releases, their own CDN, a hosted download page, or a package repository suited for runtime artifacts. Check the project's documentation or release page and fetch from there instead.

Cache the artifact in your own infrastructure. If you must fetch from Maven Central, cache the artifact in a repository manager, artifact store, or object storage bucket and have your deployment systems pull from there. Do not fetch from Maven Central on every deployment, every boot, or every pipeline run.

Treat it like any other large binary release. The same practices that apply to OS images, container images, and release tarballs apply here. Fetch once, store centrally, distribute internally.

If you are a publisher⚓︎

If your artifact is being used operationally — as a server distribution, runtime package, or large binary that consumers fetch at deploy time — consider:

Host it on a platform designed for content delivery. GitHub Releases, a project CDN, or a cloud storage bucket with a public URL are better choices for operational artifacts than Maven Central alone. Publishing to Maven Central as a coordinate for dependency discovery is fine; using Maven Central as the primary download source for runtime consumption is not.

Provide clear guidance to your users. If your documentation or getting-started guide instructs users to curl or wget a Maven Central URL as part of a setup script, deployment script, or provisioning template, update it to point to your official distribution channel instead.

Artifact redirects⚓︎

For some very high-volume operational artifacts, Maven Central redirects download requests directly to the project's authoritative hosting rather than serving the file from Maven Central infrastructure.

This is not a rate limit — it is a permanent 301 Moved Permanently redirect to a URL controlled by the artifact's project. The redirect is coordinated with the project ahead of time.

Known redirected artifacts⚓︎

Maven coordinate Redirected to
io.trino:trino-server:*:tar.gz GitHub Releases — github.com/trinodb/trino/releases/
com.facebook.react:react-native-artifacts:*:tar.gz React Native proxy cache — repo.reactnative.dev
com.facebook.react:react-android:*:aar React Native proxy cache — repo.reactnative.dev
com.facebook.hermes:hermes-android:*:aar React Native proxy cache — repo.reactnative.dev
com.facebook.hermes:hermes-ios:*:tar.gz React Native proxy cache — repo.reactnative.dev

Build tool behavior⚓︎

Most build tools and curl/wget follow 301 redirects automatically. If your tooling breaks on a redirect, check whether redirect-following is enabled:

# curl: follows redirects by default with -L
curl -L https://repo1.maven.org/maven2/...

# wget: follows redirects by default
wget https://repo1.maven.org/maven2/...

Some Maven plugins and Gradle resolvers may not follow redirects when downloading artifacts outside the normal dependency resolution flow. If you are fetching an artifact through a custom plugin, script, or integration, verify that it handles 301 responses.

If your artifact is being redirected⚓︎

If you are a publisher and your artifact is subject to a redirect, or if you believe a redirect should be set up for your artifact, contact Central Support so we can coordinate.

Still need help?⚓︎

If you are seeing 429 responses and the guidance above does not resolve it, see 429: Contact support for what to gather before reaching out.