The Sticky Defaults Strategy: Designing Tiny Personal Configs That Make Every New Machine Feel Like Home

There’s a special kind of friction that comes with a fresh machine. It’s fast and clean, but also unfamiliar. Your shell feels wrong. Your editor is missing half its magic. Your favorite tools aren’t installed. You can work, but everything is just… off.

The Sticky Defaults Strategy is about eliminating that friction. You design a small, opinionated set of personal defaults—your tiny personal configs—and make them portable, reproducible, and secure. Any time you touch a new laptop, VM, container, or remote server, you can make it feel like home in minutes.

In this post, we’ll walk through how to:

• Use a dotfiles manager like Chezmoi to sync your config across machines
• Version your dotfiles with Git to evolve them safely
• Bootstrap any fresh environment with a new-machine setup script
• Structure your repo and branching strategy so it stays maintainable
• Treat security as a first-class concern
• Focus on a handful of sticky, high-impact tweaks that give you instant familiarity

Why “Sticky Defaults” Beat “Perfect Setups”

Many developers try to craft the perfect setup for one machine—tons of plugins, custom tools, and intricate tweaks.

The problem: perfect doesn’t travel well.

• You get a new laptop: half your customizations are missing.
• You SSH into a server: nothing looks like your local environment.
• You use a cloud dev environment: all your muscle memory breaks.

Sticky defaults are different. They’re small, portable configuration layers that:

• Are easy to apply anywhere
• Survive hardware changes and job changes
• Give you the same comfort baseline on local, remote, and cloud machines

Think of them as the carry-on bag of your computing life: minimal, essential, always with you.

Step 1: Put Your Dotfiles Under Version Control

The foundation of sticky defaults is simple: store your config files in Git.

Typical dotfiles include:

• Shell: ~/.bashrc, ~/.zshrc, ~/.profile, ~/.bash_aliases
• Editor: ~/.vimrc, ~/.config/nvim/init.vim, ~/.config/helix/config.toml
• Git: ~/.gitconfig, ~/.gitignore_global
• Tools: ~/.tmux.conf, ~/.config/starship.toml, ~/.config/fd/, ~/.config/ripgrep/

Create a dedicated repo (often just named dotfiles):

mkdir -p ~/dotfiles
cd ~/dotfiles
git init

Then start importing configs deliberately, not blindly:

cp ~/.zshrc .
cp ~/.gitconfig .
cp ~/.tmux.conf .

Commit early, commit often:

git add .
git commit -m "Initial personal defaults"

Why Git matters:

• History: See when and why you changed a setting.
• Review: Use diffs to understand side effects before syncing changes.
• Safety: Revert experiments that don’t pan out.

This alone already makes your setup safer and more portable.

Step 2: Use Chezmoi to Make Configs “Stick” Everywhere

Manually symlinking dotfiles or copying them between machines gets messy. A dotfiles manager like Chezmoi solves that.

Chezmoi sits between your Git repo and your home directory:

• Templates and plaintext live in the Chezmoi-managed repo
• Chezmoi applies them to your home directory on each machine
• You can customize behavior per OS, host, or environment

Basic Chezmoi Setup

On a machine where you have your dotfiles:

# Install chezmoi (example for macOS using Homebrew)
brew install chezmoi

# Initialize from an existing remote repo
chezmoi init git@github.com:yourname/dotfiles.git

# Apply configs to home directory
chezmoi apply

To add a file to Chezmoi management:

chezmoi add ~/.zshrc
chezmoi add ~/.gitconfig
chezmoi add ~/.tmux.conf
chezmoi cd  # jump into the chezmoi-managed repo

Now your source of truth is:

• Chezmoi-managed files (often in ~/.local/share/chezmoi)
• Backed by a Git repo (local and remote, e.g., GitHub/GitLab)

Whenever you get to a new machine:

sh -c "$(curl -fsLS get.chezmoi.io)" -- init --apply yourname

In one command, your dotfiles are pulled, rendered, and applied.

Step 3: Write a New-Machine Setup Script

Dotfiles alone don’t install tools. For that, you want a bootstrap script that:

1. Installs package managers (Homebrew, apt, pacman, etc.)
2. Installs your core tools (shell, editor, terminal extras)
3. Installs Chezmoi
4. Clones and applies your dotfiles

Example (simplified) bootstrap.sh:

#!/usr/bin/env bash
set -euo pipefail

# 1. Package manager (example: macOS)
if ! command -v brew &>/dev/null; then
  /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
fi

# 2. Core tools
brew install \
  git \
  zsh \
  tmux \
  neovim \
  fzf \
  ripgrep \
  fd

# 3. Chezmoi
brew install chezmoi

# 4. Dotfiles
chezmoi init git@github.com:yourname/dotfiles.git
chezmoi apply

Store this script in Git (maybe in a setup/ or bootstrap/ directory) so you can:

• Update it over time
• Keep it in sync with your dotfiles
• Review its history and changes

On any new machine, your steps become:

1. Install Git (if needed)
2. Fetch bootstrap.sh
3. Run it once

Minutes later, you’re in a familiar environment.

Step 4: Structure and Branch Your Dotfiles Repo for Growth

Your dotfiles repo will grow. Without structure, it becomes a junk drawer. A few guidelines:

Suggested Layout (Chezmoi-style)

Chezmoi usually keeps a structure like:

~/.local/share/chezmoi
├── dot_gitconfig
├── dot_zshrc
├── dot_tmux.conf
├── private_dot_ssh
│   └── config.tmpl
└── run_once_install-fzf.sh.tmpl

General patterns:

• dot_foo → becomes ~/.foo
• private_ → for files that should not be checked in unencrypted
• run_once_ → scripts Chezmoi runs once per machine
• *.tmpl → template files (per-OS or per-host customization)

Git Branching & Workflow

You don’t need a complex GitFlow. A lightweight approach works well:

• main: Stable, working defaults
• experiment/* branches: Try new tools or major refactors

Workflow idea:

1. Create a feature branch for config experiments
2. Use it for a few days on one machine
3. Tweak until it feels right
4. Merge into main when stable

This avoids shipping half-baked ideas to every machine immediately.

Step 5: Make Security a First-Class Concern

Dotfiles are often public. Your secrets should never be.

Common pitfalls:

• API keys in ~/.zshrc
• Tokens in ~/.gitconfig
• Private SSH options in ~/.ssh/config

Use these patterns instead:

1. Environment variables from secure stores

   • Use a tool like pass, 1Password CLI, gopass, or bitwarden-cli.
   • Load sensitive values at shell startup from a non-checked-in file.

2. Chezmoi secret integration
   Chezmoi can pull secrets from secret managers or use encryption (e.g., age, GPG).
   Example: private_dot_ssh/config.tmpl that references secrets managed elsewhere.

3. Ignore sensitive files
   Add them to .gitignore in your Chezmoi repo:

   private_dot_env*
   private_dot_ssh/id_*

4. Public vs. private repos

   • Keep the bulk of your dotfiles public (harmless defaults, aliases, tools).
   • Put truly sensitive config or machine-specific overrides into a separate private repo or encrypted Chezmoi secrets.

By default, assume anything in your Git-hosted dotfiles repo could become public one day.

Step 6: Design for Portability and Reproducibility

Aim for a setup that works on:

• Your laptop (macOS, Linux, or Windows WSL)
• Remote servers and VMs (often Linux)
• Cloud dev environments (Codespaces, Gitpod, custom containers)

A few practices help:

• Use feature detection: In your shell configs, check if a tool exists before configuring it:

  if command -v fzf &>/dev/null; then
    [ -f ~/.fzf.zsh ] && source ~/.fzf.zsh
  fi

• Template by OS: With Chezmoi templates, you can branch config by platform, e.g.:

  {{- if eq .chezmoi.os "darwin" -}}
  export PATH="/opt/homebrew/bin:$PATH"
  {{- else if eq .chezmoi.os "linux" -}}
  export PATH="/usr/local/bin:$PATH"
  {{- end -}}

• Keep assumptions minimal: Avoid hardcoding paths that only exist on one machine. Prefer environment variables and detection.

The goal: one repo, many environments, with small conditional tweaks where necessary.

Step 7: Focus on Small, High-Impact Tweaks

You don’t need hundreds of lines of configuration to feel at home. Focus your sticky defaults on a few high-leverage areas.

Shell

• Prompt: a consistent prompt (e.g., Starship) across machines.
• Aliases: gs for git status, ll for ls -alF, etc.
• History: shared or tuned history behavior (e.g., ignoring duplicates, long history size).

Editor

• Cursor movement and keybindings that match your habits.
• Indentation and formatting defaults.
• A minimal plugin set that enables your core workflow.

Tooling

• Core CLIs you reach for constantly (rg, fd, jq, fzf).
• Git config: name, email, useful aliases (co, br, st).
• Tmux or terminal multiplexer configuration with your standard keybindings.

Ask: If this were missing, would this machine feel wrong?
If yes, that’s a candidate for your sticky defaults. If not, consider leaving it out or making it optional.

Conclusion: Make Every Machine Feel Like Yours

The Sticky Defaults Strategy isn’t about building an elaborate, fragile setup. It’s about creating a small, resilient layer of personal comfort you can apply anywhere.

To recap:

• Put your dotfiles in Git so you can evolve them safely.
• Use Chezmoi to manage and apply configs across machines.
• Bootstrap new machines with a single setup script.
• Structure your repo and branches to stay maintainable as it grows.
• Separate secrets from configs and use secure storage or encryption.
• Design for portability, with OS-aware templates and minimal assumptions.
• Focus on tiny, high-impact tweaks that instantly feel like home.

Over time, these sticky defaults become one of your most powerful productivity tools. No matter where you log in—from a new laptop to a random cloud instance—you’ll be greeted by an environment that feels familiar, fast, and truly yours.