hckrnws
Show HN: Provisioner per-board sidecar for serial access, flashing, and bring-up
by acarminati
Hi HN,
I’ve been building a small infrastructure tool called Provisioner: a per-board provisioning sidecar for SBC bring-up and lab automation. https://github.com/alessandrocarminati/provisioner
The model is simple: one instance per board. It sits next to the hardware, owns the serial console, exposes access over SSH, and serves boot artifacts (kernel, initramfs, rootfs) via TFTP/HTTP. It’s designed for the phase where networking is unreliable, storage is half-flashed, and UART is the only thing still telling the truth.
What it does
- Serial console ownership + SSH multiplexing - Monitor shell + serial tunnels - Scriptable boot interaction - Artifact provisioning (TFTP + HTTP) - In-band file transfer over serial - gzip/base64 hacks + XMODEM - Derived from my earlier send_console-ng utility https://github.com/alessandrocarminati/send_file-ng - Pluggable power control - SNMP PDUs, among others cheap ESP8266/Tasmota devices - Serial logging - Lightweight access control
Provisioner also embeds a minimal init runtime (goinit) inside the kernel initramfs, acting as its on-board provisioning agent, handling flashing, artifact retrieval, and reporting management state back over serial.
Routing & stream handling
Internally, Provisioner routes serial traffic through a pluggable router:
- Producers/consumers attach as components - Human vs machine clients handled differently - Unicast control sessions - Broadcast multiplexing to multiple observers
This allows several users or services to watch the same console without interfering.
Filters
A filter subsystem can intercept and modify serial streams on the fly.
Originally added to mitigate ANSI Device Status Reports (e.g. Cursor Position Report issues) when tunneling serial consoles, but it doubles as a general stream rewriting mechanism for automation and normalization.
Positioning
Not trying to replace large systems like LAVA.
This is aimed at:
- Homelabs - Bring-up benches - Kernel/BSP work - Small shared labs
Think lab automation you can deploy in an afternoon, not fleet orchestration.
Project is still evolving but already in daily use. Feedback and abuse welcome.
Nifty! I recently bought a RISC-V VisionFive 2 Lite SBC, which required a lot of mucking with firmware and talking to the U-Boot serial console before it would boot Linux for the first time. A tool like this would have been super-handy during that time.
On the other hand, I'm a low-budget hobby user. I like things that are cheap, easy, and hackable. It sounds like your product might be for more-advanced users? Or do all these fancy features stay tucked away until you need them? If you make your product cheaply, that might hurt profit margins, but it might also open up the low-end market. I have so many questions about the business side of this.
But really, I am most curious about the user experience. It's not super-helpful if learning the tool becomes its own project, so I'm hoping it's simple.
Edit: Oh, it's a software project. I thought it was a hardware project. My bad.
Crafted by Rajat
Source Code