Beyond Dotfiles: Syncing Packages, Repos, and Entire Workflows

The term "dotfile manager" has become a catch-all for tools that manage developer environments. But the name reveals the limitation: these tools were built for dotfiles, the configuration files that live in your home directory and start with a dot.

Dotfiles are important. Your .zshrc, .gitconfig, and .vimrc encode years of workflow refinement. But they are only one piece of what makes up a functioning development environment. If you have ever set up a new machine by restoring your dotfiles and then spent another four hours installing tools, cloning repos, and hunting down credentials, you already know this.

A modern development environment is built from five distinct layers, and any tool that claims to manage your environment should handle all of them.

1. Dotfiles. Configuration files for your shell, editor, git, SSH, and other tools. This is the layer that traditional dotfile managers handle well. Symlink management, templating, and version control for files like ~/.zshrc,~/.config/nvim/init.lua, and ~/.ssh/config.

2. Packages and tools. The software you have installed: Homebrew packages, npm globals, pip tools, cargo binaries, language runtimes, and system utilities. These are not files in your home directory. They are installed software that your workflow depends on. Without them, your dotfiles reference commands that do not exist.

3. Git repositories. The codebases you work on, their clone URLs, their branch states, and their locations on disk. Setting up a new machine means cloning sometimes dozens of repositories and organizing them in the right directory structure.

4. Secrets and credentials. API keys, SSH private keys, environment variables, service tokens, database connection strings. These are the most critical and most poorly managed layer. They live in .env files, keychains, and scattered plaintext files, rarely backed up and never synced safely.

5. Project configurations. Per-project settings that tie together a repo, its secrets, and its local configuration. The .env.local that makes your web app connect to the right database. The IDE run configuration that sets the right flags. The docker-compose overrides for local development.

ConfigSync treats installed packages as a first-class part of your environment. Theconfigsync scan command inventories everything you have installed across multiple package managers and captures the result as part of your environment snapshot.

When you pull on a new machine, ConfigSync installs missing packages automatically. It handles cross-platform mapping too. If you use brew install ripgrep on macOS, ConfigSync knows to use apt install ripgrep on Ubuntu. Your environment is described by what you need, not by which package manager provides it.

Your git repositories are part of your environment. ConfigSync tracks which repos you work on, where they are cloned, and what branch they are on.

No more maintaining a list of repos to clone. No more trying to remember the directory structure you had. Track them once and they are restored automatically on every new machine.

Secrets are where most environment tools fail completely. They either ignore secrets (leaving you to manage them separately) or handle them unsafely (storing them in plaintext git repos). ConfigSync treats secrets as a core feature with proper security.

Every secret is encrypted with AES before it leaves your machine. Encryption uses a master password that only you know, with per-secret salts so that identical values produce different ciphertext. The sync service stores only encrypted blobs and has no ability to decrypt them.

Secrets can be scoped to specific projects or machine tags. Your Stripe API key only appears in the project that needs it. Your work AWS credentials only sync to machines tagged as work devices. The access model is granular without being complicated.

A project in ConfigSync is a unit that ties together a repository, its secrets, and its configuration. When you add a project, ConfigSync tracks the repo URL, the.env files, and any associated secrets as a single entity.

Pull on a new machine and the project's repository is cloned, its environment variables are decrypted and placed, and its secrets are available. One tool, one push, everything synced. That is what going beyond dotfiles looks like.