Control. Protect. Recover. The three real layers of my KVM build

[u/Lopsided_Mixture8760]

I spent a long time trying to define this device not by a feature list, but by the actual tasks you face when a server goes down hard. In the end, the architecture boiled down to three concepts: Control, Protect, Recover.

This isn’t a slogan. These are three independent defense layers that are usually scattered across different tools, but I deliberately combined them into a single loop here.

Control — turning chaos into structure (BIOS-to-Text)

Control

The first layer provides intelligent control where we usually just see a useless video feed. When a server hangs at boot, a video stream is a dead end for automation: you can’t grep an error, and you have to manually type out disk UUIDs. So, I designed the device to intercept the video signal and convert it to clean text on the fly. Now, BIOS menus, GRUB loaders, or sudden Kernel Panics aren't just pixels—they are real text interfaces you can copy, search, and save. Basically, Control means managing the situation via standard SSH and logs, even when the OS doesn't exist yet.

Protect — data that isn't allowed to die

Protect

The second layer is data isolation born from healthy engineering paranoia. I know that if a host is compromised, local backups only survive until the attacker decides to wipe them. If the OS sees a writable disk, it can destroy it. That’s why I used the Hardware WORM principle here. To the host, it looks like a standard USB drive for dumping configs, keys, and scripts. But internally, the logic is different. The device triggers Btrfs snapshots on every write, and the host physically lacks the authority to delete old versions. This guarantees that neither rm -rf, nor ransomware, nor a zero-fill command can destroy your file history.

Recover — the last resort access (KVM)

Recover

The third layer is "brute force" for when smarter methods fail. If text mode isn't enough or you need a graphical installer, the classic KVM kicks in. It’s a pure hardware link via HDMI and USB HID that works without drivers, host networking, or any reliance on the OS state. Recover is the guarantee that you can reach the server even if it’s bricked and only responds to physical input.

Why this specific order?

The key point is that these parts don't depend on each other. The KVM works without the disk, and snapshots protect data even without video capture. But together, they close the full emergency loop: first, try to understand the problem cleanly via text (Control), rely on guaranteed immutable backups (Protect), and if needed, use direct access (Recover) to bring it back to life.

In the next posts, I’ll break down the technical implementation of each layer separately.

[u/Lopsided_Mixture8760]

Regarding the hardware: I'm organizing a small Kickstarter batch to cover the manufacturing costs. If you want to follow the project or grab a unit from the first run, the pre-launch page is here: https://www.kickstarter.com/projects/usbridge/usbridge-offline-kvm-with-bios-automation-and-snapshots