Sync across machines

Configuration is text, so it syncs through git. loadout drives a repository you own rather than hosting anything.

loadout sync init git@github.com:you/loadout-config.git
loadout sync status     # exactly which files would leave this machine
loadout sync push
loadout sync pull

It shells out to git, so your existing SSH keys and credential helpers work unchanged. There is no service and no account.

What travels

Only config.yaml. Nothing else is tracked.

File	Synced	Why
config.yaml	Yes	The thing you maintain
local.yaml	Never	Machine-specific by definition
init.zsh / init.bash	No	Generated per machine; would conflict on every pull
Keychain values	No	A keychain is deliberately non-exportable

loadout sync status prints the list before anything leaves, so you can check rather than trust.

Use a private repository

The configuration holds no secrets — that is enforced — but it names your hosts, your paths, your identities and your email addresses. That is a map of your infrastructure even without a single credential in it.

The scanner

A scan runs before the commit, not before the push.

That ordering is the entire point. Once a credential is committed, removing it needs a history rewrite, and the value must be treated as leaked regardless. Scanning before the commit means a token pasted into your configuration never enters the history at all.

loadout scan     # check without touching git

It matches high-signal shapes rather than guessing at entropy: ghp_, npm_, AKIA, JWTs, PEM blocks, and literal password: fields. Entropy heuristics were rejected because they fire constantly on hostnames, paths and base64-looking identifiers, and a check that cries wolf gets turned off.

password: cred:<name> is the correct form for a host password and is explicitly allowed. A literal there is refused.

A new machine

loadout sync init git@github.com:you/loadout-config.git
loadout sync pull
loadout apply
loadout doctor

doctor is the interesting step. Your configuration will reference things this machine does not have — a project root that is elsewhere, tools you have not installed yet — and it tells you which, rather than generating something broken.

Credentials do not arrive with the configuration. Re-enter them:

loadout cred list                  # what is declared but has no value here
loadout cred set npm_token work

Machine-specific values

When a value genuinely differs per machine rather than merely being absent, put it in local.yaml, which overlays config.yaml and never syncs:

~/.config/loadout/local.yaml

paths:
  project_root: /srv/work

Most differences do not need this. An entry whose tool or path is missing degrades to a doctor finding on its own, which is why there is no profile system to configure.

Credentials across machines

Three approaches, and the choice is yours:

Approach	Trade
Re-enter per machine	The default. Safe, no dependency, mildly annoying on a new box.
A shared secret backend	The configuration declares the credential; the value resolves after one authentication.
An encrypted file (age, sops)	Travels in the configuration repository, and works headless where no keychain daemon exists.

Re-entry is what ships. The keychain being non-exportable is a feature, and working around it should be a decision you make deliberately rather than a default.