Xpra: Persistent Remote X11 Applications Without Losing State

The problem Xpra solves: applications that outlive the connection

A normal X11 forwarding session over SSH ties the life of the remote program to the life of the SSH connection. Close the laptop lid, lose Wi-Fi, or switch to a different desk, and the process is gone along with any unsaved work. Xpra separates those two lifetimes. The README describes it as "screen for X", and the seamless mode is the part that matters: you run an X11 program on a remote host, its display is directed to your local machine, and you can "disconnect from these programs and reconnect from the same or another machine(s), without losing any state".

The intended user is someone who needs one graphical application, not a whole desktop. A developer running an IDE or a terminal on a build server, an engineer who needs a licensed Linux-only tool from a Windows laptop, an administrator who wants to attach to an application that has been running for days. The README also covers the other two shapes of the problem: shadow mode for viewing an existing desktop session, and desktop mode for starting a new remote desktop session. So the project is not purely application-level, but the application-level case is what distinguishes it from a VNC or RDP setup.

One design consequence is worth stating plainly. The README says xpra must be installed on both the client and the host. That is a heavier requirement than plain SSH X11 forwarding, where only the server side needs anything. The escape hatch is the built-in HTML5 client, in which case the README states xpra is only required on the host.

How the forwarding and reconnection actually work

The architecture visible in the repository is a Python server process on the host that owns an X11 display, plus a client that speaks the same protocol. The server does not merely relay raw X11; the README lists a set of desktop features that are forwarded and synchronized so that remote applications integrate into the local desktop environment: audio input and output, printers, clipboard, system trays, notifications, and webcams. It also states that xpra opens documents and URLs remotely, displays high bit depth content, and tries to honor the display's DPI.

That synchronization layer is the reason a remote window can look like a native window. The README's own screenshot caption makes the point: the windows may look native, but they are running on a remote Linux server. The cost is that the server has to understand each of those subsystems, which is a much larger surface than a pixel-streaming protocol.

On the network side, the README says a single TCP port can carry many connection types: SSL, SSH, secure HTTP and websockets, RFB, and others. Connections can be secured with encryption and authentication modules, sessions can be announced on a LAN using multicast DNS so a GUI client like xpra mdns-gui can find them, and there is a proxy server that can act as a relay or front end for multiple server sessions. The README claims xpra adapts to network conditions, but it does not quantify that, and no benchmark figures appear in the repository.

The packaging reflects the modularity. pyproject.toml declares an empty core dependency list and puts the network and printing pieces behind optional extras such as gui and cli, with entries including asyncssh, paramiko, pyopenssl, cryptography, uvloop, aioquic, zeroconf, cups and psutil. In other words, a minimal install is not the same as a full-featured one, and the extras you choose determine which protocols and forwarded features are actually available.

Installing Xpra and running a first seamless session

The README points at signed official packages rather than a package-manager command. For Microsoft Windows it links an EXE, a ZIP and an MSI under xpra.org/stable/windows/. For macOS it gives separate x86_64 and arm64 DMG and PKG files. For Linux it links to RPM and DEB instructions on the project wiki rather than listing repository commands, so the exact package name depends on your distribution and is not stated in the README. LTS and beta builds are offered separately.

If you prefer to build from source, the README gives this two-line sequence. It clones the repository and runs the setup script with python3:

git clone https://github.com/Xpra-org/xpra; cd xpra
python3 ./setup.py install

Be aware that setup.py performs its own version check and raises a RuntimeError if the interpreter is older than Python 3.10, which matches the requires-python value in pyproject.toml. Building also pulls in setuptools and cython through the build-system requirements, and the setup.py header carries an explicit FIXME about Cython leaving files behind in the source directory. That is a build-hygiene wart, not a functional problem, but it means the source tree is not left pristine.

Once installed on both ends, the README's first real example starts xterm on the remote host and displays it locally:

xpra seamless ssh://USER@HOST/ --start=xterm

The README adds a hint that xterm must be installed on the host, which is the failure you will hit first if the remote machine is minimal. Substitute USER and HOST with your own values. If you want to attach to a desktop that is already running rather than start an application, the README gives shadow mode as a single command:

xpra shadow ssh://USER@HOST/

After either command, the expected result is a window on your local desktop that behaves like a local window, with the clipboard and other forwarded features wired through. The README does not document a rollback or teardown procedure for a session, so plan on reading the usage documentation for how sessions are listed and stopped.

Where Xpra is the wrong choice

The clearest limitation is the one the README states as a requirement: xpra must be installed on the client and the host. If you cannot install software on the client, for example on a locked-down corporate laptop or a borrowed machine, the native clients are not an option. The HTML5 client removes that constraint on the client side, but then you are relying on a browser and on the server's web stack instead of a native client.

The second limitation is the server platform. The README describes xpra as forwarding X11 programs and lists clients for many platforms, but the installation section offers packages only for Windows and macOS clients and for Linux RPM and DEB systems. Nothing in the README describes running the server on Windows or macOS. If your remote host is a Windows machine and your goal is to forward Windows applications, this is not the tool the README describes.

Third, the feature set is broad but the README makes no performance commitments. It says xpra does its best to adapt to network conditions, which is a statement of intent, not a guarantee. For latency-sensitive interactive work over a poor link, a protocol that forwards a smaller set of features may behave differently, and the README gives you no numbers to compare against.

Finally, the licence is a real consideration for some deployments. The project is GPLv2 or later, and pyproject.toml declares GPL-2.0-or-later with the COPYING file. If you intend to embed xpra inside a proprietary product or ship a modified server under different terms, the copyleft obligations apply and you should have that reviewed rather than assumed.

How Xpra differs from VNC, RDP and plain SSH forwarding

The obvious alternative for remote graphical access is VNC, and the difference is structural. VNC forwards a framebuffer: the server owns a display, and the client receives pixels. Xpra's seamless mode forwards individual applications and synchronizes desktop services around them, so a remote xterm appears as a window inside your existing local desktop rather than as a rectangle containing a whole remote screen. That is a different user experience, and it is the reason the README calls the mode seamless.

Plain SSH X11 forwarding is the closer comparison on the mechanism side, and the difference is lifetime. SSH forwarding is a tunnel for X11 protocol traffic; when the tunnel drops, the client's connection to the X server is gone. Xpra keeps state on the server and lets you reconnect from the same or another machine. If your sessions are short and your network is reliable, SSH forwarding is simpler because it needs nothing on the client beyond an X server. If your sessions are long or your network is not reliable, that simplicity is exactly the problem.

RDP is the comparison for the shadow and desktop modes. RDP is a full-desktop protocol on Windows and is widely deployed, but it is not designed around forwarding an individual X11 application into a Linux desktop. Xpra's shadow mode covers the existing-desktop case, and desktop mode covers starting a new one, so there is overlap. The README also notes that the server can accept RFB connections, which means a VNC client can talk to an Xpra server in some configurations. That is a useful bridge, but it also means you can end up with VNC's pixel-level behaviour and Xpra's server complexity at the same time.

Maintenance, releases and the upgrade path

The repository is not archived, and the last push was on 2026-09-23, which is recent. The release history shows v6.5.3 on 2026-08-18, v6.5.2 on 2026-07-27, and a v5.1.6 on 2026-07-03, so the project maintains both a current line and an older one. The README also points at separate LTS and beta build channels, which means an operator can choose stability over recency, but it also means you should decide which channel you are on before you deploy, because mixing them across client and server is an untested combination as far as the README goes.

Upgrade cost is the part the README does not address. There is no documented procedure for upgrading a running server without disrupting sessions, and no compatibility statement about whether a v6 client can attach to a v5 server or vice versa. Given that persistent sessions are the entire point of the project, that silence matters: if you build a workflow around sessions that live for weeks, you need to know what happens to them when the server package is replaced. The documentation site is the place to look, and the README explicitly says the documentation for the current development version is included with each release, so a version-matched copy should be on hand.

On licensing, the GPL-2.0-or-later terms are stated in both pyproject.toml and the COPYING file that ships in the repository. Redistribution and modification carry obligations, and the README offers no separate commercial licence or exception. Treat that as a constraint to check against your own distribution plans, not as legal advice.

There is also a contributor-side cost. The README asks contributors to use pull requests and follow the code of conduct, and the repository carries a pre-commit configuration, a sonar-project.properties file, and a test workflow. Those are signals of process, not of quality, but they do tell you that patches go through review rather than landing directly.

Editorial conclusion

Adopt Xpra if you need individual X11 applications to survive a dropped connection and reappear on a different machine, and you accept that both ends need the software unless you route through the HTML5 client. Skip it if you only need a full remote desktop with no per-application control, or if your target host is a stock Windows or macOS box, since the README describes the server as an X11 forwarding system and offers no Windows or macOS server package. Verify first that your host has the X11 application you intend to forward (xterm is the README's own example), and check the installation page for your distribution before assuming a DEB or RPM exists.

Frequently asked questions

Official sources

1. License: GPL-2.0
2. Project website
3. README
4. Releases
5. Xpra-org/xpra on GitHub