Deskflow: a software KVM for sharing one keyboard and mouse across computers

The problem Deskflow solves, and who actually needs it

Two laptops, a desktop, and one desk. You either buy a hardware KVM, keep two keyboards on the desk, or run software that forwards input over the network. Deskflow is the third option. The README describes it as "a free and open source keyboard and mouse sharing app" and compares it to a software KVM "but without the video." That parenthetical is the whole scope: the monitor signal stays where it is, only the input events travel.

The audience is narrower than the download counts suggest. Deskflow assumes all machines are on the same local network and that you are willing to grant input-capture permissions on each one. It is for people who already have monitors and keyboards attached to each machine and want to stop reaching for the second keyboard. It is not a remote desktop tool: there is no video stream, so a machine without its own display is not useful to you here.

How input flows between the server and the client

Deskflow uses a server/client model. One machine runs the server, captures local keyboard and mouse events, and decides which screen the pointer is on. When the pointer crosses the configured edge of the server's screen, the server forwards the input events over the network to the client, which replays them locally. The client does not send input back; it is a sink.

The README states that TLS encryption is enabled by default, so the event stream is not sent in the clear. Clipboard sharing is listed as supported, which means clipboard contents also cross that connection. The repository layout points to a C++ codebase built with CMake: CMakeLists.txt at the top level, sources under src/, translations/ for localisation, and a LICENSES/ directory plus REUSE.toml for licence metadata. There is also a docs/ directory, though the README does not describe what it contains.

Installing Deskflow on Windows, macOS and Linux

The README gives three routes: download a package from the releases page, install deskflow from your package repository, or build from source using the Building wiki page. On Flathub the app is published as org.deskflow.deskflow.

On Windows, the README states that you need the Microsoft Visual C++ Redistributable installed first. The download links it gives are vc_redist.x64.exe and vc_redist.arm64.exe. Windows 10 v1809 or higher is required.

# Windows: install the VC++ redistributable before Deskflow
vc_redist.x64.exe

On macOS, the README recommends Homebrew through the project's homebrew-tap. It also warns that macOS reports unsigned apps as damaged because the project does not use an Apple certificate for notarization, and gives the fix:

xattr -c /Applications/Deskflow.app

After that, accessibility access must be granted to both the Deskflow app and the deskflow process under Privacy & Security. On Sequoia you may also need to allow Deskflow under Local Network settings. If you are upgrading and the old entries are still on the allowed list, the README says you must remove them manually before the new version can be granted access. That is a real upgrade tax, not a one-time setup step.

On Linux, the README states that libei 1.3+ and libportal 0.8+ are required for the server/client, and Qt 6.7+ is required for the GUI. Systems that do not meet those versions should use flatpak instead of a native package.

# Linux: install the flatpak when native requirements are not met
flatpak install flathub org.deskflow.deskflow

A first real use is the same on every platform: pick one machine as the server, add the others as clients, and arrange them in the layout so the pointer crosses edges in the direction you expect. The README does not document the layout editor or the config file format, so the in-app UI is where you configure that.

Where Deskflow stops being the right tool

The most obvious limitation is the one the README states outright: there is no video. If the second machine has no monitor, Deskflow gives you nothing.

The second is platform requirements. Linux is the sharp edge. libei 1.3+, libportal 0.8+ and Qt 6.7+ are not present on older distributions, and the fallback the README names is flatpak. If your environment forbids flatpak, you are on the Building wiki page and a toolchain you have to maintain yourself.

The third is macOS code signing. The README says the project does not use an Apple certificate for notarization. That means every macOS install involves clearing the quarantine attribute and manually re-granting accessibility access on upgrade. In a managed fleet, that is a deployment problem, not a preference.

Fourth, the release model is split. There is a tagged release line (v1.26.0, v1.25.0) and a separate continuous channel, and the most recent entry in the release list is the continuous build. The README does not document what the continuous channel guarantees or how it relates to the tagged versions, so anyone who needs to pin a version should read the release notes for that channel rather than assume it tracks the tags.

Deskflow against Barrier and hardware KVMs

Barrier is the closest comparison, and the difference is lineage rather than features. Deskflow and Barrier both descend from the same Synergy-era codebase; Deskflow is the actively pushed fork, with the last push on 2026-09-19, and it carries the newer platform work the README advertises: Wayland support, TLS by default, and the libei/libportal dependency that Wayland input capture requires. Barrier's documentation does not describe libei support, which is why Wayland is the dividing line between the two.

A hardware KVM is the other alternative, and it is a different trade. It switches the actual video signal along with the input, so it works with machines that have no network path between them and no OS-level permissions to grant. It also costs money, adds cabling, and usually degrades the display signal. Deskflow needs the machines to be reachable from each other and needs software on each one. If your requirement is "switch the monitor too," Deskflow is not in that category at all.

Maintenance, releases and the GPL-2.0 licence

The repository is not archived, and the last push was on 2026-09-19, two days before the date of this article. The release list shows v1.26.0 from 2026-02-16 and v1.25.0 from 2025-11-21, with a continuous build dated 2026-09-18. So there is a roughly quarterly tagged cadence plus a rolling channel. The README does not document an upgrade procedure beyond the macOS note about removing stale accessibility entries before granting access to a new version, and it does not document rollback.

Deskflow is licensed GPL-2.0, with a LICENSES/ directory and REUSE.toml in the repository. For anyone embedding the code in another product, GPL-2.0 is a copyleft licence and that has distribution consequences, but this is a description of the licence identifier, not legal advice. If you are shipping Deskflow inside something, talk to someone qualified. For ordinary desktop use, the licence is not a practical constraint.

Editorial conclusion

Deskflow fits engineers running two or three machines side by side who want one keyboard and mouse without a hardware KVM, and who can live with per-OS permission setup. It is the wrong pick if you need video switching, if your Linux host predates libei 1.3 and libportal 0.8 and you cannot use the flatpak, or if you need a signed, notarized macOS build from the release page. Before adopting it, check the release channel you intend to track, confirm the macOS accessibility entries for both Deskflow and deskflow, and read the Building wiki page if you plan to compile from source.

Frequently asked questions

Official sources

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