There are certainly some similarities, i.e. you use both to connect and work on your remote systems. However, the main difference is that XPipe does not come with integrated connection capabilities or an integrated terminal. Everything is delegated to your tools, i.e. XPipe for example connects via your installed ssh command-client and launches the terminal emulator you choose, nothing is included in the application itself.

On a more fundamental level, XPipe is not aware of any protocols like SSH, SFTP, FTP, and more. Instead, XPipe creates a new process using for example your local ssh executable, which is usually the OpenSSH client. I.e. it launches the process ssh user@host in the background and communicates with the opened remote shell through the stdout, stderr, stdin of the process. From there, it detects what kind of server and environment, e.g. shell type, os, etc. you have logged into with that shell connection, and adjusts how it talks to the remote system from there

As a result of this approach, you can do stuff with XPipe that you can't do with other tools like MobaXterm. One example would be connecting and accessing files on a docker container as there's no real protocol to formally connect here by default. XPipe can simply execute docker exec -i sh to open a shell into the container and handle the file management through this opened shell by sending commands like ls, touch, and more.

More broadly, XPipe can work on any shell connection, regardless of how it is established. From its perspective, there's no visible difference between a remote ssh connection, a shell in a docker container, or your local system shell.

Furthermore, MobaXterm is Windows only while XPipe is cross-platform.

What do you refer to here? The UI or something else? I haven't heard the word gooey being used to describe an application before, but I'm also not a native speaker.

You get a fancy overview over all your remote connections and don't have to type anything to establish shell connections in your terminal, you get launched into the session with one click, so it gives you an overview over your server infrastructure and saves you some typing effort.

Also you can access the file system of any connected remote system via a graphical user interface, but I guess that is personal preference whether you would like to use something like this or not.

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.

There is an optional automatic update check included that will notify you when a new version is available. You can also automatically install the new version through that, but that is up to you.

For NX, I assume you're talking about this: https://www.nomachine.com/. I would have to look into that, it depends on how open the protocol and platform is. Without looking too much into it, I would assume it has some basic open component but since there is a company involved, there's probably some proprietary vendor lock in. It's probably the same as with VNC where there is an open protocol spec, but RealVNC also develops their own closed spec to lock out any third party clients from interacting with their tools.

Overall, XPipe makes it much less tedious to connect and access remote systems wherever they are located, especially if you have to go through multiple intermediate systems in between. Once you added a system to XPipe, you can just connect to it with your favorite terminal in one click just as you would do manually and also browse the file system. Having a graphical overview over all available remote connections and their file systems can make your life easier, especially if you work with many different remote systems, containers, clusters, and more.

If you just regularly connect to two simple servers via SSH, then you probably won't get that much use out of this. But if you have many servers, gateway servers, containers, and other subsystems running, then it will make your life easier.

Yes, the community edition doesn't have any limitation.

For paid plans, it's relative to the average usage and activations across all licenses. E.g. if you, as an enterprise, purchase licenses for 5 users, but have a usage like other customers with 20 users, I might inquire about how you are using it. If it is a special case where you install and use it on many servers and VMs in parallel, this can be taken into account and the limits can be adapted. But in general, the license limits are permissive and do not interfere with your usage.

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.

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.

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.

It is a frontend for standard CLI tools yes, but it comes with many additional features. The focus is especially on integrating standard CLI tools with your desktop environment and other applications that you use like editors or terminals.

For example, of course you can just use the ssh CLI to connect to your server and edit files. But with XPipe you can do the same thing but more comfortably. You can source passwords from your local password manager CLI, automatically launch terminals with the SSH session, edit remote files with your locally installed text editor, and more.

Of course you can do this also with tools like putty, but the difference here is the integration. Other tools ship their own SSH client with its own capabilities, features, and limitations. They also have their own terminal. XPipe preserves full compatibility with your local SSH client and terminal. E.g. all your configuration options are properly applied, your configs are automatically sourced, any advanced authentication features like gpg keys, smartcards, etc. work out of the box.

The same approach is also used for the integrations for docker, podman, LXD, and more, so you can use it for a large variety of use cases.

So the vision is that this is only a connection hub, essentially a mediator that brings together your tools like terminals, editors, command-line clients and more. XPipe itself doesn't have an SSH client, it just uses your locally installed one. Same goes for text editors, terminals, password managers, git clients, browsers, and more. It doesn't replace anything, it works with your tools.

About unifying GUI access for your homelab, I guess that is personal preference. Some people like a gui-based workflow, some do like a more terminal focused experience. But with XPipe you can get both. You can use it as a quick terminal launcher if you don't want to use any of the other GUI functionality. For example, if you are a frequent SSH user, see my other reply: https://sh.itjust.works/post/31552343/16245994 on how it can make your life easier. You can try it out for a few minutes to see how it works for you, you can get started very quickly and there is no setup required on any servers. There's no commitment here.

If you like automation, there is also a built-in HTTP API (which you have to enable first). You can automate almost anything with that. The documentation for that is available here: https://github.com/xpipe-io/xpipe/blob/master/openapi.yaml and if you like python, there is also https://github.com/xpipe-io/xpipe-python-api

For the professional use case, the same concept of a connection hub apply here. XPipe doesn't manage your keys, you can use whatever storage format or SSH agent configuration you want. If you use a password manager in your organization, you can connect that to XPipe and have XPipe itself not store any secrets. In terms of transit security, it just forwards everything to your locally installed SSH client for example. If you care about all the security details, you can find them at https://xpipe.io/assets/documents/Security%20in%20XPipe.pdf .

You can deploy this in your organization with whatever tools you use. Maybe the .msi with intune, or some other management tool for Linux and macOS. There are standard installers available for every use case. These can also handle updates, so if you disable automatic updates within the app and instead want to manage that yourself, you can use the installers to upgrade installations in-place with the latest releases from GitHub.

About the data storage and usage, if you want to use shared vaults in your organization, these are all handled via your own git client and git remote repositories. You can host them wherever you want. You get a full history of who did what in that vault with git automatically.

Perhaps you are thinking of MobaXTerm?

X11 forwarding is as secure as your SSH connection as everything is handled over that as long as you trust the system you connect to as it can send some X11 commands to the client. VNC by itself is insecure but XPipe tunnels all VNC connections via SSH as well, so it is secured as well. With RDP, I would argue that there are less sophisticated authentication options available for RDP than for SSH.

I think moonlight and sunshine are intended for gaming while this more intended for server administration tasks.

It's not really related at all.

It is basically a graphical wrapper around your CLI tools like ssh, docker, kubectl, and more that gives you the features you know from tools like graphical SFTP clients but supports much more types of connections and allows you to use your favourite terminal and editor for your remote connections.

Yeah I did not downvote you, feel free to take a dive into the data if you really care about that.

I think your analogy about the cars can be augmented a bit. I would say that individual components like VNC are not really a car to begin with. VNC is an insecure protocol by default. Technically there are VNC security measures to potentially encode the data, but these are often not used*. Furthermore, even if you encrypt the data stream, VNC authentication options are severely limited. So something like VNC needs to run over something like a SSH tunnel to be considered properly secure. And to properly do that, you need an SSH integration as well. That is one example where these synergies happen in XPipe.

• Technically there is loads of proprietary stuff that tools like RealVNC do to increase security, but that cannot be considered the open VNC standard.

I think in the end you still have to exercise some trust. There are things like audits, but these are costly and not an option in the current stage. Maybe in the future. Best I can do is to provide transparency by open-sourcing large parts of the codebase and providing detailed security information like https://docs.xpipe.io/reference/security.

As someone who sometimes sells to the german public sector, it is true that they would prefer a good open source solution if it was available. But me being a german vendor makes up for it, as they still prefer this a lot more over any US-based vendors.

In general about the key handling, XPipe doesn't read any kind of keys itself, it only forwards them to the local OpenSSH client. It is essentially a wrapper around in existing ssh client, and doesn't implement anything related to key handling itself.

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.

Can you elaborate on what you mean by your problem with opening multiple terminal windows? I am not aware of such an issue, so maybe you can report it on GitHub with a few more details

Do you use the normal one or the FIPS one? Maybe I can use that to differentiate between personal and commercial use

Yeah I can do that

You can if you're interested in any status updates