I’m proud to share a development 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.
Here is how it looks like if you haven’t seen it before:
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.
XPipe 8 is this biggest update yet and includes many new features and changes that are necessary going forward to allow for future features to come. The versioning scheme has also been changed to simplify version numbers. So we are going straight from 1.7 to 8.0.
New terminal launcher
The terminal launcher functionality got completely reworked with the goal to make it more flexible and improve the terminal startup performance. You will quickly notice the new implementation whenever you launch any connection in your terminal. The new implementation allows us to start up a connection while the terminal is still opening, shaving off a lot of time.
File browser improvements
The file browser has been reworked in terms of performance and reliability. File transfers of many files are now faster, and any errors that can occur are now handled better.
In terms of the interface, there is also now a progress indicator for files being transferred. For any file conflicts, there is now a new dialog to choose how to resolve any conflict when copying or moving files.
Authentication improvements
This update comes with a newly created system for handling authentication that is better suited for arbitrary authentication prompts. This allows for better support for things like 2FA and other keyboard interactive authentications schemes. The sudo elevation authentication also has been reworked to be more intuitive and mirror the behavior of the system in regard to password prompts.
You also now have finer control over the caching behaviour of passwords and the sudo behaviour via additional settings.
Settings rework
This update comes with a complete rework of the settings menu. Many options have been added and existing ones have been improved, with a focus on providing more control over security settings. Make sure to give them a read to discover new options.
There has been a big focus on providing finer-grained control over security settings, which can be especially useful in enterprise contexts.
Kubernetes configs and namespaces
This update adds support to also add connections from other kubeconfig files.
Furthermore, you can also choose to use any namespace you want. This is useful in cases where you have not set up a context for every namespace you have.
Temporary containers
You can now run a temporary docker container using a specified image that will get automatically removed once it is stopped. The container will keep running even if the image does not have any command specified that will run.
This can be useful if you quickly want to set up a certain environment by using a certain container image, e.g. a simple ubuntu image. You can then enter the container as normal in XPipe, perform your operations, and stop the container once it’s no longer needed. It is then removed automatically.
Quick access for connections
One common feedback that some users shared was that it could be quite cumbersome to access a specific nested connection as one would have to possibly expand several connections first. Expanded connections would then also take up a lot of space, leading to a lot of scrolling.
There is now a quick access button available for connections that enables you to quickly choose a connection in the hierarchy without having to expand any connection views.
Other changes
- Add support for PowerShell on Linux and macOS
- Add ability to easily add custom files to the git vault
- Improve git vault performance
- Fix scaling issues on Linux by providing a separate scaling option
- Many more bug fixes
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.
The system is designed to allow for unlimited usage in non-commercial environments and only requires a license for more enterprise-level environments. This system is never going to be perfect as there is not a very clear separation in what kind of systems are used in, for example, homelabs and enterprises. But I try my best to give users as many free features as possible for their personal environments.
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. Next up is probably RDP/VNC support. 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 love the app, I have been using it in a personal setting and I think you deserve to make money from it.
As I was thinking about purchasing a professional license to support you I noticed an issue.
The the 1 year update limit for the “one time purchase” option is extremely preditory and annoying.
This is especially bad because it is hidden in the faq and the pricing overview itself suggests the opposite “Receives regular feature and security updates (See details)” without a mention of a 12 month time limit.
The only real option for a user is then to buy it every year over and over again… which is contrary to the wording around it, that it is a “purchase once” transaction.
I suggest the following:
-
Make it a full yearly subscription option, which would still be attractive because it is cheaper than monthly and call it such.
-
Create a real one time purchase option for professional individuals for ~300€ and include all future updates.
-
Seperate everything by creating a one-time pay for unlocking features and a subscription for receiving updates and clearly label them as such and make both slightly cheaper, since one doesn’t include the other. Also allow for either yearly or monthly payment for the update subscription. But that seems like the most unusual and confusing way to go about it.
You can do either one any combination of those three, or come up with something else entirely but please please please fix this predatory scam-like pricing mess, so that I can feel relaxed and happy (instead of angry, annoyed and disgusted) when I am thinking about giving you my money.
Maybe I have to improve the wording on that, you are right.
The idea is based on the established model of other applications, where you buy a license for a certain version. If a new major version releases in that case, you will probably not access to that with your old license. Even if you are perfectly happy with the version you bought, the issue of that model is that you will also miss out on important bug fixes , security patches, and normally free enhancements as older versions are no longer supported.
XPipe tries to find a compromise here. There is the same build for everyone, which is receiving continuous updates and support. The are no hard version barriers, it’s a continuous development. The licensing system paywall is therefore very artificial in that the build contains all features but it will not allow for usage of professional-only features released after more than one year after your license date. You can keep using all professional features that were included before forever. The important part is that you will still receive updates as anyone else, you just can’t use new professional-only features that are included in them if more than one year has passed. But you will receive bug fixes and security updates even if you own an ancient license.
Thank you for the reply.
I am familiar with the model, but I always found it very slimy and offputting, even if it is properly explained and worded (which it often is not to trick people). It is a model more suited for fully proprietary apps I feel, or at least I personally never saw it on anything (partially or fully) open source. I don’t think it fits the spirit.
Regardless of your decision, thank you for developing this helpful app and I wish you all the success.
I see you edited your original comment since last time, so I can augment my answer.
I could definitely include a lifetime purchase option for a certain price, but I was skeptical whether people would actually be interested in something like that, mainly due to the potential price difference. I honestly thought that the current model would be better received by potential customers as it is more a pay only what you use model while also keeping access. I did not expect that anyone would actually be interested in a lifetime license. But to be fair, the payment model was designed back when the application was in an earlier development stage and didn’t even work properly for like 50% of users.
I will definitely rework the website to better get the point across on how continuous updates are handled as there is no intention to make it a predatory model. Then I will reevaluate the licensing model.
Sorry about the editing. I am always writing like that, where I re-read and improve the text until I am happy. I think I edited this one about 8 times… haha
I am of course just one user with my own preferences, so other options are up to your own judgement.
I think I’ll get the yearly professional license for now and in a year or so I’ll check out if there are any new options. (will buy next week, just fyi so you don’t think I lied lol)
And again, thank you for your hard work. I really love using xpipe.
Alright, the pricing options and website have been updated. It should now get the point better across about how updates are handled and what you actually get. The fundamental approach has not changed but it should make less of a predatory first impression.
There’s also a lifetime option now, which you can find in the pricing FAQ. It is not put into the spotlight because I think showing very expensive options is a bad business decision, especially when it comes to first impressions.
I’ve read through the pricing and the FAQ and I find it very clear and easy to understand now!
-
I decided to give it a shot and it seems very nice. You’ve got to get a handle on the amount of resident memory it’s using though. I haven’t done anything other than set up some ssh connections and it’s using more RAM than most things on my computer. 242MB.
Yeah there is always the JVM overhead which is unavoidable here. That, plus all the images which are preloaded into memory to reduce any loading time at runtime, sum up to that base amount of RAM being used.
First I’m hearing of this, but seems very promising! This might be an out of scope question, but gonna try asking anyway. I have an Unraid server, would it be possible for me to run Xpipe on my desktop and have it connect to all my running docker containers on my Unraid server?
Best of luck forwards with the development 🙌
Yes, that is how it is intended to be used. Assuming that you can easily connect to your server via something like SSH, you should have access to all docker containers running on it.
Damn, that’s neat! Started reading the Github last night, will defo give this a try over the weekend. You’ve got a 🌟 from me sir!
Are there plans for adding this as a flatpak?
Sadly this is not possible due to the flatpatk sandbox, at least without having to rewrite basically the entire application. You can’t open other applications or shells from the sandbox, so nothing would work.
Someone told me that it is possible in theory to reduce the level isolation of the sandbox via flatseal, but that would require the user to perform additional operations to make it even work. If it is not going to work out of the box, a flatpak version would not make a lot of sense.
Ah yeah that makes sense! Thanks
I’m pretty sure the sandbox level is chosen by the developers of any given application. Flatseal only exists for users to change the sandbox settings the developers have chosen.
Yes, the developer can choose a few sandbox permissions, however these options are limited. Even if I grant all permissions, I still can’t spawn a bash process from my flatpak application. Flatseal can grant additional sandbox permissions to allow that, but these options are not exposed for the developer.
