JetKVM review: open source KVM over IP for remote machine control

What JetKVM actually solves, and for whom

A machine that will not boot is unreachable over SSH. That is the gap JetKVM targets: keyboard, video and mouse access at the level below the operating system, delivered over the network. The README frames the use cases directly, listing boot failures, operating system installs, BIOS settings and general remote control of a machine.

The audience is narrower than "anyone who wants remote access". JetKVM is device firmware. The repository holds the software that runs on a KVM device, the cloud API and the cloud web frontend, plus a React frontend served by the device itself. If you were looking for a daemon to install on a Linux server that gives you a remote console, this is not that. The hardware is the product; the repository is the software that makes it work, published so it can be inspected and modified.

That distinction matters for evaluation. You are not choosing a dependency to add to a project. You are choosing a piece of infrastructure that will sit between a monitor and a machine, and the repository is what tells you how that infrastructure behaves.

How the device, the cloud and the browser fit together

The repository is split into two parts that the README names explicitly: backend software running on the KVM device, and frontend software served by the KVM device. The cloud is a third piece, also part of the same repository.

The backend is Go. The go.mod file shows the shape of it: pion/webrtc and pion/ice for media transport, gin for HTTP, coder/websocket, prometheus client libraries for metrics, go-oidc for authentication, tailscale-related networking through netlink and mDNS, and go-nbd, which points at block device access over the network. Files at the repository root map onto physical concerns: display.go, edid_presets.go, usb.go, usb_mass_storage.go, serial.go, hidrpc.go, jiggler.go, ota.go, failsafe.go. That layout is a reasonable proxy for what the device does. It captures a display, presents a USB HID device and mass storage to the target, exposes a serial console, and updates itself.

The frontend is React and TypeScript with three build targets: device, development and production. The device target is what gets served by the KVM device; development is for working on the cloud version locally; production builds the cloud frontend. The README states this plainly, and it is the clearest signal that the same UI codebase serves two deployment shapes.

Remote access runs over WebRTC through JetKVM Cloud, which the README calls free and optional. Tailscale is also optional, with built-in status and control-server configuration, including Headscale-compatible endpoints. Those two sentences are the whole of the remote-access story in the README. There is no published threat model, and the README does not describe what the cloud sees or stores.

Installing JetKVM and a first real use

There is no install command for JetKVM in the sense of a package you add to a host. The README points to the documentation site at jetkvm.com/docs for answers and to the Discord server when the docs fall short, and the repository is the firmware source. What you can do from the repository is build and flash the device software, or run the frontend against a device.

The Makefile is where the build is defined. It sets VERSION to 0.5.9, matching the most recent release tag, and derives a development version from the current date. The Go build targets linux/arm with GOARM=7, and the binary is published under two SKUs, jetkvm-v2 and jetkvm-v2-sdmmc, which the Makefile comment says resolve to the same binary today but are kept separate because the cloud releases endpoint looks up artifacts per SKU.

For day-to-day work on the device, the README gives a script rather than a manual build:

./dev_deploy.sh --help

Running that with --help prints the script's own options. The README says the script builds the frontend and backend and deploys them to the local KVM device, which means you need a device reachable on your network before this is useful. If you have no device, this path is closed.

The frontend has its own targets, and the names come from the README:

# build targets: device, development, production

Use device when you are producing the UI the KVM device serves, development when you are working on the cloud version locally, and production when you are building the cloud frontend. The README does not spell out the exact npm or pnpm invocation, so check DEVELOPMENT.md before assuming a script name.

For a first real use, the sequence is: get the device on the network, reach its UI, and confirm the video and HID paths work before you rely on it. The README claims 1080p at 60 FPS with 30 to 60 ms latency using H.264 encoding. Treat that as a vendor figure. Network conditions, the target machine's resolution and the H.264 path all affect it, and the repository does not include a benchmark you can run to reproduce it.

Where JetKVM stops being the right tool

The strongest limitation is the one the README never addresses: the device is the unit of deployment. Everything in the repository exists to make a specific piece of hardware work. If the hardware fails, the software does not help you. There is a failsafe.go in the repository root, but the README does not document what it does or how recovery works, and it does not describe rollback for a bad OTA update. ota.go exists; its failure behaviour is not described in the README.

The second limitation is scope of support. The Makefile builds for linux/arm with GOARM=7, and the release artifacts are keyed to the jetkvm-v2 and jetkvm-v2-sdmmc SKUs. Nothing here suggests you can port the firmware to arbitrary boards by changing a build flag. The CGO flags reference a specific Rockchip buildkit flavour, arm-rockchip830-linux-uclibcgnueabihf, which is a strong hint about how tied the build is to the target SoC.

The third is the remote-access design. Remote management goes through JetKVM Cloud over WebRTC. The README calls the cloud free and optional, and Tailscale is likewise optional, but the README does not document a fully self-hosted alternative to the cloud that preserves the same workflow. If your policy forbids a vendor relay, you are relying on the Tailscale or Headscale path, and the README gives one sentence about it rather than a configuration guide.

Finally, if the machine you need to reach is a VM on a hypervisor you control, a serial console or the hypervisor's own remote console is cheaper and has fewer moving parts. JetKVM is for physical machines.

Alternatives and the real difference in approach

The obvious comparison is PiKVM, the other well-known open source KVM over IP project. The difference is in what you assemble. PiKVM is built around a Raspberry Pi, so the hardware is commodity and the software is something you install onto a board you supply. JetKVM is built around a purpose-made device with its own SoC and its own build toolchain, and the repository is the firmware for that device. PiKVM gives you more freedom in hardware selection and more assembly work. JetKVM gives you a finished unit and a narrower build target.

A second alternative is BMC-based remote management, IPMI or Redfish on server hardware. That is free if your servers have it, requires no extra device, and is well understood by operations teams. It is also frequently the thing that is broken or misconfigured when you most need it, and it does not help with a desktop workstation or a machine with no BMC at all. JetKVM is the answer when there is no BMC, or when the BMC is the thing that failed.

A third is a commercial KVM over IP appliance. Those typically bundle support and a warranty, and typically do not give you the firmware source or SSH access to the device. The README lists SSH access to the JetKVM device as a feature, which is the point of difference: you can get onto the box and change it.

Maintenance, releases and licence obligations

The repository is not archived, and the last push was on 2026-09-21, two days before this was written. Development is ongoing on the dev branch, which is the default branch, and the most recent release is 0.5.9 from 2026-09-09, preceded by two development tags in the same week. That release cadence suggests the project ships often, and that the default branch is where work happens rather than a stable line.

For an operator, that cadence has a cost. Firmware updates are pushed to a device that may be your only path into a machine, and the README does not describe a rollback procedure. The Makefile references a GPG signing key fingerprint variable, SIGNING_KEY_FPR, described as required for signing releases, so releases are signed, but the update and recovery path is documented on the website rather than in the repository.

The licence is GPL-2.0. If you build the firmware, modify it, and distribute the result, the GPL's source-availability terms apply to what you distribute. Running it on your own device is not distribution in the usual reading, but shipping a modified device to a customer is. The repository does not contain a separate licensing note for the cloud components, and the README does not discuss licence scope. If you plan to redistribute hardware with modified firmware, have someone who can give legal advice read the LICENSE file and the file headers before you commit to that.

Editorial conclusion

Adopt JetKVM if you already have the JetKVM device or are willing to buy one and you want BIOS-level access with an optional, self-hostable remote path rather than a subscription service. Do not adopt it if you need a pure software KVM, if your target machines are ARM boards the firmware does not target, or if you cannot accept that the repository is the device firmware and the cloud backend, not a package you install on a server. Verify three things first: that your KVM switch or ATX extension board is supported, that the tailscale.go path works with your own Headscale endpoint if you intend to avoid the hosted cloud, and that the GPL-2.0 obligations fit how you plan to redistribute the firmware.

Frequently asked questions

Official sources

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