Single window remote Linux applications: ssh -X vs xpra vs waypipe

Introduction

If you ever wanted to start a remote Linux GUI application such as Firefox, Chrome, file managers like Nautilus or Dolphin, some development IDE like VS Code or things like that you most probably have used ssh -X to login on a remote host and then started an application there and got the UI displayed on your local host. This is more or less the solution that always works.

While it works quite well it’s not really the fastest solution esp. if your remote host is only accessible via some slow Internet connection e.g. For me this use case isn’t that relevant. I’ve lots of virtual machines running locally. They run different UI applications like Firefox for various purposes or some VPN software e.g. So they are all on my local network - either a local VM (managed by virt-manager) or on a remote machine that runs within my local network. They’re all connected via a GBit network.

My main problem with this solution was always that sometimes the UI stuck. You can’t type anything anymore and have to wait a few seconds before it works again. Also the latency when typing is noticeable. So you type a character and then it takes a bit until you see that character on the screen. Using ssh -X for a temporary solution is fine. But using it all the time with lots of remote applications isn’t that much fun.

And of course there are lots of RDP and VNC based solutions out there. They also work quite well and also quite reasonable over slow connections. But most of the time you only get the full desktop and not just a single window with the remote application(s). This was a no-go for me. I really wanted to work with remote applications as they were local ones.

xpra

This brought me to xpra a few years ago. According to the homepage:

Xpra is an open-source multi-platform persistent remote display server and client for forwarding applications and desktop screens. It gives you remote access to individual applications or full desktops. On X11, it is also known as screen for X11: it allows you to run programs, usually on a remote host, direct their display to your local machine, and then to disconnect from these programs and reconnect from the same or another machine, without losing any state. It can also be used to forward full desktops, from X11 servers, MS Windows, or Mac OS X. Xpra also allows forwarding of sound, clipboard and printing services. Sessions can be accessed over SSH, or password protected over plain TCP sockets with or without SSL. Xpra is usable over reasonably slow links and does its best to adapt to changing network bandwidth constraints. Xpra includes a built-in HTML5 client, hardware acceleration, multi-user support, GUI tools and configuration and options; keyboard and clipboard synchronization; printer, cursor, sound, system tray and notifications forwarding; IPv6 support, SSL, support for shadowing existing displays, desktop mode, etc.

Xpra has served me quite well over the years on Archlinux and Ubuntu (22.04/24.04) and if you want to forward the UI of an application on a remote host with slow Internet connection it’s most probably still a very good solution. But it has some annoyances that hit me here and there:

• On Archlinux the package is always behind the current release. Sometimes for month.
• Xpra offers various codecs to compress the data stream between the two hosts. Xpra is developed in Python and it has quite a lot of dependencies with all the codes and algorithms it needs. And basically with every update, one codec or another wasn’t working anymore that I previously used. Luckily, other available codecs worked fine as fallbacks most of the time. But sometimes I had to wait a few days or weeks until this or that library was fixed and some functionality was working again. That’s of course also partly a problem if you use a rolling distribution like Archlinux.
• Getting the keyboard right was initially also an issue until I added --keyboard-layout=de and --keyboard-variant=nodeadkeys. But still some special keys were not working with VS code e.g.
• Normally if I put an application in some corner or want to have two applications side by side the windows “attaches” to the other one so that they’re really side by side. This “snapping” doesn’t work with Xpra. Not a big deal but a bit annoying.
• There were a few more minor issues like sometimes I had to downgrade Python packages because Xpra wasn’t working anymore.

To start Vivaldi web browser I used this command as an example:

xpra start ssh:remote-host-name \
  --keyboard-layout=de \
  --keyboard-variant=nodeadkeys \
  --microphone=disabled \
  --exit-with-client=yes \
  --clipboard=yes \
  --clipboard-direction=both \
  --daemon=no \
  --printing=no \
  --start-child=vivaldi

Xpra really offers a lot esp. if you want to keep the remote applications running, disconnect and reconnect again afterwards - like ‘screen’ for X11. It was also working fine after I upgraded from KDE 5.x to 6.x + Wayland and it’s still working fine with current KDE 6.5.

waypipe with KDE + Wayland

Recently I again had an issue with Xpra. Don’t remember anymore what it was. I was searching for alternatives for Xpra over the years but I always came back to Xpra because they didn’t work very well for me. But then I found Waypipe. And that was exactly what I was searching for 😄. From the docs:

waypipe is a proxy for Wayland clients. It forwards Wayland messages and serializes changes to shared memory buffers over a single socket. This makes application forwarding similar to ssh -X feasible.

Starting Vivaldi web browser on a remote host is now as simple as (I created an “alias” for this and a lot of other commands):

waypipe ssh remote-host-name vivaldi

will run ssh, connect to remote-host-name, and remotely run vivaldi, using local and remote waypipe processes to synchronize the shared memory buffers used by Wayland clients between both computers. Command line arguments before ssh apply only to waypipe; those after ssh belong to ssh.

Waypipe should be installed on both the local and remote computers. It’s mainly written in Rust and some C-bindings. Luckily for me Ubuntu 24.04 and 22.04 already offer a package and same for Archlinux. Of course you need Wayland running. In my case it’s KDE 6.x running on Wayland. The requirements are way less than for Xpra. It’s mainly ffmpeg, lz4, zstd and OpenSSH (obviously).

Running the command above for the first time already makes it obvious that the remote application startup is pretty fast (faster than with Xpra). Then the application really “feels” like it’s running locally. You don’t see much of a difference. It behaves like a local application and there is nearly no latency when typing. It doesn’t provide all the features Xpra has but for me it’s perfect. I’m really just using the command above for various applications without any tweaking or strange commandline options. Pretty awesome!

I’m really happy that I found Waypipe. If you’ve Wayland and need to run UI applications on a remote host in a single window locally that should behave and feel like a local application give Waypipe a try!