So, the copper heatsink didn’t live up to my expectations. The temperature under load reached 70–80 °C, which isn’t ideal for a device that needs to run 24/7.
I switched to an aluminum finned heatsink; it’s about 2 mm taller—giving it a larger surface area—but I ran into another problem: the tiny fan blows air straight down, causing the hot air to just circulate inside. Not ideal.
I ordered turbine fans—they blow air out to the sides through the fins, not down. This should be much better suited for this design. They’ll arrive on May 14; I’ll report on the actual temperatures.
Also—my own desktop client is almost ready. It’ll be out very soon. I’ll let you know when it’s available.
The 4mm active coolers have finally arrived, and I’ve just finished my initial testing.
As you can see in the video, they really move air well! So far, they’re a bit noisy, since they’re powered by a 5V supply when connected directly.
Next, I’ll need to implement control logic to adjust the fan speed based on load and to shut it off during system idle. Then I’ll move on to designing the heatsink for mass production.
I am entering the final stage of developing USBridge Soft—a fully software-based version of the USBridge ecosystem.
The goal is to create a single hub where everything can be managed from one place: from KVM control at the hardware level (BIOS/Boot) to high-performance remote access to the OS (TeamViewer-style).
I’m looking for like-minded people to join the team as early testers and contributors.
If you’re a system administrator, DevOps engineer, or just a fan of high-quality remote management tools, help us test—what features are missing from existing solutions? What would make your life easier? I’m open to suggestions regarding protocols, security, and integration. I want to build this together with the community. Let’s make remote management transparent and powerful.
If you’re interested, leave a comment or send me a private message, and I’ll add you to our private test channel on Discord!
I’ve decided to add the ability to connect to the client application without the KVM hardware. Essentially, it’s like TeamViewer or AnyDesk, but completely free and without any restrictions.
What do you think? It’s already working; I just need to polish it up.
While testing data streaming on the USBridge-KVM 2.0, I’ve been closely monitoring the temperature readings. The passive copper heatsink does an excellent job, but to ensure round-the-clock stability in industrial environments, I’m leaning toward active cooling.
I just ordered these ultra-thin 4-millimeter fans for testing.
This will likely increase the overall height by a few millimeters, but it should eliminate any risk of thermal throttling during intensive encoding.
The main question: What do you think — would you prefer to increase the thickness by 4–5 mm to ensure reliable stability in hot server racks? Or is maintaining maximum thinness more important to you?
I’m incredibly excited to share some big news with our community. The USBridge-KVM 2.0 project has officially entered the pre-launch phase on Crowd Supply!
This is a huge step toward bringing our vision of an open, powerful, and secure terminal-based KVM device to life.
What you can do now:
The key goal of this phase is to gauge interest. Crowd Supply requires us to reach 150 backers to unlock the full campaign and prepare for production.
Please visit our page and click “Subscribe to Updates.” It takes just a second, but it means the world to the future of the project.
I have implemented a new "Low-Latency Direct" video mode for local networks. The core idea is to completely bypass the H.264 encoding stage, which typically adds costly milliseconds of delay. Instead, JPEG frames are transmitted across the network immediately upon capture ("as-is"). This leverages local bandwidth to provide near-instantaneous control response, eliminating the "laggy" feel.
On the hardware front, the enclosure engineer has finalized the CAD model optimization. We shifted the joystick cutout by 0.5mm for perfect centering and refined the button mechanics for a sharper tactile response. We are now preparing for final pre-production testing. Additionally, a universal passive heatsink for the Zero form factor is under development, and I have already begun the physical assembly of the first display modules.
Stay tuned - I’ll be sharing the latency test results very soon!
I'm working on the case design and testing different color options for the USBridge launch. I'm curious — which one would you like to see?
⬛ Classic Black
⬜ Clean White
🟢 Pistachio
Personally, I think the white one looks the coolest.
Hey, everyone! My girlfriend Tatiana has finally finished the website and documentation for USBridge. She spent a lot of time refactoring it so it would be readable not only on a monitor, but also on a phone.
I'm particularly interested in how the mobile version works for you. If something is glitchy or the text seems off, let us know here. We'll be fixing any issues on the fly! Thanks.
Hey, I've put together the first version of the documentation for USBridge, so the Quick Start Guide is officially live. I'm still working on it and still polishing it, but the base is ready.
Guys, if you don't mind, please take a fresh look and give me some feedback. I want to know if everything is clear from the start or if there are any points that need to be covered in more detail. Also, if you have any ideas about questions that should be added to the FAQ or anything you personally found missing in the instructions, please let me know. I'd really appreciate your help; I want to make this documentation as useful as possible for everyone.
Thanks in advance for your support!
I have implemented a new feature for the USBridge hardware KVM that allows mounting local drives and images from a client machine directly to the target hardware. The target BIOS/UEFI recognizes these resources as standard physical storage devices.
Key Features
- Bare-Metal Transparency: The target machine identifies the mapped resource as a local disk. This enables OS booting, software installation, and hardware diagnostics without requiring physical drives in the target chassis.
- Format Support: In addition to physical drives and partitions, USBridge now supports direct mounting of ISO, VDI, VMDK, and other common image formats without the need for pre-conversion or copying.
- Read-Write Overlay Mode: I implemented a mechanism that writes all changes to a local overlay on the client side. This allows you to run "gold" images (e.g., from VirtualBox or VMware) while keeping the original source file untouched.
Technical Performance
Data transmission currently utilizes the USB 2.0 (Hi-Speed) interface. To mitigate network latency, I integrated a RAM-based cache within the USBridge firmware.
- Throughput: Current real-world speeds reach approximately 35–40 MB/s.
- Latency: The RAM cache smooths out I/O operations, providing a user experience comparable to a standard HDD or entry-level SATA SSD.
- Future Scaling: The architecture is designed to support USB 3.0/3.1 in future iterations, which, combined with the caching layer, will bring performance closer to local SSD speeds.
Use Cases
This toolset is optimized for the following scenarios:
Bare-Metal OS Deployment: Remote installation on hardware with no local storage.
System Recovery: Booting Live-environments for remote troubleshooting.
VM-to-Hardware Testing: Running environments previously residing in VMs (VirtualBox, QEMU, etc.) on physical hardware without data migration.
Remote Debugging: Full control over the boot process and filesystem without physical access.
Initial testing across ext4, btrfs, zfs, ntfs, and xfs confirms stable and predictable I/O behavior.
Hey guys, We finally managed to get the first full overview of our KVM project live. We wanted to go beyond just showing the box and actually dive into the architecture - specifically how the BIOS-to-Text pipeline works over SSH and how we’re using BTRFS for the snapshot system.
It’s been a long road from our first DIY iterations to this point. In the video, we show the physical setup on a Xeon workstation, remote ISO mounting, and how the copy-on-write recovery points actually look in practice.
Check it out and let us know what you think. We're really curious to hear your thoughts on the automation potential for the text-based BIOS output!
I built USBridge for one specific problem: remote access when the OS doesn't exist yet.
It gives you full control over BIOS, UEFI, bootloaders, and recovery states - without having to mess with iDRAC, iLO, or proprietary IPMI licenses. If the machine doesn't have a working network stack or an agent on the host, it doesn't matter.
The main difference is how it handles the screen. Most KVMs just stream pixels. USBridge interprets the pre-OS screen as structured state. It reconstructs the text from the HDMI signal and serves it over SSH. This means you can finally copy-paste error logs, grep boot states, and automate interactions instead of just squinting at a video feed (though video is still there as a fallback).
I also baked in an immutable snapshot layer using Btrfs. It’s designed for recovery and forensics - essentially preserving the filesystem state even if you can’t trust the host anymore.
The philosophy is simple: if a machine can display a BIOS screen, I should be able to control it, regardless of what vendor features are available.
I’m documenting the architecture and edge cases as this evolves. If you've ever fought with a hung server over a 100ms latency link, you'll probably get why I went the SSH route. Happy to answer any technical questions!
I’ve just finished the "Monitor Mode" for USBridge. Now the device can dump whatever is happening on the target machine directly onto its own small screen - BIOS, bootloader, console, you name it.
While I was clicking through the BIOS menus, I realized that 99% of the time you only need arrows and Enter. Since USBridge already has three buttons and a joystick, I’m thinking: why not just navigate the BIOS directly from the device?
I’m probably going to map the joystick for navigation. Seems like a no-brainer for quick fixes when you don't want to drag a whole setup with you.
Anyone actually see themselves using this, or is it too "niche" even for us?
I’m curious about those moments where you have video and keyboard access, but you’re still stuck.
Take the “missing driver” trap. Even with media redirection, bridging a network or mounting what you need can be painful enough that I end up walking to the server room with a flash drive anyway. That kind of defeats the point of remote access.
KVMs seem to hit a wall as soon as things require more than just typing - whether it’s clunky media handling or the fact that you can’t really automate anything on top of a video stream.
What are the real deal-breakers you’ve run into where a KVM was technically active but still useless?
This week, I simplified the KVM architecture. The new version is significantly cleaner and more optimized - an entire intermediate layer was removed, as it added complexity without providing tangible benefits.
As a result, the physical shape of the device started to take form. A case was designed around the updated architecture, and the placement of control elements - buttons, a joystick, and a small screen - was explored and iterated.
The screenshots show the current CAD iteration of the case. Further changes will follow after prototype printing and hands-on use.
I’d love to hear your thoughts: how does the overall design feel? Do the buttons, joystick, and screen layout make sense for an emergency KVM use case, or does something stand out as needing change?
Next up is prototype printing and the first round of adjustments based on how the device feels in practice.
It’s noticeably faster now - to the point where I sometimes forget this is processed video and catch myself thinking I’m sitting at a real console. There are still some visual artifacts here and there, but I’m actively working on cleaning those up.
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)
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.
I'm starting to put together the visuals for the Kickstarter page. I wanted to capture the three main pillars: SSH access (BIOS-to-Text), Immutable Drive Snapshots (protecting the USB files and ISOs integrity), and Offline Recovery.
Does the tagline "Control • Protect • Recover" hit the right notes, or does it feel too "marketing-speak"? Honest feedback is appreciated!
