Linux: three shapes from one x86_64 binary, the same dvv on every machine

DeskVNC ships Linux the way a tool that respects the ecosystem should: as a deb for system installs, an rpm for Fedora and RHEL, and an AppImage that runs anywhere an x86_64 user can drop a file. The same Rust core, the same MCP server, and the same Secret Service backed credentials on every shape.

One x86_64 binary, three install shapes

The Linux release page carries the same x86_64 binary in three forms, and the project tests all three before any release, so the loop and the lease behave the same whichever shape you unpack.

Each shape is verified together before any release, so the macOS build, the Linux deb, and the AppImage share one verified path.

The install commands

Pick the line for your distribution. Each one installs the same upstream binary:

sudo apt install ./DeskVNCViewer_<version>_amd64.deb            # Debian, Ubuntu
sudo dnf install ./DeskVNCViewer-<version>-1.x86_64.rpm         # Fedora, RHEL
chmod +x DeskVNCViewer_<version>_amd64.AppImage                 # anywhere else
./DeskVNCViewer_<version>_amd64.AppImage

The AppImage needs FUSE to mount its image. On a system without FUSE, extract the AppImage and run the entry point directly:

./DeskVNCViewer_<version>_amd64.AppImage --appimage-extract
./squashfs-root/AppRun

Where dvv lands on each shape

The path of dvv depends on how DeskVNC was installed. A system install lands it on the system path so every shell and every agent on the box can find it. The AppImage copies dvv into the user's data directory so a registered agent can pick it up after a restart.

The per user vs system question is a property of the install shape, not a choice. A deb installs under the system path so multiple users on the box share one binary. An AppImage runs as the user who launched it and lives entirely in that user's data directory. The tarball is whatever you make of it: extract it anywhere and point an agent at the dvv inside.

The AppImage path is the result of the working directory quirk, not a misplacement. The AppImage's working folder is a FUSE mount that disappears when the app exits, so dvv is copied to ~/.local/share/DeskVNCViewer/bin/dvv on first run, and that is the path an MCP client registers.

Secret Service, and a headless fallback

When a desktop environment is running, DeskVNC stores saved host passwords in the Secret Service API, the same interface GNOME Keyring and KWallet implement. Anything that already speaks to those daemons works without change.

On a headless machine, or on a minimal install without a Secret Service provider running, DeskVNC falls back to an encrypted file protected by a master password the user picks. The file lives in the user's data directory and unlocks for the duration of the session, and the encrypted file is the only place the secret exists.

On every shape and every store, the policy is the same: the secret is applied on the far side of the same call your click goes through. An agent that drives a desktop cannot read or supply the password that opens it, and there is no method on the MCP server that returns a stored credential.

Day one on Linux

The bullets below work the moment the install finishes, regardless of which shape you used:

• Saved host library, live thumbnails, tabs and split panes.
• Credentials in Secret Service when a keyring is running, encrypted file fallback when it is not.
• SFTP file transfer, over the machine's own SSH server, in both directions.
• Clipboard sync, with the direction set on the session toolbar.
• mDNS browsing, the polite subnet scan with banner fingerprinting, Wake on LAN.
• The dvv MCP server at the path the install put it, registered with agents DeskVNC finds on the box.
• The same four refusals as every other platform: LIMB_GONE, GEOMETRY_CHANGED, SCREEN_CHANGED, LEASE_REVOKED.

Read more

• Platforms overview

  One client, one MCP server, one set of keys, on Windows, macOS and Linux.

• Install and first connection

  The full install guide, with the three Linux shapes and a checksum check.

• Register the MCP server

  The exact path of dvv for a deb install and for an AppImage, and the registration line for every agent.

• Credentials in the keychain

  How saved hosts and their passwords live in Secret Service, with the encrypted file fallback for headless machines.

• Install matrix

  The full install and availability matrix for Windows, macOS and Linux.

• Latest Linux release

  The deb, the rpm, the AppImage and the tarball on the project's release page.