GitHub backs up your code. Pitara backs up your development environment.
Set up a new laptop in minutes instead of a lost day. Pitara captures the language runtimes and global CLI tools on one machine and reinstalls them on another. It captures Node, Go, Java, Bun, Deno, Python, and Rust runtimes, plus global packages from npm, pnpm, Yarn, Bun, Deno, pipx, and Cargo.
- No server, no database — backups live in your own GitHub repo
- No secrets stored — snapshots hold only tool names and versions
- Your token never leaves your machine (
~/.pitara)- Open source — audit every line yourself
pitara login # one-time: sign in with GitHub
pitara backup # save this machine
pitara restore # rebuild it on a new machineThat's the whole flow. Your backups land in a private pitara-snapshots repo
Pitara creates in your account.
Switching laptops or reinstalling an OS means rebuilding a setup scattered across runtimes, package managers, and global CLIs. Existing tools each cover a slice — dotfiles for config, Settings Sync for editors, Brewfiles for Homebrew, Nix for full reproducibility (with a steep learning curve). Pitara takes the simple middle: back up your installation state and restore it with one command.
brew bundle is great — if your whole world is Homebrew on a Mac. But a real dev
environment is spread across many package managers: npm, pnpm, Yarn, Bun, pipx,
Cargo, plus version managers like nvm, pyenv, and rustup. brew bundle only knows
about Homebrew formulae. Pitara captures all of them and restores each tool
through the same manager that installed it (an npm global comes back via npm, a
pipx tool via pipx), on any OS, synced through your own GitHub repo.
npm (works with npm, pnpm, and bun — all use the npm registry):
npm install -g pitaraFrom source (requires Go 1.23+):
go install github.com/sailingsam/pitara/cmd/pitara@latestPrebuilt binaries for macOS, Linux, and Windows are attached to every release.
pitara login # one-time: sign in with GitHub
pitara backup # save this machine
pitara restore # rebuild this setup on a new machine
pitara snapshots list # see your saved machines
pitara --version # print the installed Pitara versionBacking up more than one machine? Add --label <name> to backup and restore
(e.g. --label work-laptop). With a single machine you never need it.
pitara scan prints the snapshot Pitara would create — handy to see exactly
what gets captured, or to save it as a file and move it yourself without an account:
pitara scan # print the snapshot (JSON) to the screen
pitara scan -o snapshot.json # save it to a file instead
pitara restore --from snapshot.json # restore from that file (add --dry-run to preview)Restore installs in dependency order (Node before npm globals, and so on), skips anything whose prerequisite failed, and prints a summary:
Pitara Restore Report
───────────────────────
Snapshot: work-laptop (linux, amd64)
Created: 2026-06-10 14:00 UTC
Runtimes
✓ Node.js 22.15.0
Global Packages (npm)
✓ npm: typescript@5.4.5
✓ npm: tsx@4.7.0
Restore completed.
A snapshot is a small, versioned JSON document. Each package manager's globals are kept in separate lists — Pitara never guesses which manager installed a tool, and on restore reinstalls each via its original manager.
{
"schemaVersion": 1,
"createdAt": "2026-06-10T14:00:00Z",
"machine": { "label": "work-laptop", "os": "linux", "arch": "amd64" },
"languages": {
"node": { "version": "22.15.0", "manager": "nvm" }
},
"packages": {
"npm": {
"globals": [
{ "name": "typescript", "version": "5.4.5" },
{ "name": "tsx", "version": "4.7.0" }
]
}
}
}Your snapshots live in a private pitara-snapshots repo in your own GitHub
account (created on first backup). The CLI talks directly to the GitHub API — there
is no Pitara server and no database — and your token stays on your machine
(~/.pitara, 0600). Every backup is a commit, so your history is just the git log.
Login uses GitHub's device flow (like the gh CLI) and requests the repo scope,
which is needed to create the private repo and commit snapshots. Because Pitara is
open source and runs no server, you can audit exactly what it does — and revoke
access anytime at github.com/settings/applications.
Pitara is built around a small plugin abstraction. Each tool category implements one interface for both directions:
type Plugin interface {
Name() string
Scan(ctx context.Context) (ScanResult, error)
Restore(ctx context.Context, data json.RawMessage, opts RestoreOptions) (RestoreResult, error)
Dependencies() []string // plugins that must restore first
SupportedOS() []OS // platforms this plugin can restore on
}Adding a new tool is: implement Plugin, register it. The registry topologically
sorts plugins by Dependencies() so prerequisites install first.
cmd/pitara/ CLI entrypoint
internal/
cli/ Cobra commands (scan, restore, login, backup, ...)
discovery/ Scan orchestrator
restore/ Restore planner + executor
snapshot/ Schema, validation, builder
report/ Restore report formatter
plugins/ Plugin interface + registry (node, go, java, bun, deno,
python, rust, npm, pnpm, yarn, bun/deno/pipx/cargo globals)
auth/ Local session storage (~/.pitara)
github/ GitHub device-login + REST client
executil/ Command helpers
The CLI depends only on Cobra; the GitHub client is pure standard library, so the installed binary stays small.
| Phase | Scope | Status |
|---|---|---|
| 1 | CLI foundation: scan, local restore, Node + npm plugins |
✅ |
| 2 | Go, Java, Bun, Deno, Python, Rust runtimes; pnpm/yarn/bun/deno/pipx/cargo globals; per-OS install paths | ✅ |
| 3 | Cloud: GitHub-backed login, backup, snapshots list, restore |
✅ |
| 4 | Cross-OS warnings, version-manager detection, retry/recovery | ⏳ |
Contributions are welcome. Good first additions are new plugins — pick a tool,
implement the Plugin interface, and register it. Please run go build ./... and
go test ./... before opening a PR.
MIT © sailingsam