Today I can share a major development status update of XPipe, a 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, and more without requiring setup on your remote systems. You can also keep using your favourite text/code editors, terminals, password managers, shells, command-line tools, and more with it.
Docker compose
This release introduces support for docker compose. Containers in compose projects are grouped together and can be managed all at the same time via compose project entries.
The container state information shown is also improved, always showing the container state in combination with the system information.
Batch mode
There is now a batch mode available that allows you to select multiple systems via checkboxes and perform actions for the entire batch. This can include starting/stopping, automatically adding available subconnections, or running scripts on all selected systems.
You can toggle the batch mode in the top left corner.
Password managers
The password manager integrations have been upgraded:
There is now support for KeePassXC
All password manager integrations have been reworked to work out of the box without configuration
There is now support to use password manager SSH agents more easily
You can now unlock the xpipe vault with your password manager
Terminals
The terminal integration comes with many new features:
There is now built-in support for the terminal multiplexers tmux, zellij, and screen. This is especially useful for terminals without tabbing support.
There is also now built-in support for custom prompts with starship, oh-my-posh, and oh-my-zsh.
On Windows, you now have the ability to use a WSL distribution as the terminal environment, allowing you to use the new terminal multiplexer integration seamlessly on Windows systems as well.
SSH
Various improvements were made to the SSH implementation:
The SSH gateway implementation has been reworked so that you can now use local SSH keys and other identities for connections with gateways
The VSCode SSH remote integration has been reworked to allow more connections it to be opened in vscode. It now supports essentially all simple SSH connections, custom SSH connections, SSH config connections, and VM SSH connections. This support includes gateways
There is now built-in support to refresh an SSO openpubkey with the opkssh tool when needed
There is now the option to enable verbose ssh output to diagnose connection issues better
For VMs, you can now choose to not use the hypervisor host as SSH gateway and instead directly connect to the VM IP
Other
Connection names, e.g. VM names, will now automatically update on refresh when they were changed
You can now launch custom scripts within XPipe with a command output dialog window without having to open a terminal
Various installation types like the linux apt/rpm repository and homebrew installations now support automatic updates as well
The k8s integration will now automatically add all namespaces for the current context when searching for connections
The application window will now hide any unnecessary sidebars when being resized to a small width. This makes it much easier to use XPipe in a tiling window arrangement
The webtop has been updated to have terminal multiplexers, proper konsole tab support, disabled kwallet, and more
Various error messages and connection creation dialogs now contain a help link to the documentation sections
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 with limitations on what kind of systems you can connect to in the community edition 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, visit the Website, or check out the Docs for more information.
Giving it a quick scan, it does look interesting. I am not sure whether I will try it as I don't see the need to visualise beyond what I can do with a shell and the openstack dashboard, but there can definitely be use cases for it.
Not being FOSS is the deal-breaker though. Not sure if I am too much of a sceptic but I prefer open source when having software that accesses my private key/servers.
I think if you have a specialized tools with openstack, XPipe probably can't compete with that in that area. But it can make your life easier in a lot of other areas and common tasks when it comes to accessing many servers.
About the FOSS requirement, I know that this is a dealbreaker for some. That is a tradeoff when going the commercial route
Yes, it is absolutely valid that you decided to commercialise your project and keeping parts or all of the code closed. As I work in the public sector and we are encouraged to use open source and write open source software, my knowledge regarding closed software solutions is thin. Is there a "standard way" how closed software is able to guarantee private key safety? I could imagine solutions where there is a separate handler that is open source so that one can verify that only specific information is passed into the closed software area, but this doesn't sound feasible when talking about full terminal support within the closed software.
Again, there is nothing wrong with going commercial! I am sure I will release closed software (side projects), too, at some point.