MyKVM review: a Rust and Tauri software KVM for sharing one keyboard and mouse across macOS, Windows and Linux

What MyKVM solves, and for whom

A hardware KVM switch solves the problem of two computers and one desk by putting a physical box between them. MyKVM solves it in software: the machine whose keyboard and mouse you are physically using runs in Server mode, the others run in Client mode, and the cursor crosses the boundary between them as if the monitors were attached to one machine. The README describes it plainly: move the cursor off the edge of one screen and it lands on the next machine, the keyboard follows, and the clipboard syncs text and images automatically.

The audience is narrow and specific. You need two or more machines that already sit on the same trusted LAN, you need to install something on each of them, and you need to be comfortable that the project calls itself an experimental early release. Anyone with a single laptop and an external monitor is not the target. Anyone who wants to drive a headless server from a laptop is also not the target, because MyKVM shares input between running desktops, not into a remote session.

The value proposition is the absence of hardware. No switch box, no second set of cables, no USB hub. The cost is that the connection depends on your network behaving, and on the two peers agreeing on a protocol version.

Two UDP channels: plaintext discovery, encrypted transport

The architecture is two channels with very different security properties, and that split is the most important thing to understand before installing anything.

Discovery runs on UDP port 47833 as plain datagrams carrying the marker mykvm.discovery.v1. It handles peer probe and reply, host information, and display metadata. The README is explicit that discovery is plaintext and unauthenticated. Anyone on the same broadcast domain can see the announcements and can forge them.

Input and clipboard both run on UDP port 47834, but over different QUIC primitives. Mouse movement, buttons, scroll and keyboard events travel as QUIC datagrams under the marker mykvm.input.v1, chosen because datagrams are low latency and tolerate loss. Clipboard text and images travel as QUIC streams under mykvm.clipboard.v1, because streams are reliable and ordered, which is what a paste operation needs.

Each peer generates a self-signed certificate at startup and advertises it through discovery. The connecting side pins that certificate, so the QUIC connection is TLS 1.3 encrypted and bound to the advertised peer. That is a real improvement over sending keystrokes in the clear, but it is worth being precise about what it does and does not buy you: pinning protects the transport against a passive listener, while the unauthenticated discovery channel is what tells the client which certificate to trust. An attacker who can answer discovery probes is in a position to be pinned. The README's own framing matches this: encrypted, but a prototype not hardened for hostile networks.

The port arithmetic is worth remembering. The QUIC port defaults to the discovery port plus one, so the default pair is 47833 and 47834. Both fall back through nearby ports if one is taken, and peers advertise their active discovery port, QUIC port, transport public key and protocol version so that discovered and manually added devices still land on the right port.

Installing MyKVM and making the first crossover

The README's Quick Start is aimed at end users: download the installer for each OS from the latest release, keep Server on the machine whose keyboard you use, switch the other to Client, and let LAN discovery pair them. The repository also documents a source build path, which is what you want if you intend to read the protocol code before running it.

For a source build you need Node.js 22 or newer, a stable Rust toolchain, and the platform desktop toolchain. On Windows that means Microsoft C++ Build Tools; on macOS, Xcode Command Line Tools; on Linux, WebKitGTK and appindicator development packages. Install the JavaScript dependencies first:

npm install

Running the Tauri desktop app is a separate script from the browser-only UI. The README lists npm run dev for the web UI and npm run tauri:dev for the desktop app, which is the one that actually captures input:

npm run tauri:dev

The repository ships environment check scripts per platform, and running the check before the app saves a confusing failure later. On Windows:

powershell -ExecutionPolicy Bypass -File .\scripts\check-dev-env.ps1

On macOS and Linux the equivalent is a shell script:

sh scripts/check-dev-env.sh

If you only want to produce a desktop bundle rather than installers, the package scripts separate the two. npm run tauri:build builds without bundling installers, and npm run tauri:bundle produces the desktop bundles.

Once both machines are running, the first real use is the layout step. Open Devices on the client, and if discovery did not find the server, type the other machine's IP, optionally with a port as IP:port, and click Add. The README notes that only devices which report their screen information join the layout. Then open Layout and drag the monitors so their touching edges match the physical desk arrangement. Push the cursor past a shared edge and it should appear on the other machine. If it does not, the layout edge you dragged is the first thing to check, not the network.

On macOS specifically, the server side needs both Accessibility and Input Monitoring granted under System Settings, Privacy and Security. The README states these are required to capture and inject input, and that signed builds keep the grant across updates. If the grant drops, toggling it off and on restores it. On Linux, an AppImage needs chmod +x before it will run.

Where MyKVM is the wrong tool

The most consequential limitation is stated in the README twice: trusted LAN only. There is no user pairing or PIN, and LAN discovery is plaintext and unauthenticated. The README also says not to expose the transport ports to public or untrusted networks. Take that literally. A dorm network, a coworking space, a conference Wi-Fi, or a corporate VLAN shared with people you do not know are all the wrong environment. The certificate pinning protects the input and clipboard streams, but the discovery step that establishes which certificate to pin has no authentication at all.

The clipboard limitation is easy to miss until it bites. Text and images sync; files do not. Copying a folder in Finder and pasting on the other machine will not work, and no amount of configuration changes that. The payload caps are 256 KB for text and 32 MB for images, so a large screenshot may exceed the image ceiling.

There is also a platform asymmetry. macOS builds are self-signed rather than notarized, so Gatekeeper warns on first launch and the README's instruction is to right-click the app, choose Open, and confirm. That is a one-time friction for a user, but it is a recurring friction for anyone distributing the app inside an organization, because the warning is the expected behavior, not a bug to be fixed by configuration.

Finally, the project describes itself as an experimental early release whose protocol and behavior may change between versions. The recent release history is a run of 0.9.13 beta builds, which is consistent with that description. If you need a stable wire protocol that will not shift under you, this is not it yet.

How MyKVM differs from Barrier and Synergy

The obvious comparison is Barrier, the open source continuation of Synergy, which has done software KVM on a local network for years. The difference in approach is in the transport and the client stack, not in the user-facing idea.

Barrier and Synergy carry input over a custom TCP-based protocol with its own encryption and TLS options, and the clipboard is text-oriented. MyKVM instead runs input as QUIC datagrams and clipboard as QUIC streams over the same TLS 1.3 connection, which lets the two payload types have different delivery guarantees on one port. Datagrams for mouse movement make sense: a dropped mouse position is superseded by the next one, so retransmitting it is wasted work. Streams for clipboard make equal sense, since a partially delivered paste is useless.

MyKVM is also a Tauri application: the UI is React and TypeScript, the backend is Rust, and the desktop shell is Tauri 2. That matters if you want to contribute, because the code you would read is Rust plus a web frontend rather than C++ and Qt. It also matters for packaging, since the release artifact is a Tauri bundle and the macOS signing story is whatever the project has set up, which today is self-signing.

Where Barrier has the advantage is maturity and the accumulated handling of edge cases across many desktop environments. MyKVM's own README does not claim otherwise. If your priority is a tool that has been beaten on for a decade, the older project is the safer pick. If your priority is a smaller, modern stack you can read end to end, and you accept beta software, MyKVM is the more interesting one.

Maintenance, release cadence and the MIT licence

The repository is not archived, and the last push was on 2026-07-27. The most recent release at that date was v0.9.13-beta.99, published the same day, with v0.9.13-beta.98 and v0.9.13-beta.97 both published on 2026-07-20. That is a dense beta cadence: three tagged prereleases inside roughly a week. It tells you the project is moving, and it also tells you that any given beta is not a long-term support artifact.

The practical upgrade cost follows from the protocol. Peers advertise a protocol version during discovery, and the README warns that the protocol and behavior may change between versions. If you run mismatched versions across two machines, the failure mode is a peer that discovers but cannot complete a connection, or one that connects and behaves inconsistently. The safe habit is to update both ends together rather than letting one machine sit on an older beta.

The app checks GitHub Releases and updates itself in place, which lowers the cost of keeping up but also means an in-place update can change the protocol on one machine before you have updated the other. On macOS, the README notes that signed builds keep the Accessibility grant across updates, and that if the grant ever drops you toggle it off and on. Budget for that possibility after every update.

The licence is MIT, which is permissive: it allows commercial use, modification and redistribution provided the copyright notice and permission notice are included. That is the extent of what the repository states. It is not legal advice, and if you plan to redistribute a modified build inside a company, the macOS signing and notarization question is a separate problem the MIT licence does not address.

Editorial conclusion

Adopt MyKVM if you have two or three machines on a wired or trusted LAN, you want to read the protocol before trusting it, and you accept a self-signed macOS build and a beta release cadence. Do not adopt it on a shared office VLAN, a coffee shop network, or anywhere you would be uncomfortable with plaintext, unauthenticated LAN discovery and no pairing step. Before you commit, verify three things on your own hardware: that UDP 47833 and UDP 47834 pass between the two hosts, that macOS Accessibility and Input Monitoring grants survive an update, and that the current release notes do not announce a protocol break. The repository's own README says the protocol and behavior may change between versions, and that statement is the real deployment constraint.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. XxMinor/mykvm on GitHub