# Chocolatey (choco): the Windows package manager, and where it stops being the right tool > Chocolatey is a NuGet-based package manager for Windows written in C#. It installs, upgrades and uninstalls software from the command line, and its design choices matter most on servers and CI runners rather than on a personal laptop. **chocolatey/choco** — Chocolatey - the package manager for Windows - Repository: https://github.com/chocolatey/choco - Website: https://chocolatey.org - Stars: 11,528 · Forks: 962 - Language: C# - License: NOASSERTION - Published: 2026-09-21 · Updated: 2026-09-21 · Language: en - Canonical page: https://hysenlabs.com/projects/chocolatey-choco ## The problem Chocolatey solves on Windows Linux administrators had apt-get and yum for years. Windows had installers: download a file, click through a wizard, repeat on every machine, hope you remember the version you picked. Chocolatey is the answer to that gap. The README opens with the comparison directly, calling it "like yum or apt-get, but for Windows." The audience follows from that. It is for people who provision Windows machines in bulk: build agents, virtual machine images, servers that need a fixed set of tools before a deployment runs. It is also for developers who want one command to bring a fresh Windows install up to a known state instead of a browser session with six vendor download pages. What makes the fit awkward for some people is the packaging model. Chocolatey is not installing a binary it hosts itself. It resolves a package, and that package carries the instructions for fetching and running the vendor's own installer. That is a different trust story from a distribution that builds every package from source, and it shapes everything below. ## How choco resolves and installs a package The engine is a C# application, choco.exe, and the repository layout shows the shape of it: src/ holds the source, lib/ holds dependencies, nuspec/ holds packaging definitions, and NuGet.config sits at the top level. Chocolatey uses NuGet as its package format, which is why a Chocolatey package is a .nupkg and why the project vendors a NuGet client (update-nuget-client.ps1 exists to refresh it). A package is not just metadata. It contains a PowerShell script that Chocolatey runs during install, upgrade and uninstall. That is the mechanism that lets one tool wrap thousands of unrelated Windows installers, and it is also the reason a package can do almost anything on the machine it lands on. The data flow is roughly: choco.exe parses the command, resolves the package name and version against a feed, downloads the .nupkg, extracts it, and executes the package's scripts with the privileges of the current shell. Requirements listed in the README are .NET Framework 4.8 or later, PowerShell 2.0 or later, and Windows Server 2008 R2 or Windows 10 or later. The documentation points to a support lifecycle page for the finer details of which operating systems are still covered. The project ships a Docker image too (chocolatey/choco on Docker Hub), which is aimed at the "installing on other platforms" path rather than at running Chocolatey as a native Linux package manager. ## Installing choco and running a first install Chocolatey's own documentation and the website are the places the project points to for installation; the README itself does not reproduce the install script. The README does give the command line entry point: run choco.exe --help, or choco.exe -h, and for a specific command append the help switch. Once choco.exe is on the machine, the first useful thing to do is confirm you are talking to the right binary and see the command surface: ```bash choco.exe --help ``` The help output lists the available commands. To read the options for one of them, the README gives this pattern: ```bash choco.exe install --help ``` That prints the switches install accepts, including version pinning and source selection, without you having to leave the terminal. A first real install then looks like the package name followed by nothing else: ```bash choco.exe install git ``` Chocolatey resolves the package, downloads it, and runs the package's install script. Expect an elevated shell: the requirements and the packaging model mean the tool is designed around administrative rights, and the README's own demonstration GIF shows tab completion and refreshenv, which updates environment variables in the current session so a freshly installed tool is on PATH without restarting the shell. ## Where Chocolatey is the wrong choice The community feed is maintained by volunteers, and the README says so plainly in its etiquette section: most people answering questions are unpaid and have lives outside open source. That is not a criticism of the software, but it is a real constraint on what you can expect. Package updates depend on someone caring about that package, and the README routes package problems to a triage process rather than to the core issue tracker. If you need a guaranteed update cadence for a specific piece of software, the community feed is not that guarantee. The second limitation is trust. Because a package runs its own scripts during install, you are executing third-party code with administrative rights. Chocolatey Pro and Chocolatey for Business are marketed around exactly this concern, with private CDN download caching and virus scan protection shown in the README's comparison GIF. If your environment cannot accept running community-authored install scripts, the free edition is the wrong tool and the commercial editions exist for that reason. The third is scope. Chocolatey is a Windows tool. The Docker image and the "installing on other platforms" section in the README exist, but the requirements are Windows and .NET Framework. Treating it as a cross-platform package manager will not match what the project actually supports. ## Chocolatey compared with winget and Scoop winget is Microsoft's own command line package manager, shipped with modern Windows. The difference in approach is the source of packages: winget pulls manifests that point at vendor installers through Microsoft's community repository, while Chocolatey pulls NuGet packages that carry PowerShell install scripts. winget is already present on the machine; Chocolatey is something you install first. If your only goal is installing a handful of desktop applications on a machine you control, winget removes an installation step. Scoop takes a different angle again. It is built around per-user installs and portable applications, with no administrative rights needed, which is the opposite of Chocolatey's machine-wide model. On a locked-down developer laptop where you cannot gain administrative rights, Scoop fits and Chocolatey does not. Chocolatey sits between them in an important way: it is the one whose package format carries executable install logic, which is what makes it able to wrap arbitrary Windows installers, and also what makes the trust question unavoidable. Pick Chocolatey when you need that wrapping and you control the machine; pick winget when the vendor manifests cover your software; pick Scoop when you cannot gain administrative rights. ## Maintenance, releases and the upgrade path The repository is not archived, and the last push was on 2026-08-19. Releases arrive on two lines: 2.7.4 and 1.4.7 both landed on 2026-08-19, with 2.7.3 before them on 2026-06-10. The two parallel version lines are worth noticing, because 1.4.7 is a maintenance release on an older branch rather than a step toward 2.7.x. If you are on the 1.x line, upgrading to 2.x is a deliberate move, not something that happens by pulling the newest tag. Upgrade cost inside the tool is low: choco upgrade takes the same package names you installed with. The cost that does not disappear is the one the README's requirements imply. .NET Framework 4.8 and PowerShell 2.0 are the floor, and the supported operating system list lives on a separate documentation page. Machines you cannot move off an old Windows Server build are the ones where the upgrade path gets expensive, not the choco command itself. The licence is Apache 2.0 according to the README, with LICENSE and NOTICE files at the repository root. Apache 2.0 is permissive, but the NOTICE file exists for a reason and the commercial editions are separate products with separate terms, which the README states directly. Read both files rather than assuming the permissive licence covers everything in the tree. ## Conclusion Adopt Chocolatey when you manage Windows machines you cannot sit in front of: build agents, servers, and images where a repeatable choco install line beats clicking through installers. Skip it on a desktop where winget already covers your software, or where you want per-user installs without administrative rights, since Chocolatey is built around an elevated shell. Before rolling it out, verify which of your packages are maintained inside the community feed, because Chocolatey installs third-party packages that run their own install scripts. Check the LICENSE and NOTICE files against your own redistribution rules, and read the support lifecycle page for the Windows versions you still run. ## FAQ ### How do I install Chocolatey on Windows? The README does not reproduce the installation script; it points to the documentation and the chocolatey.org website for installation. The requirements are .NET Framework 4.8 or later, PowerShell 2.0 or later, and Windows Server 2008 R2 or Windows 10 or later. ### How do I install Chocolatey in PowerShell? Chocolatey runs from PowerShell and its packages use PowerShell scripts, so once choco.exe is present you can run commands such as choco.exe install git from a PowerShell session. Expect to need administrative rights, since the tool is built around them. ### How does Chocolatey compare with winget? winget is Microsoft's package manager and is already present on modern Windows, while Chocolatey is installed separately and uses NuGet packages that carry PowerShell install scripts. winget's manifests point at vendor installers through Microsoft's repository, so it avoids the extra installation step if it covers your software. ### How does Chocolatey compare with Scoop? Scoop is built around per-user installs and portable applications without administrative rights, which is the opposite of Chocolatey's machine-wide model. On a machine where you cannot gain administrative rights, Scoop fits and Chocolatey does not. ## Sources - [chocolatey/choco on GitHub](https://github.com/chocolatey/choco) - [Issues](https://github.com/chocolatey/choco/issues) - [Project website](https://chocolatey.org) - [README](https://github.com/chocolatey/choco/blob/develop/README.md) - [Releases](https://github.com/chocolatey/choco/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/chocolatey-choco