statico dotfiles: a personal Zsh and Neovim kit you install with one curl

One developer's environment, packaged as a bootstrap

statico/dotfiles is a personal toolkit that began around 2001, when the author moved between many operating systems and environments, and is now used mostly on macOS and Linux. The stated purpose is not to be a general dotfiles framework but to bootstrap a working environment quickly on new hardware and virtual machines.

That framing matters when you judge it. The repository is a snapshot of one person's working environment, not a configurable product. It covers the shell, the editor, tmux, PostgreSQL and psql, tig for git, a screenrc, VS Code settings split between macOS and Linux, a Neovim plugin directory, a homebrew.txt, and a bin/ directory of helper scripts. The top-level entries also include AGENTS.md and CLAUDE.md, so the repository is written to be read and edited by coding agents as well as by a human.

What it gives you is a working baseline with the small annoyances already solved, such as making sure Unicode displays properly and that ls shows colors, plus roughly sixty Git aliases. What it does not give you is a documented set of guarantees, and the README is candid that the collection of snippets has grown by accretion over years rather than by design.

install.zsh is the entire documented install path

The installation section is three steps. The first pipes a remote file straight into Zsh, the second asks you to point your login shell at Zsh yourself with chsh or an equivalent, and the third is to restart the shell. The second and third steps are manual, which is a small but real signal about how much automation the author wants on your machine.

The remote script is a redirect to the install.zsh file in the repository, and the README gives the command as curl -sL statico.link/zsh | zsh, with the piped script being the install.zsh file from the repo.

The customization path is equally plain. You fork the repository, update install.zsh so it points at your own fork, and then change what you like. That is the whole contract: this is a template you take ownership of, not a package you subscribe to.

Machine-specific commands live in files that are never checked in. A .postinstall file is optional and is described as a place for commands such as setting your Git email globally. A .zshlocal script holds host-specific functions, including the per-host colorprompt command. .vimlocal and .gvimlocal exist for machine-specific Vim customizations, although the README says the author now mainly uses Neovim and keeps the Vim config for historical reasons. The separation between committed and uncommitted state is the cleanest idea in the repository.

The container image is the fastest way to look before you install

Before you run the installer on your own machine, the repository offers a container image. The README shows it as a one-liner, and the image starts a shell as an unprivileged demo user:

$ docker run --rm -it ghcr.io/statico/dotfiles
demouser@987552d4c629:/

The Dockerfile at the top level explains how the image is assembled. It starts from alpine, installs the toolchain with apk, creates a demo group and a demo user whose shell is /bin/zsh, copies the repository into a .dotfiles directory, and then runs install.zsh inside the image:

FROM alpine

RUN apk update && apk add git zsh bash neovim exa ripgrep fzf tzdata ncurses nodejs npm python3 py3-pip curl tree-sitter-cli
RUN addgroup demo \
      && adduser --system --shell /bin/zsh -g demo demo \
      && cp /usr/share/zoneinfo/UTC /etc/localtime

WORKDIR /home/demo
USER demo

Two details in that file are worth copying into your own fork. The image copies the whole repository into a .dotfiles directory and runs install.zsh from there, so the installer is expected to work against a checkout rather than only through the network redirect. It also installs lua-language-server headlessly through MasonInstall and tolerates failure with || true, with a comment noting a fix for an error with lua-language-server on Alpine Linux. The image then appends a cat of welcome.txt to .zshlocal and finishes with a login Zsh as the default command.

Sixty Git aliases and a prompt that varies per host

The .zshrc is described as a minimal, customized prompt plus a large set of aliases and shortcuts, and the README explicitly says there are enough tricks in it to be worth a skim. Git is the heaviest user: around sixty aliases, plus a set of short forms that cover the common flow, with st for status, gd for a diff, gl for a quick log, sci to commit everything with a message, and gap to cherry pick followed by gc to commit.

Around that are single-character aliases for the tools that appear constantly: g for git, d for docker, dc for docker-compose, k for tree, and y for yarn. There are also single-key conveniences for directory movement, with j taking a fuzzy match and changing to the most commonly used matching directory through autojump, and l and ll for long listings.

Two keybindings are worth stealing on their own. Ctrl-R opens a fuzzy history search through FZF, and Ctrl-G Ctrl-G does a quick switch between git branches thanks to fzf-git.sh. Another pair of them reshape the line rather than the filesystem: Meta-L appends 2>&1|less and runs the command so you see the output in a pager, and Meta-Q queues the current command and clears the line so you can run something else first, then paste the queued one back.

The prompt color is the one bit of per-machine state. A random color is picked at first install, and the README says each host gets a different colorprompt command in its ~/.zshlocal, with ansimodes or 256-colors.sh used to pick one. Both scripts are already in the ~/bin/ directory, which is added to the PATH.

Why Zsh, argued in five specific ways

The README answers the obvious question directly, and it is a better answer than the usual list of feature names.

Completion is the first reason. The example is typing /u/l/b/x and pressing Tab, which completes to /usr/local/bin/x, and the claim is that this is easier in Zsh than in Bash. Second, Ctrl-W can be remapped to delete back to the previous word or slash, so /usr/local/bin becomes /usr/ when the key is pressed.

Third, completion can be made visible: the setup shows five red dots while a completion is running, which the author says matters when completing files from remote SSH servers, where latency makes an invisible completion look like a hang. Fourth is globbing, where the double-star recursive operator and qualifiers such as (.) and (/) are used in practice, for instance a recursive glob that removes every .DS_Store file under a directory tree.

The fifth reason is history, stated without irony: the author started using Zsh in 2002 when it was edgy, and it stuck. This is the kind of section that usually gets a paragraph of marketing, and the value here is that the reasons are testable. Try the /u/l/b/x completion and the red-dot feedback on a machine where you already know what the other shell does, and keep the setup only if the difference is visible to you.

The Neovim config leads, the Vim config is kept as an archive

The primary editor configuration now lives in .config/nvim/init.lua, described as the author's main editor setup, and the repository also carries .zsh_plugins/ for shell plugin management and a .config/ directory for per-application configuration.

Alongside that sit a .vim/ directory with the old vimrc, kept for historical reasons and because the author's writing about Vim drew interest. The README also mentions a .nethackrc, a .psqlrc for PostgreSQL, a .tigrc for tig, a .screenrc, a .tmux.conf, a .toprc, a .curlrc with a .curl-format, and .bash_profile for shells that still start with Bash. VS Code is covered too, but as two separate pairs of files, .vscode-mac.settings.json and .vscode-linux.settings.json, with matching keybinding and snippet files, because the keymap differs between operating systems.

The layers are the point. Editor, shell, terminal multiplexer, database client, and version control client each get a config, and the machine-specific layer sits on top as .zshlocal, .postinstall, .vimlocal, and .gvimlocal. What the repository does not offer is a way to choose which of those layers you want. There is no documented subset, no per-tool opt-in, and no listing of which external commands the aliases assume. The README mentions autojump, FZF, fzf-git.sh, ripgrep, exa, tree, yarn, docker and docker-compose as things the shortcuts depend on, but it does not present a single list of everything you must install before the shortcuts work.

What you inherit when you fork: no licence, one author's taste

The first thing to check before running the installer on a work machine is the licence, and here there is a gap. No licence is declared for the project, and there is no LICENSE file among the top-level entries, which hold .gitconfig.base, homebrew.txt, install.zsh, welcome.txt, bin/, and the configuration directories described above. What you can legally do with the configuration is therefore not answered by the repository itself. Treat it as code you can read and adapt for your own machines, and ask a lawyer if you intend to redistribute it.

The second check is content. A .gitconfig.base, a homebrew.txt, and a bin/ directory of scripts all carry the original author's assumptions about tools and packages. The README mentions that the author uses macOS, Windows, and various Linux distributions, but it documents no Windows installation steps, so the Windows part of the claim is not actionable from what is written here. The README also says the author primarily uses Neovim now while keeping the Vim configuration for historical reasons, which is a fair signal about how much of this repository is current and how much is archive.

For a comparison point on structure, the README points at Oh My Zsh as a popular way of customizing Zsh, while noting it does not cover all dotfiles or Neovim, and at jbalogh/dotfiles, which this repository was modeled after. Oh My Zsh works as a plugin framework layered on top of Zsh, whereas this repository takes the opposite approach and manages whole configuration files directly, including the editor and the terminal multiplexer, so you swap the file rather than adding a plugin line.

Editorial conclusion

Adopt this repository if you want a working, opinionated macOS and Linux shell quickly, and if you are comfortable forking it and making it yours, because there is no declared licence and the defaults encode one person's taste. Do not adopt it expecting a team standard, a documented installer contract, or a package-manager install path, since the only documented route is a piped shell script and the binary dependencies it relies on are listed as snippets rather than installed by a manifest. Before running install.zsh on a work machine, read the file, check the top-level entries such as .gitconfig.base and .zshrc for anything specific to the original author's machines, and confirm which external tools such as autojump, fzf and ripgrep you already have on the PATH.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. statico/dotfiles on GitHub