I’m proud to share a status update of XPipe, a shell connection hub and remote file manager that allows you to access your entire server infrastructure from your local machine. It works on top of your installed command-line programs and does not require any setup on your remote systems. So if you normally use CLI tools like ssh, docker, kubectl, etc. to connect to your servers, you can just use XPipe on top of that.
Since the last status update some months ago, a lot of things have changed thanks to the community sharing a lot of feedback and reporting issues. Overall, the project is now in a much more stable state as all the accumulated issues have been fixed. Furthermore, many feature requests have been implemented.
Large connection sets
A lot of work went into improving the application for large use cases when you’re managing hundreds of connections. This includes hierarchical organization features to group all your connections into different categories and subcategories. Furthermore, there have been multiple processing and memory optimizations to ensure that the user experience stays smooth all the time. As a side effect, the memory footprint also has gone down. For people who have to use a potato as their workstation, there’s also now a performance mode setting to disable any visual effects that are not required.
You can also now tag connections by color for organizational purposes to help in situations when many connections are opened in the file browser and terminals at the same time. These colors will be shown to identify tabs everywhere within XPipe and also outside of XPipe, for example in terminal titles using unicode color symbols.
A new scripting system
XPipe 1.7 comes with a new scripting system, so now you can take your shell environment everywhere. The idea is to create modular and reusable shell scripts in XPipe that you can then use for various different use cases.
You can set certain scripts to be run on init for every connection independently of your profile files, allowing you to set up a consistent environment across all remote systems without any manual setup. In addition, you can choose to bring scripts to all your remote systems. This will make XPipe automatically copy and update these scripts to a target system if needed and put them in your PATH so that you’re able to call them from anywhere.
As of now, there is one set of predefined scripts included for enabling the starship prompt in your shells, mainly as a proof of concept. What you will use the scripting system for is up to you. If you like, you can contribute scripts to be included by default.
Other news
-
You can now sync your connection configurations with your own remote git repository
-
You can create fully customized SSH connections by using the OpenSSH config format within XPipe
-
Additional actions for containers have been added, such as attaching to a container or printing the live logs of a container in a terminal session
-
A transparency slider has been added so that you can make all windows partially transparent just as you like
-
Support for many more terminals and text editors across all platforms has been added
-
Support for BSD systems and special login shells like pfSense and OPNsense has been added
-
There’s now support to open an SSH connection in your default installed SFTP client or Termius
-
The .deb and .rpm releases now correctly report all required dependencies. So you can install it on embedded systems or WSL2g without any hassle
-
There are now ARM releases for Linux
-
Support for VMware desktop hypervisors has been added
-
There have been many performance improvements to reduce the startup time, memory usage, file browser loading speed, and more
-
The homepage at https://xpipe.io/ got an upgrade
-
There’s an official xpipe nixpkg available that you can install. This one is however not always up to date and is currently missing crucial bugfixes that were released a short while ago. There is also a repository that contains the latest up-to-date nixpkg releases: https://github.com/xpipe-io/nixpkg
-
Of course, a lot of bugs have been fixed across the board
-
If you are interested in a video demo, there is a nice YouTube video about it
Going full-time
A few messages I received and the demand for XPipe so far convinced that there is a market for developing XPipe full-time and financing it by special commercial and enterprise plans for interested customers. It essentially encompasses support for enterprise systems and tools that you normally don’t find outside of enterprises.
This will improve the development speed and quality as I can now fully focus on creating the best possible application. The scope is very small and only involves me, so no investors or other employees. This drastically lowers the break-even value compared to most other tools and allows me to implement a very lenient commercialization.
Essentially, you can use most current features without any limitation for free. Furthermore, most upcoming features will also be included in the free version. The open-source model and license also won’t change. The only features that require a license are integrations for enterprise systems. For example, if you’re trying to connect to a licensed RHEL system or an OpenShift cluster, it will ask you to buy a license. Conversely, with a Rocky Linux system and a k3s cluster, you can use everything for free. These commercial-exclusive implementations will probably not be included in the repository though. Other than that, there are no restrictions.
Outlook
So if you gave this project a try a while ago or it sounds interesting to you, you can check it out on GitHub! There are still more features to come in the near future. I also appreciate any kind of feedback to guide me in the right development direction. There is also a Discord and Slack workspace for any sort of talking.
Enjoy!
I appreciate the writeup and that you’ve taken the time to post about it here, however I am 100% leery of managing remote access or credentials using closed source software. I’ll definitely keep an eye on the project, but it’s a hard pass for me until the app is fully open source.
Alright that is understandable, everyone has a different attitude towards that matter.
Anyone who isn’t an idiot agrees with the person you’re replying to
This looks nice! Will check it out when I get home, my tmux setup is becoming a bit unwieldy.
Have you considered embedding a terminal editor in the actual program? I use mRemoteNG on windows, and the integrated rdp/ssh with a sidebar full of bookmarks is the dragon I’ve been chasing on linux.
If this had remmina and vnc, and could embed terminals, it’d be a huge feature jump in my book (though it’s already great as a better way to manage my ssh sessions)
As a sole developer I have to prioritize features due to the time constraints. While I would definitely like to implement support for everything you listed, this would be a lot of work. For example with terminals in general, it can be very difficult to get one up to the standards of other comparable terminals. By delegating everything to other terminals, I can make the development easier.
So in the long term future this might be added. But that also depends on the project’s trajectory going forward
For sure for sure. What is your preferred mechanisms for feature requests? Small things, like in the browser pane, could we get buttons to launch terminals directly in the connections tree on the left, so I can launch the terminal without having to open the file browser for that connection, or likewise, adding a link in the connections pane to jump straight into the file browser? I envision a workflow where I keep 1 view open and can launch into file browsing or terminal directly from that view.
You can send me feature requests either on GitHub, Discord, or mail, whatever you like.
Your proposed enhancements make sense, I can already think about how to add this the best way. And if you want to open a proper feature request and elaborate more on that, we can make that happen for sure.
Wow this is kind of a cool project. This is the first im hearing about it.
Will definitely check it out. Thanks for making it 🙂
Wow, yep. Totally trying this out. Currently I have a directory full of scripts to ssh into each of my servers. Kinda want to get rid of that.
Interesting, do you mind giving an example on what those scripts do? Why not just put the hosts into .ssh/config ?
Most of them are literally just “ssh name@host”, some of them open ssh proxies (I have a weird network setup)
Keep in mind, I didn’t search for any better way to do this before doing it.
Here is an alternative Piped link(s):
Piped is a privacy-respecting open-source alternative frontend to YouTube.
I’m open-source; check me out at GitHub.
I see an issue about providing sudo credentials that has been resolved as “implemented” but I can’t figure out where you do that for a connection that you’ve ssh’d into as a user.
Any pointers?
It uses the sudo credentials from the SSH connection, even if you don’t need to provide a password to login. So if you set a password for a SSH connection, it should use that for the sudo elevation.
Ah, OK. I thought that was just for the connection setup only.
Why would I want to use this instead of AWS Session Manager? I have a policy of no SSH enabled on any of my servers. Is this compatible with SSM connections too?
The screenshots are just sample connections, you can connect to arbitrary systems via SSH so it is not really a tool intended specifically for AWS.
Obviously if you are using taylor made tools for AWS by amazon itself, XPipe can probably not compete with that in terms of features. This is more of a general purpose application that you can use with any servers, virtual machines, containers, and more.
