I think API clients have a blind spot.
They’re great when the service is reachable from your laptop. Point at https://api.example.com, add a token, send the request, done.
But a lot of real infrastructure does not work that way. The API you need is sitting behind a bastion, inside a private subnet, using internal DNS, reachable from exactly one jump host that some poor person named ops-bastion-03 five years ago. Your laptop has no route to it. Your DNS has no idea what the hostname is. Postman, Insomnia, Bruno, curl — they are all fine tools, but from your machine’s point of view the service might as well not exist.
So we do the ritual.
ssh -L 18080:inner-fleet-api:8080 user@bastion.example.com
Then we go back to the API client and replace the real URL:
http://inner-fleet-api:8080/api/v1/drivers
with the fake local one:
http://localhost:18080/api/v1/drivers
And yes, this works. That is not the point. Plenty of annoying workflows “work.”
The problem is that the API request has lost the context that makes it meaningful. The real host is not localhost. The real service is not on port 18080. The request belongs to an environment, behind a specific SSH path, with specific credentials, notes, runbooks, maybe a database next to it, maybe an incident you are trying to debug. But the tool you are using only sees a localhost URL and a pile of headers.
After a while you get the classic private-infra mess:
18080 -> dev fleet API
18081 -> staging fleet API
15432 -> dev Postgres
16379 -> Redis
19090 -> some admin UI I forgot to rename
One tunnel dies. One terminal window gets closed. One local port gets reused. Someone pastes a request into Slack with localhost:18080 in it and now nobody else can run it without recreating your exact tunnel setup.
This is dumb. Not because SSH tunneling is dumb — SSH tunneling is one of the most useful things we have — but because API clients should treat this as a first-class workflow.
That is the original reason I built ShellYard.
The feature I wanted
ShellYard is a desktop infrastructure workspace, but the first feature that made me want the app was simple:
Pick an SSH session as the route for an API request.
Open a saved SSH connection. Open a REST or GraphQL request. Choose that SSH session as the route. Send the request. DNS resolution and the TCP connection happen from the remote network context, not from your laptop.
So the request can stay honest:
http://inner-fleet-api:8080/api/v1/drivers
No fake localhost URL. No manual -L. No “which tunnel was this again?” archaeology.
This is the kind of thing that feels small until you do it twenty times a week.
The tools are good. The handoffs are bad.
Once I had SSH and API requests living in the same app, the next annoying thing became obvious: infrastructure work rarely stays in one tool.
A normal debugging session might involve SSH, an internal API, a database, DNS, certs, notes, a password manager, and maybe a chatbot if I’m trying to reason through an ugly failure. None of those tools are bad. The problem is that they all act like they are the center of the universe.
Your SSH client knows about hosts.
Your API client knows about requests.
Your DB client knows about connections.
Your notes app knows about text.
Your AI assistant knows whatever you had the patience to paste into it.
The handoffs are where the workflow falls apart.
ShellYard grew out of trying to keep that context together. It organizes work into Spaces, so a Space can be a customer, environment, lab, project, site, or whatever mental bucket matches the way you actually work.
A Space can hold SSH/SFTP, RDP/VNC, REST/GraphQL, database connections for Postgres/MySQL/SQL Server/Mongo/Redis, network diagnostics, IPAM, docs/runbooks, and vault secrets.
That sounds like a lot because infrastructure work is a lot. The trick is not “bundle every tool on earth.” The trick is keeping the context together when you are already bouncing between these things anyway.
The AI part, without the magic dust
ShellYard has an optional assistant called Magellan.
I know “AI assistant in a devtool” sounds like something everyone is stapling on now, so I’ll be specific about what I think is useful.
The useful part is not having another chat box.
The useful part is that the assistant can work from the current tab, session, or request, so I do not have to keep copying terminal output, HTTP responses, and notes into a separate chatbot.
Magellan is bring-your-own-key. Requests go directly from the desktop app to the provider you configure — Anthropic, OpenAI, Google Gemini, or an OpenAI-compatible endpoint like Ollama. ShellYard is not in that request path.
That matters to me because the point is not to have a mysterious AI layer sitting between me and my infrastructure. The point is to give the model the context I was already looking at, without turning my clipboard into the integration layer.
What ShellYard is not claiming
ShellYard is not claiming that SSH tunnels are new.
They are obviously not.
You can do all of this manually with ssh, curl, Postman, DBeaver, a password manager, some notes, and enough discipline to keep your local ports straight. I built ShellYard because I do not always have that discipline, and I suspect a lot of infrastructure work is held together by the same duct tape.
The thesis is basically this:
The tools are good. The handoffs between them are bad.
ShellYard is my attempt to make those handoffs less stupid, starting with the one that bothered me most: testing private APIs through SSH without pretending everything is localhost.
Where it is now
ShellYard is a desktop app for macOS, Windows, and Linux, built with Wails — Go on the backend, React/TypeScript on the frontend. You can download it and start free without signing in.
It is a 1.0, built solo on nights and weekends, so there are still rough edges. One known gap is the proper known_hosts fingerprint UI, which is high on my list.
I’m looking for feedback from people who actually live in this mess: bastions, private APIs, internal DNS, SSH-heavy environments, MSP/client networks, platform work, network troubleshooting, all of it.
Would this make your workflow better, or is it trying to paper over something you would rather solve with scripts?
More importantly: what would make you uninstall it immediately?
Thanks for reading.
Top comments (0)