A developer SSH workflow built for macOS

A developer's SSH setup drifts over time: hosts in shell history, the wrong key tried on the wrong server, ssh user@host copied from a wiki page, and iTerm2, Cyberduck and TablePlus each holding a piece of the picture. SSHive puts the servers in one place and hangs the rest off each profile: the tunnels a project needs, the command that runs when a session opens, the snippets you repeat. If you already live in iTerm2, the iTerm2 comparison shows where the two overlap and where they do not.

Create a folder per project in the sidebar, with prod, staging and dev inside; subfolders work too. Give prod a red dot, staging orange and dev green, and the sidebar tells you at a glance which server you are about to open. A startup command per profile, such as cd /var/www/app && git log --oneline -5, puts you where you work as soon as the session opens. Snippets can fill in {host} or {user} on their own, or ask for a value you type, as in git checkout {{branch}}.

On the dev profile, add local tunnels for the remote services: 5432 to localhost:5432 for Postgres, 6379 to localhost:6379 for Redis. Once connected, TablePlus or Postico talk to localhost:5432 and reach the remote database; when you disconnect, the tunnels close with the session. The free version opens one tunnel per profile, so Postgres and Redis together is a Pro setup.

On the Mac, Pro includes an MCP server that lets an AI client work in your SSHive sessions: ssh_execute to run a command, sftp_read_file to read a config. Turn it on in Settings > MCP and copy the setup it shows into Claude Code or Cursor; the App Store version does not write your client's configuration for you. Then ask "tail the last 200 lines of app.log on staging and find the 500s", and the assistant does it in the staging session. The Scope tab decides which servers it can reach: remove a production folder, and servers you file there later stay out too. What the assistant reads is sent by its client to the model provider.