Open-Source Tool Bridges Bluetooth to Proxmox VMs
28 Jul 2026
A new open-source project is tackling a persistent headache in the homelab and self-hosting world: getting Bluetooth to work reliably inside Proxmox virtual machines. The tool, shared via a Show HN post, lets a VM share the host machine's Bluetooth adapter over the network rather than relying on direct hardware passthrough.
The problem it solves
Bluetooth passthrough on Proxmox has long been unreliable for a specific reason: certain Intel onboard chips—BE200, AX210, and AX211—are built so that only the machine that boots them can actually drive them. According to the report, this is a hardware design decision by Intel, not a software bug, which means no amount of configuration tweaking fixes it. The report also notes that reliability issues extend to gaming-oriented Linux distros like ChimeraOS and Bazzite, where Bluetooth passthrough has been inconsistent.
How the bridge works
Instead of passing the physical Bluetooth hardware into the VM, the new tool creates a network bridge between the Proxmox host and the guest VM. Installation is reportedly simple—one command on the host, one inside the VM—and the bridge auto-starts at boot and auto-reconnects if the connection drops.
Per the report, the tool works with any Bluetooth chip supported by Linux, and testing has covered controllers, headphones, and Home Assistant sensors. Latency is a headline number: the bridge adds well under a millisecond (<1 ms) when host and VM are on the same machine, running over network port 9700.
Known limitations
The report flags one clear security concern: the bridge runs on port 9700 without authentication, which could be risky if exposed on an untrusted network. Beyond that, the report notes several open questions that aren't yet addressed—whether multiple VMs can share the same host Bluetooth device simultaneously, how the tool performs under multiple concurrent Bluetooth devices or varying network conditions, and how it stacks up against existing Bluetooth or USB passthrough alternatives. There's also no stated information on project maturity, license, or maintenance status beyond the GitHub repo itself, and no data on how many users have adopted it so far.
Why founders should care
For founders building developer tools, infrastructure products, or homelab-adjacent software, this project offers a few signals worth weighing carefully:
- The existence of this workaround likely reflects unmet demand in the self-hosting community for simpler hardware passthrough solutions—a niche that may be underserved by existing tooling.
- The lack of built-in authentication is plausibly an opportunity gap: a startup could differentiate by offering a more secure, enterprise-ready variant of the same core idea.
- Community appetite for working around Intel's chip restrictions suggests there may be a modest but real market for virtualization tooling that addresses hardware vendor lock-in more broadly.
- The two-command installation approach is a useful product design reference point—minimizing setup friction appears to be a meaningful driver of adoption in developer-facing tools, even if this project's actual user base is not yet documented.
As with any early-stage open-source project, the caveats matter: there's no public data yet on adoption numbers, multi-VM support, or how the bridge holds up under heavier or more varied network loads. Founders evaluating this space should treat the reported opportunities as directional rather than validated at scale.