Show HN: XPipe, a shell connection hub for SSH, Docker, K8s, VMs, and more

Hey HN, I built XPipe as I always wanted to have an easy file system and terminal access to all of my remote systems, including containers, virtual machines, clusters, and more that you normally can't connect to with existing solutions out of the box.

XPipe is a new type of connection hub that allows you to access your entire server infrastructure from your local desktop. It can make your life easier when working with any kind of servers by eliminating all the commonly tedious tasks that come up when interacting with remote systems, either from the terminal or from a graphical interface. XPipe comes with integrations for SSH, docker and other containers, various hypervisors like Proxmox, Kubernetes clusters, tools like Teleport and Tailscale, and more without requiring any setup on your remote systems. You can link your favourite text/code editors, terminals, password managers, shells, command-line tools, and more with it, allowing you to keep using your own favourite tools when working with XPipe.

The entire implementation of how it communicates with remote systems is completely different from most other solutions out there. What happens in the background can essentially be explained this way: It launches a local shell process like cmd or bash and executes a command that opens a remote shell connection such as ssh user@host in that shell process. All communication is then done through the stdin/stdout/stderr of that shell process. From there, it detects what kind of server and environment, such as shell type, os, user, etc. you have logged into and adjusts how it talks to the remote system. By then using, for example, file system related commands such as ls, rm, touch, etc. and its equivalents, it can realize a functional file manager that can connect to essentially every system.

It is essentially the same idea as emacs TRAMP mode if you have ever used that. With the difference being that it works on all kinds of systems and is also not constrained to a certain editor/tool environment. VSCode also uses a similar approach for some of the remote development tools with SSH, but that one is more limited in scope and is a little bit sluggish to use. And it's also bound to the VSCode platform. The goal of XPipe's implementation is to not be limited by a certain environment or specific set of tools.

The development took a while as this new approach requires a completely new implementation in many areas, but I am confident that it's ready now. I appreciate any kind of feedback from you to guide me in the right development direction from here.

Enjoy!

Show HN: XPipe, a shell connection hub for SSH, Docker, K8s, VMs, and more
xpipe.io

The homelab and professional editions have lifetime licenses available - I didnt notice them in the pricing section but there’s a link to them in the FAQ

The issue is do I own the software or rely upon SaaS infra I can't control?

I'm not really interested in the latter.

You will own a lifetime license for the software if you choose the lifetime plan.

Everyone has seen it in practice that some companies try to pull a bait and switch by then changing the terms of licenses or simply shutting down the servers when going out of business. Since this is a desktop tool not hosted on any server infrastructure, at least the latter part isn't that much of a risk. You still have to have some trust in me to honor the license terms, but I try my best to build that trust.

There is also an offline license functionality, meaning that if you obtain a lifetime license and request an offline license file, that one will not perform any verification with any online services, so it will work forever without any dependency on some SaaS infra. Anyone interested in that can simply request an offline license, you can find the details on the pricing page. The offline licenses are also often used for usage in air-gapped environments.

Yeah feel free to open a feature request on GitHub, that way I can keep track easier. You can also make my life much easier if you provide more details on how exactly such an integration could work. Because in practice, many requested integrations are for tools that I have never used before. I have to first figure them out myself and set up proper a testing environment. That part sometimes takes more time than implementing the actual integration itself because some tools are quite difficult to set up (Looking at you, goteleport).