Velxio 2.0 – Emulate Arduino, ESP32, and Raspberry Pi 3 in the Browser

3/27/2026 at 9:15:59 PM

Velxio 2.0 is live.

A free, open-source emulator for 19 embedded boards: Arduino, ESP32, Raspberry Pi, RISC-V , running real compiled code in your browser.

The best part: it's fully local.

No cloud dependency. No student accounts. No data leaving your network. Self-hostable with a single Docker container.

Universities and bootcamps can deploy it on their own servers and give every student access to a complete embedded development environment, for free.

I've been working on this for over a year, and just shipped v2.0 with ESP32 emulation (via QEMU), a custom RISC-V core, and Raspberry Pi 3 support that runs real Python

by dmonterocrespo

3/28/2026 at 6:23:15 AM

Emulating the CPU is nice, but the trouble has always been emulating the peripherals

Does your editor do this? I tried the example but didn't see e.g. LEDs blinking

by jdnenen

3/28/2026 at 3:51:58 PM

Yes,peripherals are fully emulated, not just the CPU. LEDs blink, buttons respond to clicks, Serial Monitor works, servos rotate, displays render (ILI9341 TFT), and we have 48 o more components from the wokwi-elements library. The Blink example should show the built-in LED toggling on pin 13. If it didn't blink for you, it might be a compilation issue

try the example Traffic Light : Simulate a traffic light with red, yellow, and green LEDs

by dmcrespo

3/28/2026 at 5:56:35 PM

does this handle the timing differences between browser execution and real time hardware? or is it focused on logic verification?

by functional_dev

3/28/2026 at 6:49:09 PM

Both, with a nuance. The AVR simulator syncs to wall-clock time and each frame calculates cycles from real elapsed deltaMs, so delay(1000) takes 1 real second and timer-dependent code (PWM, millis()) runs at correct real time rates. The RP2040 and ESP32-C3 simulators use a fixed cycles-per-frame budget (125MHz/60 and 160MHz/60 respectively), which targets real time but doesn't compensate for frame drops . if the browser stutters, emulated time stretches slightly. All three are cycle-accurate at the instruction level though, so the logic and peripheral behavior is faithful to real hardware regardless of frame timing

by dmcrespo

3/28/2026 at 2:52:29 PM

You can add peripherals There’s a “+” button on the right side of the circuit editor where you can add components like LEDs

by dmcrespo

3/27/2026 at 9:44:08 PM

just curious - if it runs from a docker container, what is the advantage of running the browser as opposed to just ssh'ing in ?

by mech422

3/27/2026 at 9:48:48 PM

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

by dmcrespo

3/28/2026 at 3:01:42 AM

The visual component editor does look pretty nice :-) I guess I always just associated sbc's with a more 'hands on' style...

Anyway, seems like a pretty cool project - congrats!

by mech422

3/28/2026 at 3:16:56 AM

Thanks! The visual editor is actually a big part of the project

I used a little AI to create the graphical interface since I focused heavily on emulation, testing, and refining and optimizing the circuit editor. But now I have plans to improve the UI and make it faster and more intuitive

Still a lot to improve there, but glad it’s useful already

by dmcrespo

3/27/2026 at 9:35:47 PM

Is it easy to feed an elf or bin and run that (esp32c3)? I see compilation available, but I'm playing with asm and have my toolchain figured out already and would just like to emulate the firmware.

by exe34

3/28/2026 at 12:40:30 AM

Another +1 for this one as this is what turns this tool from a toy environment with basic sketches into something that's actually useful for larger projects with a full toolchain, libraries, and so forth.

by mysteria

3/28/2026 at 3:21:01 AM

That’s exactly the direction I’m aiming for

A lot of simulators stop at simple sketches, but the goal with Velxio is to support more realistic workflows , multiple boards interacting, real toolchains, and more complex setups

Still early, but definitely moving in that direction

by dmcrespo

3/28/2026 at 1:14:25 AM

[dead]

by dmcrespo

3/27/2026 at 9:45:53 PM

[dead]

by dmcrespo

3/28/2026 at 1:35:39 AM

[dead]

by alcor-z

3/27/2026 at 8:44:33 PM

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

by dmcrespo

3/28/2026 at 1:46:36 AM

When I try to visit velxio.dev, a CrowdSec page shows up and says I am not allowed to view it. I am a pretty normal android user on firefox mobile, so that is surprising.

I look forward to trying this out though, great project!

by ehnto

3/28/2026 at 2:43:33 AM

Quick update: this should be fixed now. It was an overly aggressive CrowdSec rule blocking some legitimate traffic.

If anyone still has issues accessing velxio.dev, let me know

by dmcrespo

3/28/2026 at 3:46:14 AM

Nice one! I can access it now.

Really awesome project, it runs well on my old android phone, the fact that I can use a tool like this on my phone is pretty wild, you have done well with the UI in that regard. The oscilloscope is a really nice feature too.

by ehnto

3/28/2026 at 4:33:43 AM

Mobile support is something I’ve been paying a lot of attention to, so it's really good to know it runs well even on older devices.

And glad you liked the oscilloscope, that was a fun one to build.You can select the motherboard and ping you want to monitor.

by dmcrespo

3/28/2026 at 2:12:12 AM

Oh, thanks for reporting this.that definitely shouldn’t happen. It’s likely an overly aggressive CrowdSec rule blocking some legitimate traffic. I’ll look into it and adjust the configuration

by dmcrespo

3/27/2026 at 11:44:17 PM

Hi, adding WS2812B LED strips of arbitrary length would be awesome! Scrolling the canvas is sometimes problematic. Otherwise very interesting.

by philkrylov

3/27/2026 at 11:48:13 PM

Thanks! That’s a great suggestion, supporting WS2812B strips with arbitrary length is definitely something I’d like to add. I also have in mind adding many more LED based components. I’ll take a look at improving the canvas scrolling too

by dmcrespo

3/27/2026 at 10:18:31 PM

I often write a bunch of Esphome ‘code’ , which I then use with various esp32 based devices (mostly from M5stack) via esphome/HomeAssistant.

Can this project help me in any way during dev stage before uploading the code to device just to see it doesn’t work ? Eg could I use this to somehow compile&run those esphome yamls via this emulator?

by radicality

3/27/2026 at 10:32:55 PM

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

by dmcrespo

3/27/2026 at 11:26:15 PM

That would be awesome! ESPHome is the easiest way to integrate custom devices into your HomeAssistant with online updates, logs, and other functionality. Nothing else comes close.

by cyberax

3/28/2026 at 12:02:45 AM

[dead]

by dmcrespo

3/29/2026 at 3:52:13 AM

Nice. Yeah definitely do consider it, esphome is quite popular with people using HomeAssistant

by radicality

3/29/2026 at 6:05:52 AM

Yeah, definitely, ESPHome fits really well with what I’m building. I’m currently going through the docs to see how to integrate it properly

by dmcrespo

3/28/2026 at 12:20:40 PM

Really impressive - browser-based hardware emulation is a brutal WebAssembly performance problem. Curious what you're doing for the rendering layer: are the circuit visualizations on canvas/WebGL, or DOM-based? I've been hitting similar render-loop problems with a deck.gl mapping project (realtime vessel positions, thousands of points updating simultaneously) and the pattern I found that helped most was batching state updates on a fixed 2s interval before diffing the render layer - prevents the WebGL context from recomposing faster than the data actually changes meaningfully. Does Velxio have a similar throttle, or does it redraw on every emulation tick?

by deringeorge2

3/28/2026 at 3:42:41 PM

Thanks! The rendering is DOM-based, circuit components are Web Components (from the wokwi-elements library) wrapped in React, and wires are SVG. No Canvas/WebGL, which keeps it simple for the component count we're dealing with (typically dozens, not thousands).

The emulation itself is pure JavaScript (avr8js), not WebAssembly. The simulation loop runs on requestAnimationFrame and executes 267K AVR instructions per frame (16MHz / 60fps) in a synchronous batch. Port listeners use dirty-checking so the UI is only notified when a GPIO register actually changes value and since all those cycles run in one JS microtask, React reconciles exactly once per frame regardless of how many state changes happened during the batch

So there's no explicit throttle interval like your 2 sec approach, but the architecture achieves something similar. the CPU runs freely, state changes are coalesced within each rAF frame, and the DOM only sees the final result. For your deck.gl case with thousands of points, the 2s batch makes sense since you're dealing with a much higher entity count hitting the GPU , our problem domain is simpler (dozens of components) but the cycle-accurate emulation is the expensive part

by dmcrespo

3/28/2026 at 2:20:52 AM

The container instructions has `-d` in it, but note that after booting the container it downloads another, I don't know, 300+mb more (its still downloading as I write), so if you can't connect that's why.

Might be better to not include `-d` in the instructions?

by GCUMstlyHarmls

3/28/2026 at 2:44:32 AM

Good catch!!! thanks for pointing that out

The container pulls additional assets on first run (mainly emulation dependencies), which is why there's extra downloading even with -d.

You're right that it can be confusing. I'll update the instructions to make this clearer (and probably remove -d so users can see what's happening)

by dmcrespo

3/27/2026 at 9:34:21 PM

First of all: Awesome work! Playing with it now.

One suggestion: The main splash screen image is nearly 8MB big. It takes a noticeable time to download on my connection. I'm not sure what bandwidth costs these days, but seems like that could be something to optimize.

by hex4def6

3/27/2026 at 9:42:32 PM

Thanks a lot! Yes, that’s something I have pending, I’m planning to replace it with an SVG or an animated GIF to improve loading time

by dmcrespo

3/27/2026 at 10:54:05 PM

Nice work! One minor point for me: it wasn’t immediately clear that you need to press Compile before Play gets enabled (e.g. Arduino IDE let's you upload right away and compiles if needed)

by wumms

3/27/2026 at 11:03:50 PM

Good point.I’ll improve that. Thanks!

by dmcrespo

3/28/2026 at 3:18:42 AM

Quick update: traffic is still coming in waves, had to scale up compilation workers to keep up with demand

Things are more stable now, but still tuning performance under load

If anyone finds it useful, the source is here: https://github.com/davidmonterocrespo24/velxio

Always happy to get feedback or contributions.

by dmcrespo

3/28/2026 at 1:35:49 AM

Can someone who has used both wokwi and this do a compare/contrast? The footer suggests that it's built on top of wokwi-elements

by kaycebasques

3/28/2026 at 2:08:17 AM

Velxio is definitely inspired by Wokwi, and I really like what they’ve built. Parts of Velxio also reuse open-source components , for example, the wokwi elements are used for the visual SVG rendering of boards and peripherals, but they don’t include any emulation logic.

I also integrated a couple of existing open-source emulators, like the Raspberry Pi Pico and Arduino ones. And I even reached out to the creator of Wokwi to share the project.

In terms of differences, one of the biggest ones is that Velxio supports multiple heterogeneous boards in the same circuit: for example, two Arduinos connected over SPI or serial, ESP32 with Arduino, Raspberry Pi 3 with a Pico, etc.

Another major difference is the focus on full emulation, including ESP32 (via QEMU) and a Raspberry Pi 3 running Linux (still in beta).

There are also quite a few other differences, but those are probably the most notable ones

by dmcrespo

3/27/2026 at 10:52:26 PM

This is a great idea. It’s always been inconvenient requiring access to the physical board just to be able to test these sort of projects.

by urbandw311er

3/27/2026 at 11:02:18 PM

Exactly,that’s the idea. Not having to flash the chip a thousand times just to see if everything works. The goal is to let you test the setup as fast as possible, ideally without installing anything locally

by dmcrespo

3/28/2026 at 8:37:32 PM

From what I can see, I cannot give it an ESP32-C6 firmware binary to execute, I have to compile my source code (C only) and the source has to use Arduino APIs. Under the hood it's still QEMU.

by pshirshov

3/29/2026 at 6:08:25 AM

You're partially right. ESP32-C6 isn’t supported yet (only ESP32, S3, CAM, C3 for now), and the current flow is Arduino-based via arduino-cli — ESP-IDF support is planned a future You’re also right about binaries, you can’t upload an ELF/BIN yet, everything goes through the built-in compilation pipeline (but it’s on the roadmap).

Appreciate the feedback.

by dmcrespo

3/28/2026 at 7:59:04 AM

That looks awesome, thank you for your hard work! I would love tinker with it, but I'm not sure how to abstract things connected to those supported u_controller boards? Example, 7x16 Pico unicorn hat is driven by RP2040 PIO.

by sourdoughtronic

3/28/2026 at 3:47:27 PM

PIO isn't abstracted yet, we use rp2040js which has a full PIO emulator that executes the actual PIO instruction set (MOV, SET, PUSH, PULL, etc.) cycle by cycle, including the FIFOs and clock dividers. So it's not an abstraction. it's a direct emulation of the PIO state machines, same as how avr8js runs real AVR instructions

by dmcrespo

3/28/2026 at 11:14:02 AM

Isn't the problem with these emulations that they are not realtime and therefore will never give true feedback? As in the simulation will unlikely to translate to real world behaviour.

by varispeed

3/28/2026 at 3:45:44 PM

[dead]

by dmcrespo

3/28/2026 at 4:45:48 AM

Pretty cool project! if you're checking it out, try one of the built-in examples and hit "Compile + Play". It runs immediately, no setup required

by noahnathan25

3/28/2026 at 4:47:22 AM

Thanks! Yeah, that’s probably the easiest way to get started, just load an example and hit “Compile + Play”.

I tried to make it as close to zero-setup as possible so people can just jump in and experiment

by dmcrespo

3/28/2026 at 4:05:21 AM

This is fantastic. I am doing my first-ever consumer electronics product and this would save a lot of soldering time

by mvkel

3/28/2026 at 4:34:25 AM

That’s awesome — and exactly the kind of use case I had in mind

Being able to iterate without constantly flashing hardware can save a lot of time early on.

If you end up trying it in your workflow, I’d love to hear how it goes

by dmcrespo

3/28/2026 at 3:11:33 AM

Awesome. Is there any chance of getting MicroPython or CircuitPython support?

by flymasterv

3/28/2026 at 3:17:28 AM

I’m currently working towards that.

The Raspberry Pi emulation already runs Python, and I’d like to extend that into proper MicroPython / CircuitPython support for microcontrollers as well

It’s a bit tricky depending on the board/emulator, but definitely a priority!

by dmcrespo

3/28/2026 at 4:09:42 AM

I like this Idea but I don't want to use this. I know what kind of prompt U using to create this one: "Create something like Wokwi and make it local"

by triilman

3/28/2026 at 4:35:46 AM

Fair enough , though there’s quite a bit of low-level work behind it (emulation cores, QEMU integration, protocol timing, etc)

Definitely inspired by existing tools, but trying to push further into full multi-board emulation and local-first workflows

by dmcrespo

3/28/2026 at 9:25:04 AM

Good job

by xyrox1

3/28/2026 at 3:52:37 PM

Thanks, appreciate it!

by dmcrespo

3/28/2026 at 4:57:22 AM

Great project! Now all there is left to do is a VS Code plugin. Also make it play nice with platform io.

by suwsixect

3/28/2026 at 5:09:28 AM

[flagged]

by dmcrespo

3/28/2026 at 2:42:15 AM

[dead]

by dmcrespo

3/28/2026 at 1:56:49 AM

[dead]

by mertleee

3/28/2026 at 5:31:05 AM

Abang

by orangmisterius

3/28/2026 at 3:52:49 PM

Thanks, appreciate it! Glad you like it

by dmcrespo

3/28/2026 at 7:49:55 AM

Nice Project. One of the benefits of such small boards is the ability to provide a "Hands on" experience. Use your hands to wire, press buttons and turn knobs. Emulating all this is a big thing but it takes away the learning in my eyes. It's like flying drones. It looks cool but gets boring after 10 minutes.

by Surac

3/28/2026 at 3:48:55 PM

[dead]

by dmcrespo