I've been working with remote servers for a while, and I always found it a little weird that most SSH clients are organized around terminal tabs.
You connect to one server and get a tab. Open another connection and get another tab. Need two terminals on the same server? More tabs. Then you need to change a file, so now you're switching to an SFTP client or opening another editor.
It works, obviously. I've worked like that too. But once I had a few servers open at the same time, I would constantly end up with a pile of terminals and have to remember which one belonged to what.
That's basically why I started building SSHFlow.
The idea was simple: instead of treating every SSH connection as a terminal tab, treat the server itself as a workspace.
Servers instead of tabs
When you open a server in SSHFlow, you enter its workspace. That's where its terminals and files live.
So if I'm working on my VPS, I open that server and everything I need for it is there. I can start a couple of terminals, browse the filesystem, upload something, or open a file and edit it without leaving the workspace.
Then if I need another server, I switch to that server instead of adding another terminal to an increasingly confusing row of tabs.
[dashboard screenshot]
It's a pretty small change in how things are organized, but after using it for a while I realized this is much closer to how I actually think about remote work.
I almost never think "I need terminal number 5."
I think "I need to do something on this server."
I also wanted SFTP to be less annoying
The other thing I wanted to change was working with remote files.
I used to have situations where I'd SSH into a server, realize I needed to change a config or some code, open SFTP, find the same server again, find the file, open it in an editor, make the change and then upload it back.
That's a lot of switching around for something that might be a one-line edit.
So I ended up putting file editing directly into the SFTP side of SSHFlow.
You can browse the remote filesystem, double-click a file, edit it and save it back to the server. It's still just using SFTP underneath — there isn't anything special you have to install remotely.
[files/editor gif]
This has probably become one of my favorite parts of the app just because of how often I use it.
I didn't want another agent running on my servers
This was one of the things I decided pretty early.
I didn't want SSHFlow to require installing its own software on every machine I connect to. If a server already has SSH, that should be enough.
So SSHFlow uses regular SSH and SFTP. The connection goes from your computer to your server and there's no SSHFlow agent that needs to sit on the remote machine.
The app itself is built with Electron and Node.js. I'm using xterm.js for the terminals and ssh2 for the SSH/SFTP side.
Electron obviously has its tradeoffs, but it let me build this pretty quickly using a stack I already knew. At this stage I'd much rather spend my time making the actual workflow better than rewriting the whole thing just to make the installer smaller.
The product actually got simpler while I was building it
One mistake I made at first was assuming that if I kept adding features, the product would automatically get better.
I added more and more things because they sounded useful on paper. Eventually I realized I was slowly turning a pretty simple idea into a giant server management app.
So lately I've been going the other direction.
The part of SSHFlow I actually care about is really simple: open a server, have your terminals and files in one place, do what you need to do, and move on.
I'm trying to make that workflow really good instead of trying to replace every DevOps tool someone might use.
There's still a lot I want to improve, but I've reached the point where I use SSHFlow myself instead of the tools I was using before, which is pretty cool considering this originally started because I was annoyed by my own workflow.
If you want to check it out, it's here:
Right now it's available for Windows.
I'm also curious how other people who work with multiple servers organize this stuff. Do you just use SSH + tmux? Termius? VS Code Remote SSH? WinSCP? Something completely different?
And I'm especially curious whether the "server as a workspace" idea makes sense to other people, or if this is just how my brain wants SSH clients to work.
Top comments (0)