LinuxDoors AppImage Store

One file. Download and run.

Each of these is a single self-contained executable — the whole application plus the runtime it needs — that you download, mark executable, and run. Nothing to install, nothing left behind, and it runs the same on Debian, Ubuntu and other Linux distributions that can launch an AppImage.

Some are LinuxDoors' own work. Others are trusted upstream builds — we mirror them here unmodified, so you can get them from the same place as the rest of the system, each with a SHA-256 you can check against the project's own. Every app shows who made it and where it really comes from.

LinuxDoors Games Games have their own shelf — 4 games, free, one file, download and play. Browse Games →

A recommended way imho to keep AppImages

This is Stan Switaj’s recommendation for how per-user AppImages should be stored — a tidy layout for the ones you download from the Store, with a real Desktop launcher for each.

One folder per user. Every AppImage a user keeps lives in ~/AppImages/ — for the default account, /home/linuxdoors/AppImages/. The AppImage files sit directly in that folder: /home/linuxdoors/AppImages/FlashScp.AppImage, and so on for every other one.

One subfolder, for icons only. That folder holds exactly one subfolder, images/, and nothing else. Each AppImage’s icon goes there as a PNG: /home/linuxdoors/AppImages/images/FlashScp.png.

A Desktop launcher per AppImage. For each one, a launcher is placed on the Desktop. Its Exec= line calls LinuxDoors’ own AppImage runner — Exec=linuxdoors-run-appimage /home/linuxdoors/AppImages/FlashScp.AppImage — and its icon comes from the matching PNG (Icon=/home/linuxdoors/AppImages/images/FlashScp.png), so the Desktop shows a real, recognizable icon for launching the program instead of a generic one.

Why the runner. LinuxDoors has no FUSE, so an AppImage unpacks itself before it starts; and /tmp is cleared on every reboot, so a bare Exec= path re-unpacks the whole app on the first launch after each boot — several seconds with nothing on screen, which reads as “I clicked the icon and nothing happened.” linuxdoors-run-appimage (in /usr/bin, on every LinuxDoors install) unpacks into a persistent ~/.cache/appimage-run/ instead — so each AppImage unpacks once, ever, every later launch is instant, and that one first run shows a “Starting… unpacking” notification. You can still run any AppImage directly; the runner is just the friendlier path for a Desktop shortcut.

In short: ~/AppImages/<Name>.AppImage for the program, ~/AppImages/images/<Name>.png for its icon, and a Desktop launcher (Exec=linuxdoors-run-appimage …) wiring the two together.

No terminal? Here’s the same thing with a mouse

An AppImage has to be marked executable before it will run — normally a one-line chmod +x in a terminal. Every graphical file manager offers the exact same switch from its Properties dialog, with no terminal needed. These are real screenshots from a LinuxDoors desktop (Thunar, LinuxDoors’ default MATE file manager), using LinuxUltraOffice.AppImage right after downloading it as the example.

1Right-click the downloaded file. Right-clicking LinuxUltraOffice.AppImage in a file manager shows a context menu with Properties at the bottom In your Downloads folder (or wherever you saved it), right-click the .AppImage file. Look for Properties near the bottom of the menu — it's on every mainstream Linux file manager (Thunar, Caja/Nautilus, Dolphin, PCManFM-Qt), though the exact wording of the checkbox in step 3 can vary slightly by file manager.
2Open the Permissions tab. The Properties dialog for LinuxUltraOffice.AppImage, showing General, Emblems, Highlight and Permissions tabs The Properties dialog opens showing file details first (name, size, kind, dates). Click the Permissions tab along the top.
3Find the “run as a program” checkbox. The Permissions tab, unchecked, showing the Allow this file to run as a program checkbox with a security warning below it Down near the bottom, under Program:, there's a checkbox — on Thunar it reads “Allow this file to run as a program” (Caja/Nautilus phrases the same checkbox as “Allow executing file as program”). It starts unchecked on a fresh download, and the file manager shows a short security note under it — worth reading once: only mark a file executable if you trust where it came from.
4Check it, then close. The same Permissions tab with the Allow this file to run as a program checkbox now checked Check the box and close the dialog. That's the whole procedure — it takes effect immediately, the same way chmod +x does from a terminal, because it is chmod +x: the file manager is just setting the same executable bit through a checkbox instead of a command. Double-click the AppImage from here on and it runs.

If a checkbox for this isn't where you expect, look for an Executable or Permissions section in whatever your file manager calls its Properties/Info panel — the control is universal on Linux desktops even where the exact wording differs.

On LinuxDoors’ optional MATE desktop, the default file manager is Caja instead of Thunar — same idea, slightly different dialog. These are real screenshots from a LinuxDoors desktop using Caja, walking through an .AppImage right after downloading it.

1Right-click the downloaded file. Right-clicking an AppImage in Caja shows a context menu with Properties at the bottom In your Downloads folder, right-click the .AppImage file and choose Properties near the bottom of the menu.
2Open the Permissions tab. The Properties dialog in Caja, showing Basic, Emblems, Permissions, Open With and Notes tabs Caja’s Properties dialog opens on the Basic tab (name, type, size, location). Click Permissions along the top.
3Find the “Allow executing file as program” checkbox. The Permissions tab in Caja, unchecked, showing owner/group/others access plus an Allow executing file as program checkbox Down under Execute:, Caja phrases the same checkbox as “Allow executing file as program”. It starts unchecked on a fresh download.
4Check it, then close. The same Permissions tab in Caja with the Allow executing file as program checkbox now checked Check the box and close the dialog — the file is executable immediately, the same chmod +x effect as Thunar’s checkbox above, just under Caja’s own wording. Double-click the AppImage from here on and it runs.

1 of 20 AppImages match.

X2GoClientWayland icon

X2GoClientWayland$0.00

Open code, fair pay

The source stays open — free to read, build on and share. A price, where there is one, is not for the code as that is opensource. It is for the work around it: the servers and bandwidth that carry the download to you, and the hours a programmer spent designing, building, testing and looking after the app — hours that support them and the people they love, the same as any other profession in the workplace economy.

A share of what the paid apps earn goes back to the Linux and free-software projects they are built on. That community gave its work away so all of this should exist; paying the people who keep it alive is how it stays alive.

Anything marked $0.00 is exactly that — free, no asterisk.

The real x2go client for LinuxDoors' Wayland desktops -- GNOME 51 and KDE Plasma 6.8 over VNC -- in one portable file.

from LinuxDoors.com · created September 19, 2026

A LinuxDoors AppImage Software Product

↓  Download X2GoClientWayland.AppImage ↓  Source Download .tar.gz (2.7 MB) icon (.png) Version 4.1.2.3  ·  206.0 MB  ·  29 downloads  ·  single file, download and run
SHA256 e0b4b4824ee8c70473c2df97fe28250349082e83c70aee6a252818c13af6991d
X2GoClientWayland is a real build of the X2Go project's own client, patched by LinuxDoors with two genuine session types for desktops that no longer have an X11 session at all: "GNOME 51 (VNC)" and "Plasma 6.8 (VNC)". LinuxDoors runs those desktops headless on the server -- GNOME 51 behind gnome-remote-desktop, Plasma 6.8 behind krfb -- and this client is what reaches them: pick the session type, point it at a LinuxDoors machine with gnome51-desktop or plasma68-desktop installed, and it opens an SSH tunnel straight to that VNC server, no login-screen session menu involved. Every other x2go session type (a normal X11 desktop over nxagent) still works too -- this is a complete x2goclient, not a stripped-down connector. It replaces X2GoClientGnome51Vnc (same client, now with Plasma 6.8 added). Download it, make it executable, and run it -- nothing else to install.
chmod +x X2GoClientWayland.AppImage ./X2GoClientWayland.AppImage # on LinuxDoors (no FUSE): ./X2GoClientWayland.AppImage --appimage-extract-and-run # or via linuxdoors-run-appimage, which unpacks it once rather than on every launch
Packaged by LinuxDoors. X2GoClientWayland is assembled by LinuxDoors from the real X2Go project's own x2goclient source (GPL-2.0-or-later), ported from Qt5 to Qt6 and patched with two new session types, "GNOME 51 (VNC)" and "Plasma 6.8 (VNC)" -- a real, from-scratch feature covering the whole connection: an SSH tunnel to the remote VNC server (gnome-remote-desktop for GNOME 51, krfb for Plasma 6.8), a genuine interactive Qt6 VNC viewer widget (mouse, keyboard, live cursor, auto-reconnect through an in-session resolution change), an in-desktop resolution picker, and a real Terminate/Suspend path that actually ends the remote session instead of erroring out. It is not affiliated with or endorsed by the X2Go project. The SHA-256 above is authoritative. It carries its own glibc, GTK, Qt6 and NSS/SSH stack, so it runs on a machine with nothing installed -- built for LinuxDoors, tested on Debian 13.

Real session types, not a workaround

GNOME 51 and KDE Plasma 6.8 both removed their X11 sessions, so nxagent -- the X11 remote-display technology every other x2go session type relies on -- can never show them. "GNOME 51 (VNC)" and "Plasma 6.8 (VNC)" are genuine session types added to this client: choosing one runs the matching remote script (linuxdoors-gnome51-vnc or linuxdoors-plasma68-vnc) over the same SSH connection every other session uses, opens a local tunnel to the resulting VNC server, and hands off to a real, interactive Qt6 VNC viewer built into this same client -- mouse, keyboard and a live cursor. The Plasma 6.8 server listens on the remote machine's own loopback only, so it is reachable solely through that SSH tunnel.

Change resolution without reconnecting by hand

A headless GNOME 51 or Plasma 6.8 desktop has exactly one fixed resolution for its whole life -- there is no live multi-mode display to switch between. This client's own "Change Resolution..." session-menu action restarts the remote desktop at a new size over the same connection and reconnects the viewer automatically once it's ready, so a resize is a menu click, not a fresh login.

Terminate and Suspend that actually work

GNOME 51 (VNC) and Plasma 6.8 (VNC) sessions don't fit the normal x2go session-ID model, so the stock Suspend/Terminate actions never applied to them correctly. This client sends a real remote stop command instead, then watches the actual client process (not just a flag) to confirm the session really ended before reporting success -- clicking Terminate once genuinely ends the session and returns you to the connect screen.

Running it -- nothing to install

Download the AppImage, make it executable, run it. On LinuxDoors, which has no FUSE, run it the way LinuxDoors runs any AppImage: ./X2GoClientWayland.AppImage --appimage-extract-and-run, or through linuxdoors-run-appimage, which does that for you and unpacks it once rather than on every launch. It carries its own glibc, Qt6, GTK and SSH/VNC stack. A portable AppImage does not update itself; when there is a newer build, download it here, or install the x2goclient-wayland package with pkg / the LinuxDoors Package Manager, which keeps it current.

Prefer the package manager? X2GoClientWayland is also an installable LinuxDoors package — x2goclient-wayland — which uses the copy of Python and Qt already on your system instead of carrying its own.

Written for LinuxDoors, though nothing in it is specific to LinuxDoors -- it runs on Debian- and Ubuntu-type systems (tested on Debian 13, glibc 2.41), and on any other reasonably recent Linux distribution that can run an AppImage. Only the GPU/display-driver libraries come from the host.