Scoop: a non-admin command-line installer for Windows

The problem Scoop targets on Windows

Windows has no default package manager. The practical result is that setting up a machine means downloading MSI files, clicking through wizard dialogs, accepting a UAC prompt for each one, and hoping the uninstaller cleans up after itself. The README frames Scoop's purpose as installing apps from the command line with a minimal amount of friction, and it lists the specific annoyances it removes: UAC prompt notifications, wizard-style installer GUIs, PATH pollution, and unexpected side effects from install and uninstall.

The audience is narrow but well defined. Scoop is for people who treat a Windows box as something to be reproduced: developers who want the same toolchain on a laptop, a build agent, and a VM; anyone who has written a setup script and watched it break because a download URL changed. The README calls the tool script-friendly and gives a repeatable setup as the example. If you install apps by hand twice a year, the payoff is small. If you rebuild machines regularly, the payoff is the script itself.

How the manifest and shim model works

Scoop is written in PowerShell, and the repository layout reflects that: bin/, lib/, libexec/, supporting/, and a schema.json at the top level, with test/ holding the test suite. The schema.json is the contract for manifests, which are JSON files describing how to install one app.

The README is explicit about the mechanism. Apps that install cleanly are "portable" apps: compressed files that run standalone after extraction, without changing the Windows Registry or placing files outside the app directory. For those, the install step is extract, then expose the executable. Scoop also supports installer files and their uninstallation methods, single-file apps, and PowerShell scripts. The runat package is given as an example of the last case: it is simply a GitHub gist, with no archive at all.

Apps come from buckets, which are Git repositories of manifests. The README lists main as the default bucket for popular non-GUI apps, extras for apps that do not fit the main bucket criteria, plus games, nerd-fonts, nirsoft, sysinternals, java, and nonportable. Because buckets are Git repos, updating a bucket is a pull, and adding a private bucket is pointing Scoop at another repository. The README also notes that Scoop resolves and installs dependencies automatically, so a manifest can declare what it needs and Scoop will fetch it first.

Installing Scoop and running a first install

The README says to run the installer from a regular, non-admin PowerShell terminal. Two commands. The first changes the execution policy for the current user only, which the README explains is necessary because Windows 10 client devices restrict execution of PowerShell scripts by default.

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser
Invoke-RestMethod -Uri https://get.scoop.sh | Invoke-Expression

The second command downloads the installer script and evaluates it. According to the README, the default install location is C:\Users\<YOUR USERNAME>\scoop. Questions about the installer itself, including advanced configurations, belong in the separate ScoopInstaller/Install repository rather than the main one.

With Scoop on the machine, a first real use is installing a toolchain. The README gives this exact sequence as its example of a repeatable setup:

scoop install sudo
sudo scoop install 7zip git openssh --global
scoop install aria2 curl grep sed less touch
scoop install python ruby go perl

The --global flag on the second line is the part worth noticing: it installs for all users and therefore needs elevation, which is why the sudo package is installed first. The remaining lines are per-user installs and need no admin rights.

Downloads can be accelerated. Installing aria2 through Scoop is enough for Scoop to use it for all subsequent downloads, per the README:

scoop install aria2

While aria2 is enabled, Scoop prints a warning on scoop install and scoop update. The README documents how to silence it, and the tunable keys:

scoop config aria2-warning-enabled false

The configurable aria2 settings are aria2-enabled (default true), aria2-warning-enabled (default true), aria2-retry-wait (default 2), aria2-split (default 5), aria2-max-connection-per-server (default 5), aria2-min-split-size (default 5M), and aria2-options (default empty).

Where Scoop breaks down

The README's own framing is the limitation. Scoop is happiest with portable apps, and it says so: those are the apps most likely to install fine. Everything else is a supported case that costs more. The README acknowledges that installer files need their uninstallation methods handled, which is a different problem from extracting a zip, and single-file apps and scripts are edge cases the manifest format has to accommodate.

There is no rollback story in the README. You get install, update, and uninstall, but the README does not document reverting an app to a previous version after an update goes wrong. If your environment needs pinned versions with a tested downgrade path, verify that before you build a provisioning script around Scoop.

The manifest model also puts the maintenance burden on whoever writes the manifest. The README pitches Scoop as an alternative to building an MSI or InnoSetup installer: compress your app to a .zip and provide a JSON manifest describing how to install it. That is a lower bar than an installer, but the manifest is code. A download URL that moves, an archive whose internal folder name changes between releases, and the install breaks. For a public bucket, someone else maintains that. For your own software, you do.

Scoop against winget and Chocolatey

The obvious alternative on modern Windows is winget, and the difference is in the source of truth. winget wraps the vendor's own installer, so it inherits whatever that installer does: registry writes, machine-wide placement, an uninstaller registered in Windows. Scoop's default path is the opposite. It extracts an archive into a per-user directory and exposes the binary, which is why the README can claim it prevents PATH pollution and avoids side effects. If you want the vendor's installer behaviour, winget is the direct route. If you want the app isolated under your user profile, Scoop is.

Chocolatey is the closer comparison, and the split is administrative. Chocolatey's ecosystem is built around machine-wide packages that frequently require elevation, which suits managed fleets and configuration management. Scoop's default installs per user with no admin rights, and the README's example reaches for sudo only when it explicitly wants --global. The README also names Homebrew and Sub as inspirations, which explains the bucket model: a curated Git repository of recipes, pulled and updated like source.

The practical test is what you are installing. A portable CLI tool is a one-line Scoop install. A GUI application that writes to the registry and expects an entry in Add/Remove Programs is a winget or Chocolatey job, and Scoop's nonportable bucket exists precisely because some apps refuse to behave.

Maintenance, licensing and upgrade cost

The repository is not archived, and the last push was on 2026-09-19. Releases move slowly: v0.5.1 on 2024-07-17, v0.5.2 on 2024-07-30, and v0.5.3 on 2025-08-12. That cadence matters if you expect the core tool to change under you; it mostly does not. The churn lives in the buckets, which are separate repositories updated on their own schedule. Upgrading Scoop itself is therefore a rare event, while bucket refreshes are routine.

The licence is the part to read carefully. The repository's LICENSE file is the authority, and the README's badge says UNLICENSE or MIT. GitHub reports the licence as NOASSERTION, meaning the platform could not map the file to a single SPDX identifier. That is not a legal problem by itself, but if your organisation runs licence scanning, a combined UNLICENSE/MIT file may need a human to classify it. This is a description of the paperwork, not legal advice.

The real upgrade cost is not the tool. It is the manifests you own. Every private bucket you maintain is a Git repository you have to keep working as upstream download URLs and archive layouts change.

Editorial conclusion

Adopt Scoop if you provision Windows machines from scripts and want non-admin installs that leave the registry alone. Skip it if your workload depends on GUI apps that write to the registry or expect a machine-wide MSI. Before committing, install it in a non-admin PowerShell session, run scoop install python, and check where the shims land under C:\Users\<YOUR USERNAME>\scoop.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. ScoopInstaller/Scoop on GitHub