DEV Community

BeaconKVM
BeaconKVM

Posted on

I Built an IP KVM – BeaconKVM

I'm a programmer and entrepreneur from China. Before this, I built a SD-WAN product for the Chinese market—similar to Tailscale or ZeroTier—so my background is heavily in networking, WebRTC, and audio/video development.

Now, onto the KVM.

I love tinkering with hardware. My home is filled with routers, mini-PCs, NAS boxes, and all kinds of embedded gear. But I only have one monitor—and it lives upstairs with my main workstation.

That led to a few recurring headaches:

  1. New devices go downstairs (networking closet, lab rack, etc.), but my monitor and desk are upstairs. Whenever something goes wrong during setup, I have to either haul the device up or drag the monitor down—just to see what's on the screen.

  2. Traveling. Remote desktop software works fine when the OS is up and running. But the one time you actually need remote access is exactly when the system won't boot—and remote desktop can't help you there.

  3. I wanted native remote KVM. No extra VPN layer, no added instability. Just direct, secure access.

Later on, I learned that many people use IP KVMs for power management, WOL, and other scenarios—but those aren't my primary drivers.

Given my background, I decided to build my own IP KVM software. And here's what it looks like.

What BeaconKVM looks like

What Makes This One Different

To be honest, I didn't study other KVMs extensively. I just designed this from a user's perspective. A few things stand out:

  • Built‑in Remote KVM – It comes with remote access out of the box, with no monthly subscription (at least for now).

  • You own the device – Full root access. Treat it like any other box in your homelab. We recommend lightweight usage, but it's yours.

  • You can use your own remote tunnel – Worried we might disappear someday? No problem. You can always install Tailscale, ZeroTier, or any other VPN software on the device. Even if we're gone, the hardware keeps working.

The most valuable part, in my opinion, is the Remote KVM. I've noticed that many KVM vendors are hardware‑centric and don't pay enough attention to the remote experience. I want Remote KVM to actually solve the pain of business trips and remote troubleshooting—and we already have enterprise customers using this in production.

BeaconKVM Console

BeaconKVM Console

How It Works Under the Hood

Feel free to skip this section if you're not into the technical details.

We're currently using our own SD‑WAN CPE as the base hardware. It comes with:

  • 4 Ethernet ports
  • 2 USB‑A ports
  • 1 USB‑C port
  • Dedicated power input

On the software side, we stream video using both MJPEG and H.264.

  • MJPEG is smooth and low‑latency, but it's essentially a sequence of full JPEG frames, so bandwidth usage is high. That's why we force MJPEG on LAN—great experience, and local bandwidth is rarely an issue.

  • H.264 is used for remote access to save bandwidth. Since we're serving multiple users, lower bandwidth means better scalability. Our H.264 encoding is hardware‑accelerated—without that, the latency would be unacceptable. We spent a long time getting this right.

As for Remote KVM, it's basically a tunnel—but we added a security layer in front. You must log in first, and the device must be assigned to your account before you can access it remotely. No extra software to install; it all works right in the browser. And it's secure.

Try It Out & Share Your Feedback

Here's where you can find us:

If you're not ready to buy hardware yet, you can also build your own using a Raspberry Pi 4B—we've put together a guide here:

https://github.com/beaconbeacon/kvm

We'd love to hear your thoughts, feedback, and real‑world use cases. Help us understand what matters most to you—and what we can do better.

Top comments (0)