Overview

Rigo is a dotfiles manager for macOS, Linux, and Windows. It keeps the real files in a plain directory called the vault and symlinks them into their usual places. The name Rigo combines rig (rigging up an environment) with Go, the implementation language.

Design Philosophy

Rigo's design comes down to three points.

• Syncing is not Rigo's job
  The vault is a plain directory you sync across machines with whatever tool you like (Syncthing, Dropbox, iCloud Drive, and so on). Rigo itself never touches the sync mechanism.
• No extra "apply" step
  Editing a linked file edits the vault copy directly. The change rides the sync tool to your other machines as it is.
• No manifest, no templating
  The vault's directory tree itself is the single source of truth, mirroring your home directory (vault/.zshrc → ~/.zshrc). There is no separate file listing "what to manage".

A configuration file, rigo.toml, does exist, but it annotates the vault (directory-unit deployment, per-machine selection, secrets, and so on) rather than acting as a manifest. Every item in it is optional.

Features

• File-level and directory-level symlink deployment with a five-state model (linked / pending / unlinked / conflict / broken)
• Conflicts are never resolved silently (Rigo shows a diff and asks, or requires an explicit --force)
• OS-specific entries under .os/<darwin|linux|windows>/, plus per-distribution overlays on Linux
• Per-machine selective deployment via groups / include / exclude
• Tags for grouping entries and operating on them in bulk
• Named volumes for non-system drives on Windows
• A secrets subcommand that materializes secrets from 1Password (op:// references)
• An in-vault trash that makes forget undoable

Why Another Dotfiles Manager

There are already plenty of dotfiles managers. Rigo exists because none of them combined the design philosophy and the features above.

• No version control required
  Dotfiles do not necessarily need version control. Git-centric tools (yadm, bare-repository setups) fix the sync mechanism to git, while Rigo treats the vault as a plain directory, so syncing alone with Syncthing, Dropbox, or iCloud Drive is enough (and if you do want history, the vault itself can go under git).
• Edits take effect immediately
  Tools that copy a source state into place (the "apply" model, with chezmoi as the leading example) need a propagation step, or tool-mediated editing, after every edit. Switching environments, often cited as the strength of the copying model, only takes pointing Rigo at a different config file (the rigo.toml inside the vault; see How It Works for the procedure). Day-to-day work happens against a single vault, so Rigo favors the immediacy of symlinks.
• No manifest, no templating
  dotbot's YAML manifest, and chezmoi's filename encoding (dot_zshrc) and templates, are at odds with "the vault tree itself is the single source of truth".
• Windows as a first-class citizen
  Earlier symlink-based tools (GNU Stow, Mackup) have no practical Windows support. Rigo designs for Windows down to the %APPDATA% / %LOCALAPPDATA% sections and named volumes.
• Observed state and safe convergence
  The combination of the five-state model, interactive conflict resolution, and the trash is only partially available in existing tools.

The closest relative is GNU Stow (a manifest-less symlink farm), but it lacks Windows support, OS layers, per-machine selection, and secrets. The strongest contender, chezmoi, is powerful, but its templates and apply-style workflow sit on the other side of the design philosophy.

Requirements

Platform	Requirements
macOS	13 or later
Linux	—
Windows	11. Creating symlinks requires Developer Mode (Settings → System → For developers) or an elevated prompt

Installation

Download a release archive and put rigo somewhere on your PATH, or build from source:

go install github.com/rinodrops/rigo@latest

For Linux, .deb / .rpm packages are also attached to releases.

First Steps

Only the first run on a new machine names the config file inside the vault with -f. After that, the vault is discovered automatically.

# First run on a new machine only: name the config inside the vault directly
rigo -f ~/Sync/Vault/.config/rigo/rigo.toml apply

# From then on, the vault is discovered automatically
rigo status

# Start managing a file (moves it into the vault, links it back)
rigo add ~/.zshrc

For a walkthrough from zero to multi-machine syncing, see the tutorial (macOS and Linux) or the tutorial (Windows); for individual command specifications, see the command reference. The machinery (the state model, the vault layout, per-machine selection) is covered in How It Works.

License

MIT. The source code is on GitHub.