Testing My Dotfiles in Disposable Containers

In the previous article, we got started with dotfile management and zsh using chezmoi. Now I’d like to experiment — try out new configs, install tools, tweak settings — but without ruining my host’s environment in the process.

A safe space to try things out that also plays perfectly into my later dev container goal: one-time containers. They let me practice spinning up my environment from basically nothing, and they allow me to experiment with apps and configurations without any effect on my host machine. If something breaks, I just exit the container and it’s gone.

So let’s get started.

Prerequisites: A Container Runtime

#

I’ll assume you already have a container runtime installed on your machine. Whether that’s Podman, Docker, containerd, or one of their desktop companions — I won’t cover the installation here because of the many options and licensing differences between them.

I’ll be using Podman throughout this article, but you can follow along with Docker just as well. Simply replace podman with docker in every command.

Spinning Up a Throwaway Container

#

To start a container for my dotfiles experiments, I use a simple, minimal Linux distribution. Here’s the command:

podman run -it --rm debian:bookworm-slim bash

Let’s break down what each part does:

• -i keeps STDIN open, even if not attached
• -t allocates a pseudo-TTY
• -it is just the shorthand for combining both options
• --rm tells the container runtime to delete the container once it exits
• debian:bookworm-slim is the image to create the container from — a minimal Debian Bookworm base image
• bash is the command to execute inside the newly created container

When you run this, a fresh Debian container spins up and drops you straight into a root shell:

marcus@devvm ~ % podman run -it --rm debian:bookworm-slim bash
root@a86b9a4ff5fc:/#

Feel free to explore the container and its contents — try ls -al / or ls -al /etc to see what’s included in this minimal image.

Installing the Bare Minimum

#

What’s the bare minimum we need inside this container? The tools for chezmoi to work: git to access our dotfiles repo, curl to install chezmoi, and of course zsh — because we don’t want to stay in bash.

root@a86b9a4ff5fc:/# apt update -y && apt upgrade -y && apt install curl git zsh -y

Installing chezmoi and Pulling Our Dotfiles

#

With the tools in place, let’s install chezmoi and pull the dotfiles repo in one step. The chezmoi install script supports this — we just pass init --apply along with our GitHub username:

root@a86b9a4ff5fc:/# sh -c "$(curl -fsLS get.chezmoi.io)" -- init --apply knuth-info
info found chezmoi version 2.69.4 for latest/linux/amd64
info found glibc version 2.36
info installed bin/chezmoi
Cloning into '/root/.local/share/chezmoi'...
remote: Enumerating objects: 12, done.
remote: Counting objects: 100% (12/12), done.
remote: Compressing objects: 100% (9/9), done.
remote: Total 12 (delta 1), reused 11 (delta 0), pack-reused 0 (from 0)
Receiving objects: 100% (12/12), done.
Resolving deltas: 100% (1/1), done.
root@a86b9a4ff5fc:/#

Now we should be able to switch to zsh and call chezmoi from the ~/bin directory — thanks to our .zshenv which should have been applied by chezmoi:

root@a86b9a4ff5fc:/# zsh
root@a86b9a4ff5fc / # chezmoi --version
chezmoi version v2.69.4, commit c4c669c9f2f329233a85802014d26fba3c58a4a4, built at 2026-02-11T08:59:37Z, built by goreleaser
root@a86b9a4ff5fc / #

It works! You can also see the subtle change in the prompt — the colon after the hostname is gone, which tells us our zsh configuration has kicked in.

Configuring Git for Pushing Changes

#

Just like on any new machine, we need to configure the git settings inside the chezmoi directory so we can push changes back to our repo. This is the same step we covered in the previous article:

chezmoi cd
git config user.name "Marcus Knuth"
git config user.email "github@knuth.info"
git config core.sshCommand "ssh -i ~/.ssh/my_new_github_accounts_ssh_key"
git remote set-url origin git@github.com:knuth-info/dotfiles.git

Adding the SSH Key

#

One thing that’s missing in the container is the SSH key itself. Since this is a fresh, throwaway environment, we need to create it manually. We set up the .ssh directory with the correct permissions and paste in our private key:

mkdir -p ~/.ssh && chmod 700 ~/.ssh
cat > ~/.ssh/my_new_github_accounts_ssh_key << 'EOF'
-----BEGIN OPENSSH PRIVATE KEY-----
<contents-of-the-private-key>
-----END OPENSSH PRIVATE KEY-----
EOF
chmod 600 ~/.ssh/my_new_github_accounts_ssh_key

Hint: You can keep this snippet in a secure location like Bitwarden for now. We’ll find a better way to handle this in a future article.

Experimenting and Pushing Changes

#

And that’s it! You now have a fully functional, disposable environment to experiment with new configs, tools, and settings. Anything you change can be pushed back to your dotfiles repo.

To add a new dotfile:

chezmoi add ~/.mynewdotfile
chezmoi cd
git add -A && git commit -m "add .mynewdotfile" && git push

Or to edit an existing one:

chezmoi edit ~/.zshrc
chezmoi apply
chezmoi cd
git add -A && git commit -m "update zshrc" && git push

When you’re done, just type exit twice — once for zsh, once for the container — and everything disappears. Your host stays clean, your changes live in the repo, and the next time you need a fresh environment, you’re one podman run away.

The one downside? That manual SSH key step is a bit tedious. Every new container means copying that key again. In the next article, we’ll fix that.