That’s a really interesting use case. I’m currently evaluating integrating the ESPHome compiler into the project, so it could potentially compile and run ESPHome YAMLs during the development stage

It’s still exploratory, but it could definitely go in that direction

The main advantage is accessibility and ease of use: with the browser, no setup is required on the user’s side, no toolchains need to be installed, and there’s no need to be familiar with SSH or terminal workflows

It also provides a more visual and interactive environment (editor, peripherals, simulation controls), which is especially useful for teaching and for beginners.

The Docker image is there so you can easily install it on your own machine if you want to run it locally or work on development

Hey HN, I posted Velxio here a while back and got great feedback. Since then I've shipped a major update

What's new in v2:

- 19 boards across 5 CPU architectures (AVR8, Xtensa, RISC-V, ARM Cortex-M0+, ARM Cortex-A53)
- ESP32 emulation via QEMU (lcgamboa fork) — real flash images, ROM function emulation, GPIO/ADC/timers
- ESP32-C3 and CH32V003 run on a custom RISC-V core written in TypeScript, entirely in the browser
- Raspberry Pi 3B via QEMU raspi3b — boots real Pi OS, runs Python
- Realistic sensor simulation: DHT22 (40-bit protocol timing), HC-SR04 (trigger/echo), WS2812B NeoPixel (GRB decoding)
- 48+ electronic components from wokwi-elements

Architecture:

- AVR, RP2040, and RISC-V emulation runs client-side (avr8js, rp2040js, custom TS core)
- ESP32 Xtensa and Pi 3 run on backend QEMU
- Compilation via real arduino-cli
- React + Vite frontend, FastAPI backend
- Self-hostable via Docker, no account needed

Source: https://github.com/davidmonterocrespo24/velxio (AGPLv3)

Happy to discuss the emulation architecture — particularly the trade-offs between in-browser vs. backend QEMU emulation