Show HN: XPipe, a shell connection hub for SSH, Docker, K8s, VMs, and more (xpipe.io)
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!
83 comments
[ 2.8 ms ] story [ 147 ms ] threadI'm not really interested in the latter.
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.
If you used XPipe a year ago, it's night and day compared to today in terms of features, stability, and performance.
Or maybe a license with $70 with two years of updates included and then $10/year afterward.
Or what Jetbrains does and reduce the cost of the subscription over time, but let the users still use their last version after the subscription ends.
I believe Java is no longer an appealing choice for these types of tools, but I still like the project and its development process.
Next week, when JDK 24 is released for the general availability, I plan to immediately switch to that as there will be additional performance gains with Project Leyden's AOT compilation and Project Liliput's memory improvements. So I'm positive for the future.
Sure it can be done, but it's not exactly like there are well-established solutions for this.
tbh java is a perfect choice for a tool like this. building it in rust or go would take 10x the time.
I'm particularly interested in this "field". I've build something similar many moons ago [1], in the same spirit, but much more primitive. I later started a company around an evolved idea, where the structure you sort of see in your screenshots is effectively a DAG with arbitrary depth (we didn't manage to release it unfortunately, complexity overtook us).
In any case, much congratulations + good luck with the launch!
[1]: https://github.com/raaftech/session
It's cool to see that there are also other people in that space. And about the complexity, I definitely know what you mean. It took a long while before this approach even worked and also took a while until it was actually stable. One of the main points of consideration whenever I think of adding something is the added complexity, because it's very important for me to keep that as low as possible. Otherwise I will end up with an unmaintainable workload. There were definitely a few interesting features I discarded to keep the application as lean as possible.
/me blinks. An OS is an OS... so, access to developer licenses for these are Professional use too?
> connections to those systems are only possible starting from the homelab plan: Oracle Linux systems
/me blinks even more ...
I've been using OEL since before Rocky was a thing. It was and still is a free alternative to RHEL.
Apart from that, all my planned use of XPipe fits entirely in the Community feature set (maybe apart from Yubikey/GPG agent).
But now I'd need to pay $5 a month just to open a shell? No thanks.
Also, a slight tangent, but charging homelab folks $5/mo is weird. The only profit I'm making with my homelab is negative. And I, as a developer, would much more likely to ask my employer to buy an enterprise license if I actually liked using it at home. Like Tailscale, JetBrains, etc.
The community version is pretty extensive in what you can do with it, so I think you can accurately judge whether the homelab plan is worth it for you by using it for a bit.
I'm a freelancer working with different clients with a mix of the technologies you listed (Docker/Kubernetes) and I'm using Tailscale for mostly personal use-cases, so this hits all the right spots.
Up until now I proxied most of my stuff on a macOS client via "SSH Tunnel Manager", which has quite a clunky UI, and whenever I have to reconfigure something there the current feedback of the current connection state isn't always right. I just moved all those settings to XPipe, and it works like a charm.
Previously I also used the same solution for accessing some internal websites via a combination of the SSH tunnels + /etc/hosts entries + header rewrites, which depending on the complexity of the websites sometimes works great and sometimes doesn't at all. With XPipe I was easily able to set up a SOCKS proxy, which I previously gave up on trying to figure out. Paired that with FoxyProxy on Firefox and now all the websites work like a charm!
And I don't think it's available for my os, otherwise I'd try it. But it's ok, I have my own setups for this stuff.
And about adversity to subscriptions, note that you can also obtain lifetime licenses further down the pricing page.
And the marketshare on desktop is so tiny that there is really no value in supporting it, I understand that.
For VNC, as the a landscape of tools to integrate is a little bit less populated compared to RDP, XPipe has a built-in VNC client. However, if you still want to use your own VNC client, you can do so using the service tunnel functionality.
Will try it to see how this work.
https://news.ycombinator.com/item?id=40599419 (9 months ago)
https://news.ycombinator.com/item?id=38412162 (2 years ago)
https://news.ycombinator.com/item?id=37186039 (2 years ago)
Thank you for this, it looks amazing. With so many client machines, servers, raspberry pis, tunneling to home, RDP sessions etc etc these days it gets out of hand managing connections. I can't wait to try this. Thank you
Would it be possible to get XPipe to work with this constraint? Couldn't find much in the docs.
So, if you just straight-up call `kubectl` within XPipe without having AWS credentials already available, then it would fail. So, I'm guessing this wouldn't work.
By default, it looks like this:
but for us it would look like this:To preface that, the CLI is only very basic. The only real thing you can do with it is launch shell connections. For more advanced usage without the GUI, there is for example the Python API: https://docs.xpipe.io/guide/python-api
Welp. If I have to choose between XPipe and LTSC, I'm afraid LTSC is gonna win. I have no interest running a version of Windows where Windows Update will randomly decide to brick my install or better yet, add even more Candy Crushes to my start menu.
You can run XPipe on a local LTSC installation, you just can't connect to one remotely because it thinks that you are connecting to a Windows Enterprise server. I will think about how to solve this the best way, because that wasn't on my radar
Apptainer?
Can it import my connections from WinSCP?
The only service it relies upon is the licensing server, but if you also don't want to use that to be fully independent, you can request an offline license. You can find the details about that on the pricing page.
Right now, there's no direct import from WinSCP, next best thing where it can import from is Putty
Well, I tried to try it. I guess I'll just bookmark it and try again at a later date.
If your hypervisor is supported by libvirt, you should already be able to use it in XPipe.
If it does not support libvirt, then I guess this would need a separate integration. But I would have to look into that first as I have never used these tools you listed.
But there is very good support for nested shell connections and tunneling RDP over SSH. If your target system isn't reachable directly and require something like a bastion host connection first, you can still connect via RDP if you use SSH tunnels over multiple hops in XPipe.
- You can bring your shell environments / init scripts / aliases with you in a noninvasive way. I.e. you don't have to modify the remote system dotfiles, when you connect through xpipe it will set up any scripts you want to have available automatically
- You can link up your password manager with your SSH client and other connection methods that require passwords
Feel free to write here or refer to any url you recommend.
Thank you, and good luck with your product!
- XPipe acts as an askpass program for SSH, meaning that it can listen to any password requests made from the ssh client, forward that your password manager, and reply with the password that the password manager returned. If you password manager supports the SSH-agent, XPipe can also use it to supply keys for ssh as well.