Dorothy: a dotfile ecosystem that treats your shell as a runtime

One configuration, many shells

Dorothy is described as a dotfile ecosystem, and the feature list is where the design shows. It claims support across Bash, Zsh, Fish, Nushell, Xonsh, Elvish, Dash and KSH, so a single configuration can be used from any of them, and it claims support across multiple operating systems and architectures, for your terminal and GUI editors, automatic configuration of environment variables for what is actually installed on the system, automatic installation and updating of the packages you specified, automatic Git, SSH and GPG configuration based on what the system supports, hundreds of commands in its own commands directory, and complete extensibility through your own user repository. The summary the README gives of the whole thing is that together this allows you to go from zero to productive on a brand new machine within minutes instead of days. The audience is a developer who moves between machines and shells, or who has accumulated the same dotfiles in three slightly different directories and knows the pain of keeping them in sync.

The repository layout is a set of shells and a command library

The top level entries show how the pieces are organised. There is a commands/ directory holding the command library, with commands.beta/ and commands.deprecated/ alongside it for commands that are being tried out and commands that are on the way out, which is a revealing detail about how the project manages churn. Then there is config/ for configuration, sources/ for the package sources, themes/ for themes, docs/ for documentation, and a root package.json plus eslint.config.js, a cspell.json, a .trunk/ directory and a .prettierignore, so the project itself lints and formats its shell code. The most telling files are the init scripts: init.dash, init.elv, init.fish, init.ksh, init.nu, init.sh and init.xsh, one bootstrap script per supported shell. That is the core of the design, because each of those scripts is responsible for handing control to the shared configuration in a way the shell can accept.

Per platform and architecture support is tracked through CI

The setup section publishes a support table that is worth reading before you commit, because it is organised by operating system and architecture rather than by shell. macOS appears for both Apple Silicon and Intel or AMD, Raspberry Pi OS appears in both desktop and lite flavours, and Windows 10 and 11 appear through WSL2 with Ubuntu, Debian, AlmaLinux and Kali distributions. The Linux list is long and includes AlmaLinux on Raspberry Pi, Arch, CachyOS, Debian on both architectures, Devuan, elementary OS, Fedora in workstation and server flavours, Kali on ARM, and openEuler, with the table continuing beyond what is shown. Every entry carries a CI marker, which is the honest signal in the table: the support claim is a claim that the project tests that combination, not just that it says it works. The architecture column distinguishes ARM64 machines such as the Raspberry Pi from x86_64 machines, and the README's own feature list claims support across multiple operating systems and architectures, so the coverage is broad in principle and CI-backed in practice.

A shell framework rather than a dotfile repository

This is the distinction that matters when you evaluate the project. A dotfile repository is a set of files you copy to a machine and adjust. Dorothy is a framework, and the difference shows in the feature list. Automatic configuration of environment variables for what you have installed on your system means the configuration is evaluated against the machine rather than being a static file, and automatic Git, SSH and GPG configuration based on what your system supports is the same idea applied to credentials. Automatic installation and updating of your specified packages pulls in the package manager layer, and the hundreds of commands are a library of things that would otherwise be your own shell functions. The description at the repository level groups this into four parts, a framework for cross-shell, cross-cli and cross-tui scripting, an overlay for cross-shell, environment and dotfile interoperation, a manager for cross-source packages, apps and utilities across sources like GitHub, brew, apt, flatpak, appimage, cargo and npm, and hundreds of cross-OS commands for macOS, Linux and Windows on both x86 and ARM.

The custom licence and the open questions it leaves

The licence is the thing to check before you install this. The repository is marked as using a custom licence that GitHub cannot classify, and the package manifest names it as RPL-1.5. The top level carries a LICENSE.md file, so the terms are there to read, but a bespoke licence attached to something that installs packages and configures Git and SSH on your machine deserves ten minutes of your own attention rather than an assumption that it is equivalent to MIT. The README also points to a contributor guide and a TODOS.md file, which is an honest sign of a project that still has work ahead of it. There is no installation command in the README itself, and the setup section is cut short in the table of supported platforms, so the practical next step for an evaluator is the project's own documentation rather than a copy-paste line, which is unusual for a tool in this category and tells you the project expects you to read before you run it.

Where Dorothy is the wrong choice

There are two cases where the abstraction costs more than it saves. The first is the single shell, single machine developer. If you use Zsh on your laptop and nothing else, the value of a framework that boots eight shells is low, while the cost is real: you are inside someone else's conventions for how packages are declared, how commands are invoked, and how configuration is layered. The second is the team that wants a lightweight dotfile sync. Dorothy's own feature list includes automatic package installation and updating, and automatic Git, SSH and GPG configuration, which are exactly the parts that want a careful audit before you point them at a new machine. The alternative worth naming is a plain dotfile repository with a small bootstrap script, which you can read end to end in an afternoon, and the cost of that choice is that you maintain the shell specific parts yourself. Dorothy earns its place when the scale of your environment justifies a framework, and the size of the commands/ directory suggests the author believes the answer is often yes.

How a project like this stays maintained

A few signals from the repository tell you what kind of effort this is. The commands are split into a stable directory and a beta directory, plus a deprecated one, so new commands can be tried in public before they become part of the interface and old ones can be retired without being deleted outright. The project is written in Shell with a TypeScript-adjacent toolchain, since the package manifest is a Node package with eslint, prettier, trunk and cspell configuration, which means the shell code is checked by the same linting pipeline a JavaScript project would use. The topics list the shells, the dotfile management keywords, WSL2 and Ubuntu, and the platforms people actually use, which is consistent with a project that grows by adding support rather than by rewriting. The last push was on 2026-09-14, the project publishes no GitHub releases, and the version in the manifest is 1.0.0, which together say this is a continuously deployed personal infrastructure project that happens to be public rather than a versioned product with a support commitment.

Editorial conclusion

Adopt Dorothy if you use several shells across several machines and want one configuration that adapts itself to what is installed rather than a set of dotfiles you maintain per shell. Do not adopt it if your work is mostly in one shell on one machine, because the abstraction has a cost. Verify first which of the supported platforms your machines cover, since the project tracks support through CI per operating system and architecture, and read the RPL-1.5 licence in LICENSE.md before assuming the terms match what you expect from a dotfile manager.

Frequently asked questions

Official sources

1. bevry/dorothy on GitHub
2. Issues
3. README