purple: a terminal SSH manager that syncs ~/.ssh/config with 18 cloud providers

The problem purple solves is config drift, not SSH itself

The README is explicit that the author's SSH config was never the problem: aliases were tidy, ProxyJump chains worked, hosts were organized by provider. The friction sat around the config. Checking a container meant `ssh host docker ps`. Copying a file meant remembering scp flags. Running one command on ten hosts meant a shell loop or booting Ansible for a one-liner. Provisioning a VM on Hetzner meant opening a console, copying the IP, editing config, saving.

That is the target audience: engineers who already live in a terminal, manage more than a handful of hosts, and treat ~/.ssh/config as the source of truth for how to reach them. purple does not replace ssh. It sits on top of the file ssh already reads. The claim in the README is that a new machine lands in ~/.ssh/config the moment it boots, IPs follow instances as they move, and decommissioned hosts grey out rather than linger as dead entries.

The scope is deliberately wide: cloud sync, a host list with a detail panel, fuzzy jump, fleet-wide container management, tunnel monitoring, snippets, visual file transfer, key push, Vault SSH certificates and an MCP server for AI agents. Whether that breadth is a strength depends on whether you want one binary to own all of it. Someone who only wants a prettier host list will find most of the surface area irrelevant.

How the cloud sync and the host list actually fit together

The mechanism described in the README is token-based and file-based. You drop one API token per provider into purple, and it queries that provider's API for instances. The result is written into ~/.ssh/config, which remains an ordinary config file that plain ssh, scp and rsync can read. There is no daemon and no remote agent: the container features run docker or podman commands over the SSH connection you already have, which is why the README says no extra ports are opened.

The README lists 18 providers, naming AWS, GCP, Azure, Hetzner, DigitalOcean, Proxmox, Teleport and NetBox, with multiple accounts per provider supported. The full list lives in the project wiki rather than the README, so provider coverage is something to check against your own inventory before installing. Cloud sync is not the only write path: hosts can exist purely as manual entries too.

The UI is a ratatui TUI, confirmed by the dependency list in Cargo.toml (ratatui 0.30, crossterm 0.29) and the badge in the README. Navigation is keyboard-driven, with `:` opening a jump bar that fuzzy-matches hosts, tunnels, containers, snippets and actions, ranked by usage frequency. The README notes that the search covers the SSH `User`, `ProxyJump` and Vault SSH role fields, and that field prefixes such as `user:`, `proxy:`, `vault:` and `tag:` narrow the query to one directive.

A detail worth noticing in Cargo.toml: the TCP byte counters for live tunnel throughput use NETLINK_SOCK_DIAG on Linux. That is a Linux-specific mechanism, and it is consistent with the stated macOS and Linux support rather than Windows.

Installing purple and getting a first host list

The README gives a one-line installer for the shell. It fetches and runs a script from getpurple.sh. If you would rather not pipe a remote script into a shell, the README lists package-manager alternatives, and those are the ones to prefer on a managed workstation.

curl -fsSL getpurple.sh | sh

The alternatives named in the README cover Homebrew, crates.io, Nix, the Arch User Repository and a source build. The crate is published as purple-ssh, while the binary it installs is called purple, which is a mismatch worth knowing before you go looking for a package named after the command.

brew install erickochen/purple/purple
cargo install purple-ssh
nix profile install github:erickochen/purple

For a source build, the README gives a clone and a release build. Cargo.toml declares edition 2024 and rust-version 1.88, so an older toolchain will refuse the build rather than fail somewhere confusing.

git clone https://github.com/erickochen/purple.git
cd purple && cargo build --release

Once installed, the README's instruction is short: run `purple`, and press `?` on any screen for help. From there the first real task is adding a provider token so instances populate the host list, or adding a host by hand if you do not want cloud sync at all. The README does not document a dry-run mode for the first sync, which is the one thing I would want before letting a tool rewrite a file I depend on. Back up ~/.ssh/config first.

Claude Desktop users have a separate path: the project publishes an .mcpb bundle on its releases page for one-click MCP integration, described as read-only by default, with setup details on the MCP Server wiki page.

Where purple is the wrong tool

The support matrix is the first limit: macOS and Linux only. There is no Windows build described anywhere in the README or Cargo.toml, and the Linux-only NETLINK_SOCK_DIAG path for tunnel throughput has no documented equivalent elsewhere. If your engineers are on Windows, this is not a maybe, it is a no.

The second limit is architectural. purple's value proposition rests on ~/.ssh/config being the place where access is defined. Teams that have moved to a short-lived credential broker, a bastion with session recording, or an inventory system that mints config on the fly will find the sync feature solving a problem they already solved elsewhere, and possibly fighting the tool that solved it.

The third is the trust boundary. Cloud sync means purple holds API tokens for your providers and writes to a file that governs how you reach production. The README points at PRIVACY.md for the data-handling claim and states that no data leaves your machine, but the README does not document rollback for a bad sync, nor a way to preview the diff before it is applied. A tool that edits ~/.ssh/config without a documented undo is one you should try on a non-critical host list first.

Finally, breadth has a cost. Snippets, tunnels, containers, keys, Vault certificates, scp and an MCP server all live behind one keymap. The README's answer is `?` for help on any screen, which is reasonable, but a team that only wants container access across hosts may prefer a narrower tool that does one thing.

Termius and Ansible are the comparisons that matter

The repository tags include termius-alternative, and the difference is not cosmetic. Termius is a commercial GUI client with a hosted sync service: your host list lives in its account and reaches your machines through its apps. purple is a single Rust binary that reads and writes the local ~/.ssh/config, which means your existing ssh, scp, rsync, git-over-ssh and IDE remote sessions keep working unchanged, and there is no account to create. The trade is that you get a terminal UI, not a polished cross-platform GUI, and no Windows client.

Ansible is the other comparison the README invites, though it does not name it in those terms. The README's own example is running the same command on ten hosts: Ansible does that with an inventory, a playbook and Python on the control node, and it is the right answer when the task is configuration management with idempotence and reporting. purple's snippets are for the one-liner case, and the README describes showing the blast radius before fanning out plus a per-snippet track record (the example given is "28 of 29 host runs ok"). That is a lighter contract than a playbook. If your fleet changes need to be reproducible and reviewed, Ansible is the better tool and purple is the wrong one.

The container story is also worth contrasting with a web UI such as Portainer or with a remote agent. purple shells out over SSH with no agent and no extra listening port, which is simpler to secure but means every operation pays SSH latency and depends on the remote user having Docker permissions.

Maintenance, licence and what an upgrade costs you

The repository is not archived, and the last push was on 2026-09-08. The release history is dense: v3.27.0 on 2026-08-26, v3.26.1 on 2026-08-24, v3.26.0 on 2026-08-16. That cadence is a real signal for a project this size, and it also means the surface you learn today will move.

The licence is MIT, stated in Cargo.toml and in the LICENSE file at the repository root. MIT is permissive: you can use, modify and redistribute it, including internally at a company, provided the copyright notice and permission notice are preserved. What MIT does not give you is any warranty, and it does not cover the cloud provider APIs purple talks to, your provider tokens, or the contents of your ~/.ssh/config. Those are governed by your provider agreements and your own security policy, not by this licence. This is not legal advice.

Upgrade cost is mostly about the config file. Because purple writes to ~/.ssh/config, a version bump that changes how hosts are named or how stale entries are marked will show up as a diff in a file other tools read. The repository keeps a CHANGELOG.md at the top level, which is where to look before upgrading rather than after. The Rust toolchain floor is also a constraint: rust-version 1.88 and edition 2024 mean anyone building from source on a pinned older toolchain has to move it first. Package-manager installs avoid that entirely.

Editorial conclusion

Adopt purple if you run Linux or macOS, already keep your fleet in ~/.ssh/config, and want cloud inventory, tunnel monitoring and container control to land in the same terminal without an agent on the remote. Skip it if you are on Windows, if your fleet is Windows-only, or if your access model is a bastion with a short-lived credential broker that never touches the config file. Verify first that your provider is among the 18 listed in the wiki, that the API token you plan to use is read-only, and that a cloud sync run leaves a diff in ~/.ssh/config you are happy to keep.

Frequently asked questions

Official sources

1. erickochen/purple on GitHub
2. License: MIT
3. Project website
4. README
5. Releases