One-KVM: a Rust IP-KVM that reaches the BIOS over the network

What One-KVM replaces, and who it is for

A conventional KVM switch is a box with a physical button. One-KVM is the software half of that idea: the target machine's video goes into a capture device, its keyboard and mouse input arrives over a USB HID path, and a web console in your browser carries both across the network. The README's stated goal is an open, lightweight and easy-to-use IPKVM solution, with three claims attached: it is not bound to a specific hardware configuration, it ships as a binary without heavy dependencies, and configuration happens in the web interface rather than by editing files.

The audience is narrow and practical. You are running a home lab, a small rack, or a single workstation you cannot physically reach, and you want to see POST output and change BIOS settings without a monitor and keyboard on site. The README positions the project as an alternative to commercial IP-KVM appliances, and the feature table is the evidence: video capture from HDMI USB, MIPI CSI or RK3588 HDMI IN; keyboard and mouse over USB OTG HID or a CH340 plus CH9329 pair; virtual media through USB Mass Storage; ATX power control via GPIO or a USB relay; and audio captured through ALSA and encoded with Opus.

That list also tells you what One-KVM is not. It is not a drop-in replacement for a managed PDU, and it is not a hypervisor console. If the target machine never leaves its OS, a plain SSH session or a remote desktop tool is cheaper and has no hardware prerequisites at all.

How the capture, HID and power paths fit together

The architecture is a Rust service that owns several device-facing subsystems and exposes them over HTTP and WebRTC. On the video side, capture comes from an HDMI USB device, MIPI CSI, or the RK3588 HDMI IN block. Encoding is where the hardware matters most: the feature list names VAAPI, QSV, RKMPP and V4L2M2M as hardware paths, with software encoding as a fallback. The service then serves MJPEG or a WebRTC stream carrying H.264, H.265, VP8 or VP9. MJPEG is the low-latency, high-bandwidth option; WebRTC is the one that puts a real codec on the wire.

Input travels the other direction. The host presents itself to the target as a USB HID device, either through USB OTG or through a CH340 serial adapter driving a CH9329 controller. The README notes support for both absolute and relative mouse modes, which matters because absolute mode keeps the cursor aligned with what you see, while relative mode is the fallback when the target's OS does not cooperate.

Virtual media is implemented as USB Mass Storage, so the target sees a drive. The README states that ISO and IMG images can be mounted, and that a Ventoy virtual USB mode is available. Power control is deliberately low-tech: a GPIO line or a USB relay, both of which the README lists as supported for ATX control. Nothing here is exotic, and nothing here is automatic. Each of those paths is a physical connection you have to make before the web console is useful.

The dependency list in Cargo.toml confirms the shape of the service: axum and axum-server for HTTP, tokio as the runtime, sqlx for storage, webrtc and rtp for streaming, v4l2r for capture, alsa and cpal for audio, gpio-cdev for the power line, and argon2 plus totp-rs for authentication. The desktop feature is enabled by default, so a plain cargo build pulls in the whole web stack.

Installing One-KVM from a .deb package or Docker

Build artefacts are published on the GitHub Releases page. The README describes two common installation routes and points to docs.one-kvm.cn for system requirements, hardware preparation, Docker environment variables and USB OTG details, which means the README alone is not enough to get a working deployment.

On Debian or Ubuntu, download the one-kvm_*.deb matching your architecture, then install it from the directory containing the file:

sudo apt update
sudo apt install ./one-kvm_0.x.x_<arch>.deb

Replace the version and architecture in the filename with the package you actually downloaded. apt resolves dependencies from the local file, which is why the ./ prefix matters.

The Docker route uses two images. one-kvm contains the main program plus ttyd; one-kvm-full adds gostc and easytier-core among other optional extensions. The README's example runs the full image with host networking and the device and sysfs trees mounted:

docker run --name one-kvm -itd \
  --privileged=true --restart unless-stopped \
  -v /dev:/dev -v /sys:/sys \
  --net=host \
  silentwind0/one-kvm-full

If the pull is slow, the README suggests the Aliyun mirror registry.cn-hangzhou.aliyuncs.com/silentwind/one-kvm-full, and the same substitution works for the one-kvm image. The privileged flag and the /dev and /sys mounts are not decorative: the container needs the capture device, the HID path and the GPIO line to be visible inside it.

There is also a NAS route. The README states One-KVM is listed in the 飞牛 (fnOS) app market, where you search and install it directly. After installation, open a browser at http://<device IP>:8080, or port 8420 if it was installed through fnOS. The first visit walks through initial configuration. The README does not document a default password, so the initial setup step is where credentials come from.

Where One-KVM stops being the right tool

The honest limitation is hardware. The README frames the project as not bound to a specific hardware configuration, and the feature table lists several capture and encoding families, but it does not name a single validated board, capture chip or OTG-capable host. That gap is pushed to docs.one-kvm.cn. Until you read that documentation, you are buying hardware on the assumption that your kernel exposes the right V4L2 nodes and that your board's OTG port can act as a device rather than a host.

The second limitation is the deployment model. The Docker example runs --privileged=true with /dev and /sys bind-mounted and host networking. That is a container in name only; it has effectively the same reach as a system service. If your threat model treats a compromised web console as a path to the host's GPIO lines and block devices, that is a real exposure, and the README does not describe a sandboxed alternative.

The third is operational. The README documents installation and first configuration but says nothing about upgrades, backups of the configuration database, or rollback. The release cadence is visible (v260720, v260802, v260926), and the version in Cargo.toml is 0.2.7, which is still a 0.x line. Treat upgrades as something you plan for yourself.

Finally, the licence. Cargo.toml declares AGPL-3.0-only, and the repository carries an AGPL-3.0 LICENSE file. If you intend to embed One-KVM in a product you distribute, or to expose a modified version as a network service, the copyleft terms apply. That is a business decision, not a technical one, and it is worth a lawyer's time rather than mine.

One-KVM against PiKVM and against a managed PDU

The closest comparison is PiKVM, which the README does not mention but which occupies the same niche: a Raspberry Pi acting as an IP-KVM. The difference in approach is packaging and hardware assumption. PiKVM is built around a specific board family and a prepared image, so the hardware is the product. One-KVM is a Rust binary you install on a system you already have, with the capture and HID hardware left as your choice. That is more flexible and less predictable at the same time: nothing in the README tells you which combination has been exercised.

A second comparison is a switched PDU. A PDU gives you power cycling and nothing else. One-KVM adds video and input, which is the difference between rebooting a machine and diagnosing why it will not boot. If your only failure mode is a hung OS, a PDU plus SSH is enough and costs less attention.

A third is the Python predecessor. The README states plainly that One-KVM Python has stopped development and points to the python branch for anyone who still needs it. If you find older instructions referencing the Python version, they describe a project that is no longer moving.

Maintenance, licensing and what the repository tells you

The last push to the default branch was on 2026-09-26, and the most recent release, v260926, is One-KVM Rust 0.2.7, published the same day. Two earlier releases, v260802 and v260720, sit roughly one and two months back. That is a steady cadence over the recent window, and the repository is not archived.

Upgrade cost is the part the documentation is quiet about. The README explains how to install a .deb and how to run the Docker image, but it does not describe migrating a configuration between versions, nor does it mention a rollback procedure. Because the service stores state through sqlx, and because the README says configuration is done in the web interface rather than in files, the practical upgrade question is what happens to that stored state. The README does not answer it.

On licensing: the package metadata declares AGPL-3.0-only and the repository ships an AGPL-3.0 LICENSE file. The README also states the project is built on several other open source projects, and the repository contains a licenses/ directory, which is where third-party obligations are likely recorded. If you redistribute One-KVM or run a modified version as a network service, read that directory and the AGPL text before you decide. Nothing here is legal advice.

One more signal worth noting: the README carries a sponsorship section and a long list of individual supporters, plus named cloud and storage sponsors. That is a project funded by its users rather than by a vendor, which shapes both the release cadence and the support channel, a GitHub issue or a QQ group.

Editorial conclusion

Adopt One-KVM if you already have a target machine with HDMI capture, a USB OTG or CH340/CH9329 HID path, and optionally a GPIO or USB relay for power, and you want a browser console rather than a vendor appliance. Do not adopt it if you need a supported hardware list, a documented rollback path, or a permissive licence for a closed product; AGPL-3.0-only in Cargo.toml settles that last point. Before buying anything, read the system requirements and hardware preparation pages on docs.one-kvm.cn, because the README does not state which capture chips or boards are known to work.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. mofeng-git/One-KVM on GitHub
3. Project website
4. README
5. Releases