dotdrop for Versioned Dotfiles Across Multiple Hosts

Why dotdrop targets host-specific dotfile collections

dotdrop addresses a problem that basic Git-backed dotfiles do not fully solve: the same logical setting may need different contents on different hosts. A laptop and office desktop can share most files while requiring different shell initialization, desktop panel settings, or temporary-machine defaults. dotdrop represents those differences as profiles containing named subsets of managed dotfiles.

The intended users are people who already store configuration in Git but find a single copied directory awkward when deploying to several systems. The feature list also includes individual files, directories, and symbolic links, so the model is not restricted to one file copied into every home directory. Actions can be associated with deployment, while transformations can store sensitive or compressed content in forms that are processed when deployed.

Profiles can overlap. The README's `home` profile contains a Vim configuration, an X startup file, and a Polybar directory, while its `office` example keeps only the latter two entries. That makes dotdrop a fit for shared baselines with exceptions, rather than requiring a separate repository for every hostname. By default, a profile resolves to the current hostname, but `-p` or `--profile` allows an explicit selection.

Inside dotdrop's config.yaml and profile model

A dotdrop repository combines the managed files, configuration, and profile assignments. The documented default config uses `dotfiles` as the `dotpath` and `~/.config/dotdrop` as its `workdir`. Importing does two concrete operations: it copies the selected file or directory into the dotpath and adds corresponding entries under `dotfiles` and `profiles` in `config.yaml`.

Each `dotfiles` entry defines the managed identifier, destination, and stored source. In the documented import result, `f_vimrc` maps `vimrc` to `~/.vimrc`, while `d_polybar` maps the stored `config/polybar` directory to `~/.config/polybar`. The `profiles` section then lists which identifiers belong to each deployment profile.

This indirection is dotdrop's main architectural distinction. The destination can be an individual file or a directory, and deployment is controlled by profile membership rather than by placing the entire repository into `$HOME`. It also creates room for host-dependent content. The README links templating documentation and introduces conditional content based on a `profile` variable.

The configuration is YAML rather than a flat script. The repository declares `ruamel.yaml` as a dependency, and the sample includes settings for backup, banners, creation, ignored empty files, dot retention, long keys, diffs, and paths. Those options make the tool adjustable, but they also mean an existing repository needs some design work instead of only a copy-and-symlink conversion.

Installing dotdrop from its checked-out repository

The README's quick start keeps dotdrop in a Git submodule, installs its Python requirements for the current user, bootstraps the checkout, and displays command help. Run these commands inside a new dotfiles repository as shown. The final command should print the `dotdrop.sh` help output rather than change existing dotfiles.

mkdir dotfiles && cd dotfiles
git init
git submodule add https://github.com/deadc0de6/dotdrop.git
pip3 install -r dotdrop/requirements.txt --user
./dotdrop/bootstrap.sh
./dotdrop.sh --help

For a system installation rather than a submodule checkout, the README lists PyPI, Homebrew, stable and git AUR packages, Snapcraft, and Pacstall. It links those channels to separate installation instructions but does not provide platform-specific package commands in the project overview. The project metadata requires Python `>=3` and declares `Jinja2`, `distro`, `docopt-ng`, `packaging`, `python-magic`, `requests`, `ruamel.yaml`, `tomli`, and `tomli_w` as dependencies. `python-magic-bin` is additionally declared for Windows in `requirements.txt`.

That source distribution model is convenient for users who want dotdrop versioned alongside their configuration. It also adds a bootstrap step and repository submodule to maintain.

Importing files and comparing a second host

After dotdrop is installed, a new repository needs a generated `config.yaml`. The README links the configuration-generation command to its usage documentation but does not print that command, so it should be taken from that page rather than guessed. Once generation and dotfile imports are complete, the imported repository can be committed and pushed to Git.

Import the files and directories that should be managed from the first host. The command below copies the selected items into the configured dotpath and writes their metadata and profile membership. After it finishes, `config.yaml` should contain entries corresponding to `.vimrc`, `.xinitrc`, and `.config/polybar`.

$ dotdrop import ~/.vimrc ~/.xinitrc ~/.config/polybar

On another host, clone the repository and compare local files against the stored versions for the intended profile. This is a non-destructive planning step documented by the README.

$ dotdrop compare --profile=home

The comparison is especially useful before editing a host-specific profile. The README does not document a separate rollback command, so an adoption should not assume one from the overview. It does document backup configuration, but the sample `backup: true` setting should not be treated as a complete recovery procedure without checking the linked configuration documentation.

Profiles and templates for genuinely different host configurations

A profile is not merely a label. Its membership determines which managed identifiers participate in deployment. Removing `f_vimrc` from the `office` profile while retaining `f_xinitrc` and `d_polybar` produces an overlapping deployment: both hosts receive two settings, but only `home` receives the Vim file.

Templates address differences inside a managed file. The README begins an example in `<dotpath>/config/polybar/config` that checks whether `profile == "home"`. That condition can select host-specific content while retaining one stored source file. This is more appropriate than maintaining two near-identical Polybar directories when the only variation is a small setting.

The repository lists Jinja2 as both a project dependency and a keyword, so templates are part of the core model rather than an external script. Dynamic file generation with predefined variables is also listed as a feature. Still, templates introduce a second source of deployment-time input. A saved file that renders incorrectly will not be diagnosed merely by inspecting its stored text, so the generated result must be compared after deployment.

The repository also associates actions with particular dotfiles and supports transformations for encrypted or compressed content. These features extend the basic profile mechanism, but the README does not provide a complete GPG, action, or transformation tutorial. The linked documentation should be checked before relying on those features for unattended machine provisioning.

dotdrop versus a plain Git directory of symbolic links

A plain Git repository plus symbolic links is the closest alternative. It stores canonical files and points home-directory paths at them, so it has little configuration structure and is easy to inspect with Git. For users who deploy an identical configuration to one kind of host, that simplicity can be preferable.

dotdrop takes a different approach. It maintains a YAML mapping from managed identifiers to source and destination paths, then uses profiles to select subsets. That extra layer supports overlapping host configurations, conditional templates, directory deployment, and actions tied to individual files. It is also a better fit when the target host should receive a tailored configuration rather than the repository's single version.

The trade-off is repository complexity. Users must maintain `config.yaml`, understand source versus destination paths, and check rendered content. A symbolic-link setup can also preserve the live file as the source of truth, whereas dotdrop's import step explicitly copies local files into the dotpath and records metadata. Neither approach is automatically preferable. The deciding issue is whether host variation and deployment behavior matter enough to justify a configuration manager.

Maintenance, licensing, and upgrade boundaries

The repository is not archived, and its last push was on 2026-10-13. Recent releases include v1.17.0 on 2026-09-09, v1.16.2 on 2026-05-17, and v1.16.1 on 2026-04-12. Those records show recent project activity, although they do not establish that every configuration format or external integration remains compatible across upgrades.

The repository uses GPL-3.0. That matters for redistribution and modification of distributed versions, but this review does not provide legal advice. Users embedding dotdrop into another distributed product should review the license requirements separately.

Upgrades can affect three connected areas: the `dotdrop` package itself, repository configuration, and scripts or actions attached to managed files. The project metadata supports Python 3 versions through 3.14 and keeps the command entry point at `dotdrop = 'dotdrop:main'`. Its test workflow and test directory are present, but the README does not publish a migration procedure for `config.yaml` between v1.16.x and v1.17.0. Existing encrypted files are a particular upgrade checkpoint because they depend on correct transformation and key configuration. The repository is current, but compatibility of a particular setup still needs verification against the release notes for the installed version.

Editorial conclusion

Adopt dotdrop if your configurations vary across laptops, desktops, or temporary machines and you want those differences represented in a Git-managed repository. Do not choose it if you need only a flat collection of identical symbolic links. Before adoption, verify that `config.yaml`, profile membership, template variables, and any GPG or transformation settings match your existing setup. The most important first check is whether the default `dotfiles` dotpath and `~/.config/dotdrop` workdir can be accepted without redesigning the repository layout.

Frequently asked questions

Official sources

1. deadc0de6/dotdrop on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases