# dorado: a Scoop bucket where every manifest installs without administrator rights > dorado is a third-party Scoop bucket for Windows, holding a curated set of manifests that work without elevation, among them a non admin nvm-windows, a non portable rustup and several MinGW toolchains. It is a small repository with a narrow purpose, and its value depends entirely on the quality of the manifests rather than on any code of its own. **chawyehsu/dorado** — 🐟 Yet Another bucket for lovely Scoop - Repository: https://github.com/chawyehsu/dorado - Website: https://chawyehsu.com/blog/talk-about-scoop-the-package-manager-for-windows-again - Stars: 1,233 · Forks: 111 - Language: PowerShell - License: Unlicense - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/chawyehsu-dorado ## A bucket is a manifest list, so the whole value is in the manifests dorado is a Scoop bucket, which means it is a directory of package manifests that Scoop reads and applies. The README calls it yet another bucket for Scoop and puts the guarantee in the header: none of the apps in this repository require elevated administrator privileges to install. That single line is the entire positioning statement, and it is a narrower and more interesting claim than it first looks. On Windows, the usual way to install a compiler, a Node version manager or a Python distribution is a machine wide installer that writes to protected directories, edits the system PATH and sometimes the registry, and needs an administrator account to do it. A bucket whose manifests install everything into the user scope sidesteps that. Because a bucket holds no executable code of its own, the quality bar is entirely in the manifest files, the URLs they point at, the hashes they pin and the install scripts they run. There is no library to import, no API to call, and no service to run. ## The catalogue is mostly toolchains and non admin variants The featured apps table reads like a list of things that normally demand elevation. `llvm-mingw` is an LLVM, Clang and LLD based mingw-w64 toolchain. `winlibs-mingw-msvcrt` and `winlibs-mingw-ucrt` are full mingw-w64 toolchains with the MSVCRT and UCRT runtimes respectively, built and distributed by winlibs, and `winlibs-mingw-llvm-ucrt` is the UCRT build with LLVM support added. `nuwen-mingw-gcc` is the minimalist GCC compiler from the MinGW Distro, and the description is careful to say it is not a full toolchain, with no make and no gdb, just gcc and ld for quick start scenarios. Then there are the deliberately modified tools. `nvm-windows` is a fork that removes the elevated permission requirement for non admin Scoop users. `rustup-np` is a non portable variant of Rustup that keeps `.rustup` and `.cargo` in their original location under `$env:USERPROFILE`. `miniconda3` is a variant that does not add the default venv to your PATH unless you activate it with `conda activate base`. `volta` is there with the note that you do not need nvm-windows any more, and `trash` moves files and folders to the recycle bin instead of using `rm -rf`. ## The modified variants are where the judgement calls live Several entries are not the upstream tool, and that is the part a user has to read carefully rather than install blindly. The `nvm-windows` manifest points at a fork rather than the original project, and the fork exists to remove the elevated permission requirement. The `rustup-np` manifest is a non portable build, so the trade is explicit: the Rust toolchain stays in the user's own profile directory instead of a shared location, which is what makes an elevation free install possible at the cost of that shared location. The `miniconda3` entry is a variant that keeps the base environment out of your PATH until you activate it, which is a fix for the classic problem of a package manager's installer silently changing the environment of every shell. The `nuwen-mingw-gcc` entry is deliberately incomplete. And the `volta` entry carries a plain claim that nvm-windows is no longer needed, which is an editorial position in a table of manifests. The point for a reviewer is that a bucket is where a curated opinion lives, and dorado's opinion is that the per user variant of a tool is usually the one you actually want on a managed Windows machine. ## Adding the bucket and installing from it The usage section gives two PowerShell commands, and that is the whole installation story for the bucket itself: ```powershell scoop bucket add dorado https://github.com/chawyehsu/dorado ``` ```powershell scoop install dorado/ ``` The app name is the manifest name inside the bucket, and the first command registers the repository with your Scoop installation so that the `dorado/` prefix resolves. The repository layout is the evidence of how the catalogue is curated: a `bucket/` directory holds the current manifests, `deprecated/` holds ones that have been retired, `experiment/` holds entries that are still being tried out, `bin/` holds binaries, `scripts/` holds helper scripts, and `test/` holds the tests. The presence of separate deprecated and experiment directories is the useful signal, because it means the maintainer distinguishes between something that is finished and something that is still being evaluated, and you can check which list a given app is in before you install it. There is also a Chinese README alongside the English one, and the repository publishes no GitHub releases, which is normal for a bucket, since a manifest is referenced by commit rather than by a versioned tag. ## Updates come from forked manifest pull requests The README describes the contribution route with refreshing directness. If you want an app that is not in the bucket, open a new app request as an issue. If an app is outdated, be a contributor: fork the repository, update the app manifest, and file a pull request. And the request for new apps carries a caveat worth repeating, that you should consider submitting your new app pull requests to the official buckets if they satisfy the criteria, before opening a request in this bucket. That is a maintainer telling you the boundaries of their own scope, and it points at the real structure of the Scoop ecosystem, where a third party bucket takes the apps the official ones have not accepted. The path from an issue to a merged manifest is the maintenance model of the project: there is no versioned release to cut, no changelog to write, and no binary to ship. What changes is a file that points at a URL and a hash. The Unlicense, in a file named UNLICENSE at the root, puts those manifest files into the public domain, which is consistent with the rest of the Scoop ecosystem and means an application that cares about provenance can copy a manifest rather than depend on this repository. ## How this differs from the machine wide installers it replaces The alternative to dorado is not another bucket, it is the ordinary way of installing developer tools on Windows, and the difference in approach is per user versus machine wide. A machine wide installer copies files into a protected location, adds entries to the system PATH, may register things with the operating system, and needs an administrator account. That is the right model on a single machine you own, and it is the wrong model on a locked down corporate image, a shared build agent, or a machine where you simply do not have the credentials. A Scoop bucket like dorado keeps everything in the user scope, so the same manifest works on a personal desktop and on a machine where elevation is refused. The cost of that model is consistency across a fleet: a per user install is invisible to the machine, so an administrator cannot see it, and a tool that other users expect to be on the system PATH is not there. The second alternative is the official Scoop buckets, which the README itself points you to for anything that meets their criteria, and the practical reading is that dorado is the place to look when the official bucket either does not carry the tool or carries the variant that needs elevation. ## Conclusion Adopt dorado if you install developer tooling on Windows without administrator rights, especially for Node, Rust or a MinGW toolchain, since the bucket exists to make those installs work in a per user context. Do not adopt it as a general package source, because the catalogue is small and curated, and the README asks that new apps go to the official buckets when they meet their criteria. Before you install anything, check the manifest list in the `bucket/` directory for the app you want, read the description of the variant you are getting, since several entries are deliberate modifications of the upstream tool rather than the upstream tool itself, and expect the project to be maintained by manifest pull requests rather than releases. The licence is the Unlicense, and the last push was on 2026-10-19. ## FAQ ### How do I install apps from the dorado bucket? Add the bucket with `scoop bucket add dorado https://github.com/chawyehsu/dorado` in PowerShell, then install an app with `scoop install dorado/`, where the name is the manifest name inside the bucket. ### Do dorado apps need administrator rights? No. The README states that none of the apps in the repository require elevated administrator privileges to install, which is the point of the bucket, and several manifests are modified variants built specifically to work that way. ### What is the difference between nvm-windows and rustup-np in dorado? The nvm-windows entry is a fork of nvm-windows that removes the elevated permission requirement for non admin Scoop users. The rustup-np entry is a non portable variant of Rustup that keeps `.rustup` and `.cargo` in their original location under `$env:USERPROFILE`. ### How do I request a new app or report an outdated manifest in dorado? Open a new app request as an issue. For an outdated app, the README asks you to fork the repository, update the app manifest and file a pull request, and it suggests considering the official Scoop buckets first if the app meets their criteria. ### What licence does dorado use? The repository includes an UNLICENSE file at the root, and the license badge in the README points to it. The repository publishes no GitHub releases, since manifests are referenced by commit rather than by a versioned tag. ## Sources - [chawyehsu/dorado on GitHub](https://github.com/chawyehsu/dorado) - [Issues](https://github.com/chawyehsu/dorado/issues) - [License: Unlicense](https://github.com/chawyehsu/dorado/blob/master/LICENSE) - [Project website](https://chawyehsu.com/blog/talk-about-scoop-the-package-manager-for-windows-again) - [README](https://github.com/chawyehsu/dorado/blob/master/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/chawyehsu-dorado