What Rivet excludes

A tool that reads your home directory owes you an exact answer to “what do you take?”. This page is that answer.

Rivet’s boundary is enforced in two independent layers: a name-based exclusion list applied while collecting, and a content scanner that looks for private-key and token signatures before anything reaches Git staging. Both run on every snapshot, including on output captured from plugin hooks.

Never captured

Category	Why
SSH private keys, GnuPG keyrings	Long-lived credentials. Losing them is unrecoverable; leaking them is catastrophic. Move a machine’s keys deliberately, by hand.
Browser profiles, cookies, session state	Contains live session tokens and saved passwords, is enormous, and rarely survives a version change intact.
Caches, Flatpak application data	Regenerable by definition. Capturing it inflates every snapshot for no restore value.
System-wide configuration under /etc	Outside the user’s ownership, distro-specific, and the fastest way to make a restore unbootable.

There is no flag that overrides these categories wholesale. That is deliberate: a safety boundary you can disable with a flag is a safety boundary that gets disabled.

Captured, but only once you approve it

• Explicit native packages — Pacman, APT, DNF, Zypper, XBPS
• Foreign and sandboxed sources — AUR, nix profile, Flatpak, Snap (including classic mode), and portable .AppImage files in conventional home locations
• Curated configuration groups — KDE Plasma, GNOME, Cinnamon, Xfce, Hyprland, Sway, niri, i3; Bash, Zsh, Fish, Tmux, Git, Vim, Neovim; Kitty; VS Code; fonts and themes; user scripts
• dconf settings — GNOME and Cinnamon replay their settings through an explicit, reviewable hook command, for state that lives outside any file
• Paths you name yourself — via rivet track, with include/exclude globs

Nothing in that list is captured by default without passing through rivet checklist --select first.

The escape hatches, and their limits

Two mechanisms let you go past the defaults. Both are explicit, per-path, and narrow.

rivet track --allow-excluded-names

Relaxes the name-based exclusions (cache, secrets, credentials, …) for one tracked path only. The content secret scanner still applies — this cannot be used to smuggle a private key into a snapshot.

The encrypted vault

To carry a secret rather than merely exclude it, declare it explicitly:

rivet vault init --repo ~/rivet-snapshots
rivet vault add --repo ~/rivet-snapshots ~/.ssh/config

The file is sealed as age ciphertext into every snapshot and unsealed on restore. The private identity lives only at ~/.config/rivet/identity.age and never enters a snapshot or a backend. See Secrets vault for the full model, threat model, and key-loss guidance.

Note the distinction: ~/.ssh/config is a routing file you may well want to carry. ~/.ssh/id_ed25519 is a key, and Rivet’s answer for keys is still no.

What to do anyway

Review the diff before your first push:

cd ~/rivet-snapshots
git status
git show --stat

Two enforcement layers are better than one, and neither is a substitute for looking at what you are about to publish.