loadout

Configuration in, commands out

~/.config/loadout/config.yaml

paths:
  project_root: ~/Projects

identities:
  - id: work
    git_user: Example User
    email: user@work.example
    ssh_key: ~/.ssh/id_work

hosts:
  - alias: edge
    hostname: edge.example.internal
    user: deploy
    upload_path: /srv/app
    shortcut: true

workspaces:
  - name: docs
    path: ~/Projects/docs/docs.code-workspace
    tmux_session: docs

What your shell gets

p docs: Change to ~/Projects/docs
s work: Switch git author and SSH key together
msh -m edge: SSH to edge.example.internal as deploy
mpush edge ./build.tar: Copy it to /srv/app on that host

Those four ship with loadout and read your configuration. These two did not exist until the hosts and workspaces entries were written:

edge: ssh edge — the shortcut the host asked for
docs: Open the workspace, attach to its tmux session

Six of 136 aliases and 14 functions. The rest — with what each one needs, and which platforms it runs on — is in the alias catalog, or under loadout catalog once it is installed.

Three stages, one file

Curate

136 aliases and 14 shell functions, chosen and kept rather than accumulated. Every entry declares what it needs, so one that points at a tool you never installed is reported instead of failing at the moment you use it.

Configure

Your git identity, project root, workspaces, hosts and credential names live in one YAML file. That file is the only thing that is yours to maintain, and it is data, not a fork of someone's dotfiles.

Load

loadout apply renders the two together into a single file. Your shell sources it at startup. Nothing runs when you open a terminal — the file is static text, regenerated only when you ask.

Why it generates shell

An alias cannot be a program. gpush and .. are shell state, not executables, so no binary can provide them. loadout therefore generates shell rather than intercepting commands, and the binary stays out of the hot path.

Two shipped functions, p and activate, change the calling shell's directory and environment. They stay real shell functions because a child process cannot cd for its parent. Everything else could be a subcommand, and is not, because the generator already exists.

What you get

Two shells, two platforms: zsh and bash, Linux and macOS. The generated shell is pinned by golden files for all four combinations, so a change to the catalog is reviewed as the diff that will land in your shell.
Availability, not hope: loadout doctor reports every alias whose tool is missing, every path that has gone, and every command that needs configuration it does not have.
Secrets in the keychain: Credentials live in Keychain, libsecret or pass — never in a file loadout writes. Config records only which entries exist and which is active.
Verified binaries: Third-party executables are declared, not committed: fetched per platform over HTTPS on every hop, checksum-verified before install, and appended to PATH so they cannot shadow a system tool.
One config, many machines: sync keeps config.yaml in a git repo you own, refusing to commit anything credential-shaped. local.yaml holds what must not travel.
A local interface: loadout ui serves a page on 127.0.0.1 for as long as the command runs. Browse the catalog with live availability, toggle packs, and diff the generated shell before anything is written.

Install

curl -fsSL https://loadoutsh.github.io/site/install.sh | sh

The script verifies the published checksum before putting anything on your PATH, and installs by rename so an interrupted run cannot leave a half-written executable behind. Homebrew and go install are documented in Install.

Documentation →

Every command, the whole configuration schema, all 136 aliases and 14 functions, the security model behind the local interface, and how the generated shell stays identical in zsh and bash.