Forty boards share one editor, but they do not all run locally
Velxio combines a Monaco code editor, circuit canvas, compiler output, serial monitor, and virtual instruments in one browser workspace. The README lists 40 boards across 5 CPU families and more than 150 interactive components. AVR and RP2040 boards run in the page. ESP32, STM32, and Raspberry Pi Linux targets use QEMU-backed services that stream GPIO and serial state to the same canvas.
That uniform Play button hides a licensing and deployment split. The self-hosted image includes Arduino, Raspberry Pi Pico, and ESP32 families. STM32, Raspberry Pi Linux, ESP32-C6, and branded partner boards remain on velxio.dev, with some requiring a paid plan. The open picker can show those boards, but selecting them sends users to the hosted editor. Check the board table before promising an offline classroom a particular target.
The prebuilt container is the real installation path
Velxio documents three routes: a published container, a Compose source build, and a manual frontend-plus-backend setup. The container maps port 3080 and uses five named volumes for SQLite data, Arduino cores, user libraries, ccache objects, and ESP-IDF build directories. The volumes keep board toolchains and compiled objects across restarts. The service generates its secret key on first boot, so the basic local path needs no environment file.
Manual development has more moving parts. The backend uses Python, the frontend needs Node.js, and compilation depends on arduino-cli. Browser-side AVR and RP2040 boards can work there. ESP32 requires QEMU shared libraries supplied by the Docker image or wired up by hand. The repository includes a Compose file and 11 CI workflows, though our scan found no Dockerfile at the measured commit.
What happened when we ran it
Our sandbox installed 6 npm packages in 7 seconds and used 38 MB on disk. It checked out commit ff2ff0d in a fresh unprivileged Debian container with 3 CPUs, 8 GB of RAM, Node 22, and no secrets. Npm audit reported 0 known vulnerabilities across all listed severities.
The root package.json contains only @types/node, tsx, and TypeScript as development dependencies. It defines no scripts, so there was no build target and no test target to run. Both steps were skipped. The result covers the small root tooling package, not the Python backend, React frontend, Arduino compiler path, QEMU services, or browser emulators.
That boundary matters in a 2,780-file repository with about 329,313 source lines and a 116.5 MB checkout. A successful 7-second npm install does not show that an Arduino sketch compiles or an ESP32 peripheral behaves correctly. The repository has a tests directory, but the root package offered no command that invoked it. Teams should use the container path and run board-specific examples matching their firmware.
The simulator covers buses, displays, WiFi, and custom chips
Velxio goes beyond blinking one virtual LED. The README describes SPI, I2C, UART, ADC, PWM, virtual WiFi with MQTT, an oscilloscope, and a SPICE-based electrical layer. Custom chips can be written in C, compiled to WebAssembly, and placed beside emulated boards. More than 400 hosted examples provide starting circuits.
A student can see source, wiring, serial output, and a waveform without moving between applications. That breadth also creates fidelity boundaries. Browser AVR execution, RP2040 emulation, and QEMU-backed ESP32 peripherals do not share one implementation. A passing sketch on one board family is evidence for that simulated route, not every board with a similar pin label.
Open ESP32 reports are reasons to keep hardware in the loop
Issue 381 reports that an ESP32 NeoPixel example works with 1 pixel but stalls when changed to 2 or more on the QEMU path. The reporter saw the first batch of RMT events and no completed update frame. Issue 374 reports a different gap: ESP32 code toggles GPIO2 and prints once per second, but the onboard LED drawing never changes because the board component receives no LED state.
Issue 332 describes a Grove servo example failing after a move to ESP32-S3 and behaving inconsistently after rewiring. These are user reports, not results from our Debian run, but they affect teaching demos where the visible output is the lesson. Confirm the exact board, component, and library combination in Velxio, then repeat important results on physical hardware. Simulation should shorten the path to a bench test, not replace it.
A shared host needs its own access control
The open-source image has no accounts or built-in authentication, according to the README. Its HTTP container also accepts any Host header. That is convenient on localhost and unsuitable as the only boundary on a public server that compiles user code and runs emulator workloads. Put it behind an authenticated reverse proxy, restrict network reachability, and decide who can create projects or consume build capacity.
The default news feed fetches release notes and product news from velxio.dev, caches them, and can display remote media. VELXIO_NEWS=off disables that behavior for private or offline environments. The repository uses AGPLv3 and offers a separate commercial license. A company exposing a modified service over a network should review those terms before building around it.
October code activity matters more than the September release date
GitHub showed 3,109 stars and 13 open issues and pull requests on October 8, 2026, split into 12 issues and 1 pull request. The last push was October 5 at measured commit ff2ff0d. Release v3.0.5 shipped September 2 with project export, wire junctions, scope probes, custom-chip work, theme changes, and many ESP32 fixes.
The recent push and issue activity show ongoing maintenance even though the latest tag is a month older. Velxio earns a trial for embedded teaching, tutorial embeds, and early circuit work. Its value is the shared workspace across code and wiring. Treat the emulator as a fast experiment, and move claims about electrical behavior or peripheral compatibility onto the actual board.