Replacing Ansible Playbooks with ConfigSync for Dev Environment Setup
Ansible is a powerful infrastructure tool. But for managing your personal dev environment, it's like using a forklift to move a chair.
When Ansible Makes Sense
Ansible is brilliant at what it was built for: provisioning servers, configuring infrastructure, and managing fleets of machines. If you are deploying to 50 servers, Ansible's inventory system, idempotent modules, and role-based structure are exactly right.
But somewhere along the way, developers started using Ansible for something it was never designed for: managing personal dotfiles and dev environments. The logic made sense — "I already know Ansible, so I will write a playbook for my laptop." And it works. But the overhead is enormous.
When Ansible Is Overkill
Here is what a typical "dotfile playbook" looks like:
---
- hosts: localhost
connection: local
tasks:
- name: Copy gitconfig
copy:
src: files/gitconfig
dest: ~/.gitconfig
mode: '0644'
- name: Copy SSH config
copy:
src: files/ssh_config
dest: ~/.ssh/config
mode: '0600'
- name: Install packages
homebrew:
name: "{{ item }}"
state: present
loop:
- git
- neovim
- tmux
- ripgrep
- name: Template zshrc
template:
src: templates/zshrc.j2
dest: ~/.zshrc
That is 25 lines of YAML to copy three files and install four packages. And you need Ansible installed, an inventory file (even if it is just localhost), and familiarity with Ansible's module system. For a personal laptop, this is unnecessary complexity.
localhost — you are using an infrastructure tool for a personal configuration problem.Step-by-Step Migration
1. Identify dotfile copy/template tasks
Search your playbooks for copy: and template: tasks that target your home directory. These are the files ConfigSync should manage.
# Add modules for standard tools
configsync add module ssh
configsync add module git
configsync add module zsh
# Add individual configs that don't map to modules
configsync add config ~/.config/starship.toml
configsync add config ~/.tmux.conf
2. Replace package install tasks with configsync scan
Instead of maintaining a static list of packages in YAML, let ConfigSync capture what is actually installed:
# Scan captures packages from Homebrew, apt, npm, pip, etc.
configsync scan
# On a new machine, restore packages
configsync pull --install
This is always up to date because it scans your actual installed packages, not a list you have to manually maintain.
3. Convert Ansible templates to ConfigSync templates
If you use Ansible's Jinja2 templates for platform-specific configs, ConfigSync has its own template system:
| Ansible (Jinja2) | ConfigSync Template | Description |
|---|---|---|
| {{ ansible_os_family }} | {{platform}} | Operating system (macos, linux, windows) |
| {{ ansible_hostname }} | {{hostname}} | Machine hostname |
| {{ ansible_user_id }} | {{username}} | Current username |
| {{ ansible_distribution }} | {{distro}} | Linux distribution name |
| {% if ansible_os_family == "Darwin" %} | {{#if macos}} | Platform conditional blocks |
{{#if macos}}
export PATH="/opt/homebrew/bin:$PATH"
{{/if}}
{{#if linux}}
export PATH="$HOME/.local/bin:$PATH"
{{/if}}
export HOSTNAME="{{hostname}}"
4. Migrate Ansible Vault secrets
If you use Ansible Vault to encrypt sensitive variables, ConfigSync handles this more simply:
# Ansible Vault: encrypt a file, decrypt with password at runtime
# ansible-vault encrypt secrets.yml
# ConfigSync: secrets are encrypted by default
configsync secret set GITHUB_TOKEN ghp_xxxxxxxxxxxx
configsync secret set AWS_SECRET_KEY AKIAXXXXXXXXXX
No separate vault command, no password prompts during runs. Secrets are encrypted with AES-256-GCM using your master password, automatically.
5. Move one-time setup commands to bootstrap.sh
Ansible tasks that run shell commands (installing Xcode tools, setting macOS defaults) can go in a bootstrap script:
#!/bin/bash
xcode-select --install 2>/dev/null
defaults write NSGlobalDomain AppleShowAllExtensions -bool true
defaults write com.apple.dock autohide -bool true
6. Push everything
configsync push
Keep Ansible Where It Belongs
This is not about replacing Ansible entirely. It is about using the right tool for the right job:
| Use Case | Right Tool |
|---|---|
| Server provisioning | Ansible |
| Infrastructure automation | Ansible |
| Fleet configuration management | Ansible |
| CI/CD pipeline setup | Ansible |
| Personal dotfile sync | ConfigSync |
| Dev environment setup | ConfigSync |
| Secret management for dev | ConfigSync |
| Package tracking across machines | ConfigSync |
If you run ansible-playbook against localhost to set up your laptop, you can replace that entire workflow with three commands: configsync pull, configsync pull --install, and bash ~/.configsync/bootstrap.sh. No inventory files. No YAML indentation debugging. No waiting for Ansible to gather facts about a machine you are sitting in front of.
Ready to try ConfigSync?
Sync your entire dev environment across machines in minutes. Free forever for up to 3 devices.