XPipe - A connection hub for all your servers: Status update for the v14 release
I'm proud to share a major development status update of XPipe, a new connection hub that allows you to access your entire server infrastructure from your local desktop. XPipe 14 is the biggest rework so far and provides an improved user experience, better team features, performance and memory improvements, and fixes to many existing bugs and limitations.
If you haven't seen it before, XPipe works on top of your installed command-line programs and does not require any setup on your remote systems. It integrates with your tools such as your favourite text/code editors, terminals, shells, command-line tools and more. Here is what it looks like:
Reusable identities + Team vaults
You can now create reusable identities for connections instead of having to enter authentication information for each connection separately. This will also make it easier to handle any authentication changes later on, as only one config has to be changed.
Furthermore, there is a new encryption mechanism for git vaults, allowing multiple users to have their own private identities in a shared git vault by encrypting them with the personal key of your user.
Incus support
There is now full support for incus
The newly added features for incus have also been ported to the LXD integration
Webtop
For users who also want to have access to XPipe when not on their desktop, there exists the XPipe Webtop docker image, which is a web-based desktop environment that can be run in a container and accessed from a browser.
This docker image has seen numerous improvements. It is considered stable now. There is now support for ARM systems to host the container as well. If you use Kasm Workspaces, you can now integrate the webtop into your workspace environment via the XPipe Kasm Registry.
Terminals
Launched terminals are now automatically focused after launch
There is now support for Wave terminal on all platforms
The Windows Terminal integration will now create and use its own profile to prevent certain settings from breaking the terminal integration
Performance updates
Many improvements have been made for the RAM usage and memory efficiency, making it much less demanding on available main memory
Various performance improvements have also been implemented for local shells, making almost any task in XPipe faster
Services
There is now the option to specify a URL path for services that will be appended when opened in the browser
You can now specify the service type instead of always having to choose between http and https when opening it
There is now a new service type to run commands on a tunneled connection after it is established
Services now show better when they are active or inactive
File transfers
You can now abort an active file transfer. You can find the button for that on the bottom right of the browser status bar
File transfers where the target write fails due to permissions issues or missing disk space are now better cancelled
Miscellaneous
There are now translations for Swedish, Polish, Indonesian
There is now the option to censor all displayed contents, allowing for a more simple screensharing workflow for XPipe
The Yubikey PIV and PKCS#11 SSH auth option have been made more resilient for any PATH issues
XPipe will now commit a dummy private key to your git sync repository to make your git provider potentially detect any leaks of your repository contents
Fix password manager requests not being cached and requiring an unlock every time
Fix Yubikey PIV and other PKCS#11 SSH libraries not asking for pin on macOS
Fix some container shells not working do to some issues with /tmp
Fix fish shells launching as sh in the file browser terminal
Fix zsh terminal not launching in the current working directory in file browser
Fix permission denied errors for script files in some containers
Fix some file names that required escapes not being displayed in file browser
Fix special Windows files like OneDrive links not being shown in file browser
A note on the open-source model
Since it has come up a few times, in addition to the note in the git repository, I would like to clarify that XPipe is not fully FOSS software. The core that you can find on GitHub is Apache 2.0 licensed, but the distribution you download ships with closed-source extensions. There's also a licensing system in place as I am trying to make a living out of this. I understand that this is a deal-breaker for some, so I wanted to give a heads-up.
Outlook
If this project sounds interesting to you, you can check it out on GitHub or visit the Website for more information.
Anyone who manages some kind of servers, virtual machines, containers, etc. That can be in your homelab or also at your job if you are doing that professionally. So assuming that you are selfhosting something, you can get some use out of this. And the more stuff you selfhost and have to manage, the more useful it becomes.
I appreciate the reply, but I guess I wasn't clear on what I was asking.
It's obvious who this is for in the literal sense, what I mean is: what is the use case for this?
On the homelab front, I don't see enough need to unify my GUI access, and i have roughly 30 containers to manage. At that point, most homelab admins gravitate to automation.
On the professional front, I can tell you that unifying the keys to mgmt interfaces to critical infrastructure in a single app is not a welcome tool to see on my junior admin desktops. And if it's simply the interface to mgmt portals without storing keys, then I would have my doubts about a junior admin who hasn't developed a personal strategy to manage this themselves.
Don't get me wrong, I'm happy to encourage you to develop this, but the second you write "trying to make a living from this", you should know that these questions are coming.
If I were across the table from you trying to understand what you're selling me, I would want to know:
how do you handle secrets in transit and at rest?
can I deploy this once and set access for various departments or employees?
can I find out who has been using the tool?
how does the app handle updates?
You can see where this is going. If I buy this tool for use by several people, I don't want to have to wrap it in vault entries and update scripts just to meet compliance with my client's environment.
Seemed so nice until I tried to add my very first personal server that has Oracle Linux distro on it and it paywalled me immediately. So if you want it for personal use but you use the wrong(!) distro on your server, tough luck! You gotta pay for it unless you replace your server with something like Debian I guess. That was the end of it for me. As a constructive feedback: it would be nice to see a list of which distro/server os variants are not paywalled, or which ones are paywalled. For now Asbru will do it for me.
Edit: turns out it's written out on the pricing page in detail. See the comment below.
Thank you for the heads up, i was a dork, it's indeed fully listed in the table that's on the pricing page.
I'll quote that part for the context.
From the Pricing page :
The following systems are classified as commercial operating systems within XPipe and connections to those systems are only possible starting from the homelab plan:
Amazon Linux systems
Oracle Linux systems
The following systems are classified as enterprise operating systems within XPipe and connections to those systems are only possible starting from the professional plan:
Yeah that is implemented under the assumption that these distros are most of the time used in enterprise contexts. I know that this is not always the case, there is the option to upgrade to a license at no additional cost to the next tier if you're only using it for personal use. Just send me an email I can upgrade it for you.
And out of curiosity, is there a particular reason why you chose Oracle Linux for your personal server?
Yeah I saw that option to offer free upgrade for the claimed personal use and that's nice. It's also just fine for paying such a product as a whole. I was just frustrated for not being able to try it with a single server.
Reason for Oracle Linux is my Linux journey pretty much started and continued with rhel based distros, be it Mandrake(yeap good old Mandrake) at home at first then actual redhat subscription in the research center I volunteered and mostly centos on my servers as well as fedora as my workstation OS.
After Centos upstream change, I started using Oracle and it's nice and stable.
As far as the explanation on the product page goes I guess anything that looks like rhel (like Rocky) will also ring the enterprise bells.
Thankfully most hobbyists like raspi users will go with Debian based stock OS or use something like Ubuntu server version so they'll be fine with free version of xpipe.
I'm still very confused on this project and it's aim...
So it's a GUI front end for all the other system utilities you would need to install first in order to make it work properly, right? So then...like...why all the overhead if it's just literally opening up the tool you intended to use anyway? Is it actually opening a new CLI window an SSH connection to a server, for instance? It seems like more steps to open this, go through multiple clicks to find the connection you want, and then get plopped back into an SSH session versus just typing 'ssh user@thismachine.com'.
If you are looking for key points from the perspective of a heavy ssh CLI user, you can think of it as a fancy wrapper around your existing SSH client and configuration. It will automatically detect your SSH config and supports exactly the same set of features and options as your SSH client as it internally uses that one. It doesn't try to replace your existing SSH client and configuration, it works with it.
What it will add:
You have direct access to all systems running on the servers you connect to, e.g. docker containers, using the exact same graphical interface. On the CLI you also have that in theory, but that's tedious
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
You have the ability to synchronize your connections and environments through git, including your SSH configs
You get special integration for SSH tunnels that allows you to toggle them to start / stop in the background and open tunneled services in the browser automatically
You get an overview over all your remote connections and can access the file system of any connected remote system via a uniform graphical user interface, allow you to use your own desktop text editors instead of terminal-based ones. It also supports dynamic sudo elevation, so you can also save files as root without having to login as root
Plus all the integrations for other tools as well. For example, you want to connect to a certain VM guest in in a hypervisor via SSH but it is not reachable from the outside? XPipe can connect you to it through the hypervisor host, automatically determine IP addresses, and open a terminal session instantly
I'm really not trying to diss on your project, but all of this is just really the default for a normally configured SSH client in a proper ecosystem. MAYBE this is somewhat useful for beginners, or Windows users I guess. The only thing in there that sort of seems to improve a workflow might be the tunneling, but even then I don't see it actually saving time.
I appreciate you taking the time to reply, but I guess I'm just not going to understand the target user here unless they are absolute beginners and unfamiliar with how all of this fits together.
It's an easy way to manage multiple servers/vms remotely. It makes transferring files to remote headless systems easy and simplifies remembering multiple hosts. It's akin to moba xterm, a similar windows only project