purple: an SSH config editor that syncs ~/.ssh/config with 18 cloud providers

The problem purple solves is the gap between provisioning and connecting

The README is unusually direct about the motivation. The author states that their SSH config was fine, with aliases, ProxyJump chains and provider-based organisation, and that the config was not the problem. The problem was everything around it: checking a container meant running 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, and spinning up a Hetzner VM meant opening the console, copying the IP, editing the config and saving. The target user is the person who does all of that from a terminal and does not want a GUI client or a web dashboard for it. The README frames the alternative as Termius, and the repository topics include termius-alternative. If your hosts are static and you edit ~/.ssh/config a few times a year, the cloud sync half of purple does nothing for you.

Cloud sync writes into ~/.ssh/config rather than replacing it

This is the architectural decision that matters most. purple does not maintain its own host database and generate a config on demand. According to the README, new machines land in ~/.ssh/config the moment they boot, IPs follow instances as they move, and decommissioned hosts grey out instead of lingering. The unit of configuration is the file OpenSSH already reads, so plain ssh, scp, rsync and git over SSH keep working without purple in the loop. The cost of that choice is that purple becomes a second writer to a file you may already manage elsewhere, and the README does not describe a conflict resolution policy for that case. Sync covers 18 providers including AWS, GCP, Azure, Hetzner, DigitalOcean, Proxmox, Teleport and NetBox, with multiple accounts per provider, and setup is described as one API token per provider. The README does not state the polling interval, whether sync is triggered manually or on a timer, or what happens when a provider API call fails mid-run. Those are the questions to answer before pointing it at a production account.

Tunnels, containers and keys are read through SSH, not through an agent

The container fleet view is the clearest example of the design. The README says your whole fleet's containers appear in one list grouped per host, and that you can shell in, stream logs, restart, stop, exec, or take down a compose stack member by member. The stated constraint is explicit: no agent on the remote, no web UI, no extra ports, just SSH. That means every container operation is an SSH command executed against a host you already have credentials for, which keeps the deployment surface at zero but also means purple is only as fast and as available as your SSH connection to each host. Tunnel monitoring works differently. The README describes Local, Remote and Dynamic SOCKS forwards with live throughput, channel activity, uptime and a per-client process roster showing the exact app behind each connection. That implies purple inspects the SSH process and its channels rather than inferring activity from the config, though the README does not say how it obtains per-channel data. Keys get a similar treatment: every key in ~/.ssh is scored and fingerprinted, listed with the hosts it unlocks and the last time it was used, and can be pushed to a fleet with the p key. Vault-managed hosts are skipped automatically during a key push, which is the right default because it keeps certificate-managed hosts certificate-managed.

Install paths and the first commands

The primary install is a shell script: curl -fsSL getpurple.sh | sh. Alternatives documented in the README are brew install erickochen/purple/purple, cargo install purple-ssh, nix profile install github:erickochen/purple, paru -S purple-bin or yay -S purple-bin on Arch, and a source build via git clone https://github.com/erickochen/purple.git followed by cd purple && cargo build --release. Note the crate name is purple-ssh while the binary is purple. You start it by running purple, and the README says pressing ? on any screen opens help. The universal search is the colon key: press : and type, and it matches hosts, tunnels, containers, snippets and actions, ranked by how often you use them. It also searches the SSH User and ProxyJump directives and the Vault SSH role, and accepts field prefixes user:, proxy:, vault: and tag: to narrow to a single directive. Cloud sync configuration is one API token per provider, and the README points to a wiki page for the full provider list rather than documenting the config keys inline. That is a real gap: you cannot tell from the README alone where tokens are stored or what file holds them.

The MCP server is the part to enable carefully

purple ships an MCP server so AI agents can reach your hosts, and Claude Desktop users can install a .mcpb bundle from the releases page. The README states the bundle is read-only by default and links to a wiki page for setup. It also states that no data leaves your machine, with a pointer to PRIVACY.md. Two things are worth separating here. The privacy claim is about purple's own behaviour. An MCP client is a separate program with its own data handling, and the README does not describe what an agent can do once connected beyond the read-only default. The default is the right one, and anyone who flips it should do so deliberately. The README does not enumerate which operations become available in write mode, so that is something to establish from the wiki before enabling it.

Where purple is the wrong tool

Platform support is the first hard limit. The README describes purple as being for macOS and Linux, and the install options are a shell script, Homebrew, Cargo, Nix and the Arch AUR. There is no Windows path documented. The second limit is scope. The snippet feature runs a saved command across a set of hosts, shows the blast radius before you fan out, and keeps a per-snippet track record, with the README using the example of 28 of 29 host runs succeeding. That is a useful safety rail for ad hoc commands, but it is not configuration management. There is no documented idempotency, no desired-state model and no rollback, so it does not replace Ansible or similar tools for anything that needs to converge repeatedly. The third limit is the config file itself. Because purple writes to ~/.ssh/config, it competes for that file with any other tool that generates it. The README does not describe how it merges with existing entries or what it does when a host it previously wrote has been edited by hand. If your config is generated by a provisioning pipeline, two writers on one file is a problem you have to solve before adopting purple, not after.

How it differs from Ansible and from GUI SSH clients

The comparison the README draws is against Termius, a GUI SSH client with a sync service. The difference in approach is that purple is a terminal TUI with a single binary, and its state lives in ~/.ssh/config rather than in a hosted account. That matters if you do not want host inventory in someone else's database, and it also means you get no cross-device sync from purple itself. Against Ansible, the difference is direction. Ansible pushes a declared state to hosts and is built for repetition; purple reads your existing infrastructure and makes it reachable from one terminal. The README's own framing is that you would otherwise boot Ansible for a one-liner, which is an argument about the small end of the task range, not a claim that purple replaces it. A fair reading is that purple covers connection management, ad hoc command execution and container inspection, and stops there. It does not attempt provisioning, package management or drift correction, and the README does not claim it does.

Maintenance cost and what the MIT licence actually covers

The project is active. The most recent release listed is v3.27.0 from 2026-08-26, with v3.26.1 and v3.26.0 in the preceding ten days, and the last push to the repository is 2026-09-08. That release cadence is worth knowing because purple depends on external APIs: 18 cloud providers, the HashiCorp Vault SSH secrets engine, and the Docker and Podman CLIs on remote hosts. Provider API changes and Vault behaviour changes are the most likely sources of breakage, and they arrive on the providers' schedule, not purple's. The practical cost is keeping the binary current, which the install methods make cheap. The licence is MIT, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are preserved. That is a statement about the licence text, not legal advice; if you are redistributing purple inside a product, read the LICENSE file and get your own counsel. One more thing the README does not cover: there is no documented migration or upgrade procedure for the state purple keeps, so it is unclear whether a version bump can alter anything it has written into ~/.ssh/config. Back that file up before the first run.

Editorial conclusion

Adopt purple if you already live in ~/.ssh/config and your fleet changes often enough that hand-editing it after every Terraform run has become a chore, or if you want container and tunnel visibility without installing an agent on each remote host. Skip it if you are on Windows, if your hosts come from a configuration management system you do not want a second writer touching, or if you need a full remote-execution tool rather than a snippet runner. Before trusting it, verify three things yourself: that the provider credential you plan to use is read-only, that a sync run leaves your existing ~/.ssh/config entries intact, and that the MCP bundle is installed in its read-only default rather than with write access enabled.

Official sources

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