Bottom line - As an individual using Chocolatey, you are more likely okay if something breaks when setting up your personal machines - the Community Package Repository is typically fine for you. When it comes to using Chocolatey in an organizational context, you want reliability, control, and trust. You can gain trust over some packages on the community repository, and possibly some reliability if the binaries are included in the package. However there is a limiting factor with a public repository - distribution rights. This creates a large failure point that organizations just don't have when they are hosting their own internal packages.
As an organization, you want 100% reliability (or at least that potential), and you may want full trust and control as well. This is something you can get with internally hosted packages, and you are unlikely to achieve from use of the Community Package Repository. If your use of Chocolatey is for an organization/business, you likely have a low tolerance for production breakages and/or low trust for the greater internet. You likely would not want to give control of your infrastructure over to community members and volunteers. Organizational use of the community repository is not recommended.
Chocolatey is the best option for software management, as long as you are using package repository sources you can rely on.
A huge thing in Windows ecosystem is copyright law and how it plays into distribution rights. Most software in POSIX-land (Linux) is open source friendly, which has friendly redistribitution rights (redist). So you can embed that software directly in the package and publicly offer it. In Windows that is not the case - an organization like Microsoft would get very upset if the Office 365 packages on the public Community Package Repository actually contained the Office 365 binaries. That creates an enormous failure point that is outside of the package's control when it needs to download files at install time (that dependency on internet-available files that are hoped to always be available, but in practice they are not).
You can build a 100% reliable pipeline/workflow within the Chocolatey framework, just not with the community package repository. Building a reliable pipeline is huge. If you are a Windows admin wanting to trust a framework like Chocolatey, you are not going to use the Community Package Repository. Not when your reputation/job is on the line for picking the best options.
NOTE: You can also achieve reliability when reusing community packages, as long as you [[internalize|How-To-Recompile-Packages]] them. Internalizing is not the same thing as caching the nupkg files like Artifactory, Nexus, ProGet, etc can do.
Windows admins typically need to do everything internally with no outside internet access. There is quite a bit more hush-hush, non-use of publicly available things without bringing it internal for absolute control and trust. There is a huge (semi-healthy, but maybe even unhealthy) lack of trust for anything reaching out to the internet. I'm not saying this is exclusive to Windows admins, but it is very much the norm. So using the community package repository is a non-starter for these kinds of folks.
There are options for organizations to be able to reuse packaging from the community repository but make the package 100% offline and reliable. Please look at those options on the pricing page if you are interested.
There is another psychology aspect to this - Debian/RPM are nearly the ONLY way you install software on those machines, so it is expected that you would go that route. There are organizations using POSIX environments (typically RedHat) where it is becoming more typical that they pull those repositories local as well so they can trust everything will always work and be reliable.
However Windows doesn't have a distro-provided repo. Chocolatey Software does not support use of the community repo for organizational use that doesn't also benefit the community (providing and maintaining packages). Reliability plays a huge part in that. If something breaks within the context of a package, then Chocolatey gets blamed (even though it is not Chocolatey's fault).
Please note that individuals (even organizations) using the community repository are unlikely to hit excessive use numbers under normal usage scenarios.
NOTE: If you do find you have been blocked / rate-limited, having commercial licenses will not have any effect the policies with the community package repository. These policies were put into place to ensure stability and availability for the entire community, not to try to get folks to pay for licensing.
See rate limiting below if you are seeing 429 errors (too many requests).
Another aspect to keep in mind is that the community package repository is meant for the community. Perceived abuses of the community package repository that affect it in a detrimental way for the rest of the community will not be allowed. By abusive, it may mean more than 100 installs per hour on average over an internally determined amount of time (it could be more, could be less) - this is not queries, this is installs, upgrades where actual package downloads are occurring. Let's say that is 30 days - that would mean 72,000+ package downloads over 30 days. When that is seen, our community team will make attempts to warn folks if we have known contacts (keep in mind it's highly unlikely we will have your contact information), and implement a temporary block to ensure your usage does not affect the community in a detrimental way. Many times this is due to a misconfiguration and can be corrected quickly.
Blocks are meant to be temporary bans, but require you to act to remedy the situation. If you have been blocked, please see the next sections for corrective actions.
NOTE: If you or your organization feels you will need to go over this limit with good reason and need whitelisted, please reach out at https://chocolatey.org/contact, choose "Blocked IP Address". As we have limited information, please include your name, email address, phone number, and the IP addresses you believe are blocked so we can contact you and verify if there is a ban. Once you have resolved any issues on your side, we can lift the ban.
To avoid excessive use, please see our [[organizational deployment guide|How-To-Setup-Offline-Installation]]. Installation of Chocolatey itself and everything else should be from your internal repository and not directly from the community package repository. There are even ways to automate caching (see below) / [[internalizing|How-To-Recompile-Packages]] (caching and internalizing are entirely different concepts) packages so you still get a pretty good hands off experience.
If you are not able to take advantage of [[internalizing|How-To-Recompile-Packages]] packages, you can still cache them locally (using package repository solutions like Artifactory, Nexus, ProGet, MyGet, etc), which will reduce your direct usage of the community repository. NOTE: Caching doesn't make the packages you are using from the community repository any more reliable, they may still need to download things from the internet at runtime - but it doesn't put you in a worse place than you already are at because you are already using the community repository directly which has issues identified in this document. If you want to achieve reliability when reusing community packages, you would need to [[internalize packages|How-To-Recompile-Packages]].
For caching of packages, something can be quickly implemented in 15-30 minutes to get your organization unblocked (and avoid rate limiting) while you look into implementing the rest of the [[organizational deployment guide|How-To-Setup-Offline-Installation]] (which takes about 1-2 hours). With 15-30 minutes, you can implement a Proxy Repository including the install of a Nexus Repository Manager v3 (or NXRM v2) which automatically caches (but does not [[internalize|How-To-Recompile-Packages]]) packages from the community repository (https://chocolatey.org/api/v2). This provides the same experience you get in using the community repository now but with more availability and no rate limiting!
NOTE: A block will not automatically expire, you will need to contact our team to resolve the block. Rate Limiting on the other hand does automatically expire after one hour. Please see rate limiting below.
If you have found that you have gone over the limit and have been warned/blocked, please reach out at https://chocolatey.org/contact (send message to "Blocked IP Address" in the drop down - you may need to do this from a different IP address) or go to https://gitter.im/chocolatey/choco to contact the community team. As we have limited information (only an IP address), please include your name, email address, phone number, and the IP addresses you believe are blocked so we can contact you and verify if there is a block.
See the section above on avoiding excessive use - the expectation is that organizations would not use the community repository directly. As part of addressing any misconfigurations you might have, you will also need to see about addressing the previous section on "How To Avoid Excessive Use".
Once you have resolved any issues on your side, we can lift the block. A block will be reimplemented later if we find excessive use again.
NOTE: Purchasing licenses will not have any effect on rate limiting of the community package repository. Please read carefully below to understand why this was put in place and steps you can take to reduce issues if you run into it. HINT: It's not an attempt to get you to pay for commercial editions.
As a measure to increase site stability and prevent excessive use, the Chocolatey website uses rate limiting on requests for the community repository. Rate limiting was introduced in November 2018. Most folks typically won't hit rate limits unless they are automatically tagged for excessive use. If you do trigger the rate limit, you will see a (429) Too Many Requests. When attempting to install Chocolatey you will see the following:
It will look like the following using choco.exe:
If you go to a package page and attempt to use the download link in the left menu, you will see the following:
You will start to see 429 Too Many Requests if you have triggered the rate limit. Currently the rate limit will be in place for one hour. If you trigger it again, it will then be set for another hour.
- Error 1015
NOTE: Please note that individuals using the community repository are unlikely to hit rate limiting under normal usage scenarios.
Details:
- Installations/downloads of Chocolatey itself (chocolatey.nupkg) are rate limited at about 5 per minute per IP address - temporary ban expires after 1 hour.
- All other packages are rate limited at about 20 per minute per IP address - temporary ban expires after 1 hour.
NOTE: Rate Limiting defaults are subject to change with or without notice as we find a good happy medium that ensures ease of use and stability for our community.
NOTE: A rate limit will automatically expire after an hour, but if you hit the limit again, it will block for another hour.
If you have found that you have been rate limited, please see How To Avoid Excessive Use. Implementing best practices for organizational use will limit chances of being rate limited again in the future.
- Individual users being rate limited should reach out as per the next section and let us know as we are constantly adjusting limits to find a happy medium and need to have as much data to work with as possible. In addition to providing the requested information, make sure to also mention you are "individual use" and provide details on what caused the rate limiting. We may ask you to provide logs for further inspection.
- Organizational use will be asked to set up best practices for Chocolatey deployments.
If you have special needs and are being rate limited, please reach out to us as in special instances, we can whitelist your IP address for a small period of time. Do the following:
⚠️ WARNINGRate limits are temporary and expire within an hour, but will trigger again if you go over the limits. You may not need to file a special request if you can determine alternative means of use or if you implement best practices.
- Go to https://chocolatey.org/contact.
- Select Blocked IP Address in "Send message to" drop down (this is important to get it routed to the right folks).
- IMPORTANT: Mention you are being rate limited, include your IP address.
- IMPORTANT: Note what special need your organization has in the message as well.
- You will typically receive a response somewhat quickly with options for you to implement. These are considered best practices and can typically be implemented within 15-30 minutes.
- Our team will evaluate your request within a few business days and make a determination if your need qualifies for whitelisting. If so, the team will typically put in a temporary one time 7 day whitelist for you to implement best practices.
NOTE: These are subjective, and special requests ONLY. Please ensure you implement best practices so that you are not rate limited.
See the section above on avoiding excessive use - the expectation is that organizations would not use the community repository directly. As part of addressing any misconfigurations you might have, you will also need to see about addressing the previous section on "How To Avoid Excessive Use".
The packages contained at https://chocolatey.org/packages (the community repository) are collectively known as the Community Feed or Community Repository. Packages found on the community repository may not be supported by the original software vendor. If you have an issue with a package, contact the package maintainers through the community repository package page, Do not contact the software vendor directly. It bears repeating, DO NOT contact the software vendor directly.
The packages you find on the community repository are completely unsupported. By using the packages on the community repository, you assume all risk for any issues or damages that may occur. The packages found in the community repository are built, moderated, and maintained by the community. While the packages are moderated by community moderators to help ensure safety and reliability (at the time of moderation), package maintainers and moderators assume no support nor liability for the packages. Neither package moderators nor package maintainers will be held liable for any issues, downtime, or damages that may occur from your use of the packages on the community feed. It is also not the responsibility of the package maintainers and/or package moderators to ensure that the package works in all scenarios. They are volunteers and thus are unable to support you and/or your business needs.
Support is not guaranteed by package maintainers, but should you encounter issues, please work directly with the maintainers to get the package(s) corrected. Do NOT contact the software vendor directly.
Transferring a package to another repository (even internal) with or without changes does not change the support level by the maintainers of Chocolatey, by the moderators nor maintainers, and not by Chocolatey Software, Inc.
Due to software distribution rights, many of the packages contained on the community repository must download actual software from official distribution points, thus creating a dependency on those internet locations not changing (and from time to time they do, thus breaking a package until it is updated). This introduces a failure point for the community repository that is not found with internal packages. When hosting your own internal packages you would not be subject to software distribution rights, so you could embed the software directly in the package or pull from an internal share location, thus guaranteeing a reliable and repeatable software management process.
For folks in the community that are not using Chocolatey for production purposes, with an understanding of the disclaimers set forth here, it is fine to use the community repository. For organizations that have a low tolerance for breakages and require a higher level of reliability, security, trust, and control, a self-hosted Chocolatey server is the recommended option. This guarantees that your installs, upgrades, and uninstalls will always work every time. This gives you complete control over what software gets installed. Also because you are vetting newer versions, you control when those newer versions are available for upgrade. Please see Host Your Own Server for more information.