Chocolatey Software Blog | I Got 429 Problems, but a Cache Ain't One

Chocolatey Software

5 min read Original article ↗

Upcoming Terms of Use Changes

From January 1, 2027, Chocolatey Software’s updated Terms of Use will prohibit using the Chocolatey Community Repository directly to manage organizational computers.

If your organization currently uses the Chocolatey Community Repository directly, please ensure your usage is compliant and read Clarifying Organizational Use of the Chocolatey Community Repository for the full details and permitted exceptions.

From IT admins setting up a fresh batch of laptops to home lab enthusiasts spinning up multiple VMs at once, we all rely on scripts to do the heavy lifting. But sometimes, that automation hits an invisible wall. You kick off your scripts, everything looks great, and then suddenly it stops.

You may start seeing red: 429 Too Many Requests.

If you are using the Chocolatey Community Repository, then this is a sign that the system is applying the brakes. We implement these rate limits as a necessary measure to increase site stability and prevent excessive use. While the immediate result is a temporary block lasting for one hour, the long-term solution isn’t just to wait it out. It is to adopt a more sustainable infrastructure strategy.

Let’s dive into what these limits are, why they exist, and the architectural changes you can make to ensure you never see a 429 error again.

The Speed Limit

First, let’s look at the actual numbers. The rate limits on the Chocolatey Community Repository aren’t a secret, they’re actually listed out on our docs site. At the time of writing, they are:

  • Downloads of Chocolatey CLI itself (i.e. chocolatey.nupkg) are limited to 5 per minute per IP address.
  • Downloads of any other packages are limited to 20 per minute per IP address.

If you exceed these thresholds, your IP address triggers a rate limit. This is a temporary block that lasts for one hour. It is also important to note that there is no cooling off period; if you trigger it again, the timer will be set for another hour.

Why Do We Have Limits?

The Chocolatey Community Repository is a massive, free resource used by millions of people globally (we did recently observe the four billionth download!). To ensure the service remains available for everyone, we have to prevent any single user or organization from consuming excessive resources.

It is helpful to distinguish between Rate Limiting and Excessive Use. Rate limiting is a temporary block that is the system protecting itself from a burst of traffic. Excessive Use is different; that is where an IP address might be permanently blocked if it is consistently degrading the service for others.

The “Commercial License” Misconception

We often see tickets from users who have either triggered a rate limit or excessive usage block asking if the purchase of Chocolatey for Business licenses will increase or remove these limits.

To be clear: Purchasing a license does not bypass the rate limits on the Chocolatey Community Repository.

The Chocolatey Community Repository is a public resource, and the rules apply to everyone equally, regardless of license status. A Chocolatey for Business license gives you powerful tools to manage your own infrastructure, but it does not buy you a “fast lane” on the public feed.

A First Step to Avoiding the Limits: Internal Repositories

While it may be enough to simply set up one computer at a time, the real solution is to stop using the Chocolatey Community Repository as your direct source.

When using Chocolatey products in an organizational (or home lab!) context, we recommend that you don’t use the Chocolatey Community Repository directly. Instead, you should implement a caching mechanism that you can then configure as the source from which you’re downloading packages.

Tools like Sonatype Nexus Repository or Inedo ProGet allow you to set up a remote/proxy repository. Here is how it works:

  • You point your Chocolatey CLI clients to your internal Nexus/ProGet URL

    choco source add -n=example -s="https://example.internal/example-choco-proxy/api/v2/"

  • You disable the default Chocolatey Community Repository source

    choco source disable -n=chocolatey

  • When you request a package version (like git version 1.2.3), your internal server checks if it has it.

  • If not, your server reaches out to the Chocolatey Community Repository once, downloads it, and caches it.

  • All subsequent requests for git version 1.2.3 come directly from your internal server.

This provides the same experience you get in using the Chocolatey Community Repository now but with more resilience against potential outages and no rate limiting!

You can configure your internal repository for how long a given “answer” from the Chocolatey Community Repository is “remembered”. This impacts how long it may take for a new version of a given package to become available via your internal server.

You should review the documentation for your chosen repository software for specifics on how to set the server itself up. However, this video from Gary Ewan Park is a useful resource for getting started with Sonatype Nexus (despite its age!) and demonstrates the concept in general:

Wrapping Up

Rate limits are there to keep the lights on for everyone. If you find yourself staring at a 429 error, take it as a sign that your automation has graduated; it is time to move from direct consumption to your own internal repository.

If you’ve got any questions about this post please reach out to us on our Community Hub!

You can also find us on:

Credit: Photo by Erik Mclean on Unsplash