Most firmware for LoRa development boards does one job. You flash Meshtastic, or a sensor sketch, or a tracker, and to change what the board does you reflash it. KoaOS takes a different approach. It is a small Unix-style operating system for the Heltec WiFi LoRa 32 V4 that you use from a serial terminal, and it lets you add and remove programs over the network the way you would install packages on a Linux machine.

Hackaday's Jenny List wrote about the project on 5 November 2026, calling it "a small OS for the ESP32-S3 on the Heltec WiFi LoRa 32 V4." The code is on GitHub under the account Koakno. According to the repository metadata, it was created on 12 October 2026 and last pushed on 6 November 2026. It is written in C, MIT licensed, and had 23 stars and 3 forks when we checked. It is less than a month old, and its documentation reads that way, in a good sense: it lists what doesn't work yet.

What KoaOS actually is

KoaOS is headless. Hackaday notes that the only way to talk to it is a serial terminal on the board's USB port. The README adds that what you type also shows on the board's OLED, but the interface itself is the terminal. When you connect, you get a Unix-like shell. The project README and Hackaday's write-up list several built-in programs: a Nano-style text editor, a GPS tool, a weather app and a LoRa APRS client. There is also an SDK for writing your own apps in C.

The app model is the interesting part. KoaOS does not link apps into the firmware image. Apps are compiled from C to WebAssembly and run by wasm3, an interpreter, and the README says app memory lives in PSRAM. Apps ship as .esp packages, which can be installed and uninstalled over the network, so adding a program does not mean rebuilding and reflashing the board.

Sandboxing goes beyond the WebAssembly boundary. The README describes three mechanisms:

  • Manifest capabilities. An app declares what it needs, for example requires=wifi,gps, and the OS enforces that declaration.
  • Per-app storage. Each app gets its own /data/<app>/ folder.
  • A pin allow-list. The OS decides which GPIOs an app can claim; GPS, radio, OLED, USB and power-switch pins can never be handed to an app. On a microcontroller, one stray pin write can do real damage to attached hardware, so this matters.

Some Hackaday commenters pointed out that KoaOS runs on top of FreeRTOS as an Arduino sketch, and one called it more of a runtime environment than an operating system. That's a fair technical point. It is also a familiar argument: plenty of systems people call operating systems sit on a kernel someone else wrote. In practice, KoaOS is a shell, a package manager and a sandbox layered on the Arduino core. Whether that earns the label "OS" matters less than whether the layer is useful.

The hardware it targets

KoaOS supports exactly one board, and the README states plainly that the V3 is not supported because it has no PSRAM. Hackaday also cites the large PSRAM requirement as the reason for V4-only support.

Heltec's product page lists two variants of the V4:

  • V4: ESP32-S3R2 with 2MB PSRAM
  • V4-R8: ESP32-S3R8 with 8MB PSRAM

Both have 16MB of flash and an SX1262 LoRa transceiver. Heltec lists a high-power version covering 863–928MHz at 28 dBm and a low-power version covering 433–510MHz at 22 dBm. Other specs from the same page:

  • Wi-Fi 802.11 b/g/n and Bluetooth LE 5
  • USB-C
  • A 1.25mm 2-pin solar interface and an 8-pin GNSS interface
  • Dimensions of 51.7 x 25.4 x 10.7 mm
  • Pin compatibility with the V3
  • Support for Arduino, PlatformIO, ESP-IDF and MicroPython

Heltec says the two variants use different firmware and asks buyers to select the correct one when flashing, so you need to know which one you have.

The KoaOS README does not say whether it supports one variant, the other or both. Its flash instructions call for QSPI PSRAM and the "No OTA (2MB APP/2MB SPIFFS)" partition scheme, built against ESP32 Arduino core 3.x. If you own the R8 variant, read the build notes carefully before you assume the defaults fit your board, and check the repository's issues. Our sources don't settle the question.

The limits, in the project's own words

The README is unusually frank. Here are the constraints it documents:

  • App size. A .wasm file can be at most 256 KB, and each app gets about 1 MB of PSRAM.
  • Input and output. Apps take input only from the terminal, and the display capability is reserved: only built-in tools draw on the OLED for now.
  • Install transport. Apps install over plain HTTP from a local Python repo_server. The SHA-256 check catches a corrupted download but not a deliberately swapped one, because the hash travels with the package and so proves nothing about who made the file.
  • TLS. HTTPS connections do not validate certificates.
  • Boot security. Secure boot and flash encryption are not enabled.
  • Credentials. The default login is root/1234, which the README calls a convenience rather than protection.
  • Known bug. MeshCore direct messages crash the system.

Put together, KoaOS is a hobby and lab system. It is not something to leave unattended on a network you don't control. That isn't a criticism, and the author says as much. But anyone who reads "sandboxed apps" as "secure device" should note the gap. The sandbox controls what an installed app can do. Nothing controls whether the app you installed is the one you meant to install.

Why the WebAssembly approach is worth watching

Using an interpreter to run code on a microcontroller is not new. MicroPython and various Lua and JavaScript runtimes have done it for years. What KoaOS adds is the combination of a compiled-C workflow, a capability manifest the OS enforces, and network package management, all on a board people already buy for LoRa work. The 256 KB / 1 MB ceilings rule out anything heavy, and the README warns that heavy maths is slow in an interpreter. Within those limits, you can keep a single field board running and swap utilities on and off it: an APRS beacon one day, a GPS logger the next, a custom sensor poller after that, all without reflashing the firmware.

The README's MeshCore bug and the lack of display access for apps show how far the project still has to go before it covers what dedicated mesh firmware does.

What It Means for Makers

Who it's for: people who already own a Heltec WiFi LoRa 32 V4 and prefer a terminal, want to experiment with sandboxed WebAssembly on a microcontroller, or would like to write small C tools for the board without a full Arduino rebuild every time. It is also a compact teaching example for capability-based sandboxing and package management on constrained hardware.

What it replaces or enables: it does not replace Meshtastic or MeshCore firmware for mesh messaging. Its MeshCore support crashes on direct messages, and apps can't use the display. What it does enable is a multi-purpose bench or field board where tools install and uninstall over Wi-Fi. Owners of a V3 are out of luck, since the README says the V3 is unsupported because it has no PSRAM, even though Heltec describes the V4 as pin-compatible with it.

Price and availability: KoaOS is free, MIT-licensed software, available now on GitHub. The README says a web flasher is available at flash.koakno.com. We don't quote a price for the Heltec V4 board, so check current pricing with Heltec or its distributors. KoaOS is an independent project, and its README says it is "not made or endorsed by Heltec."

Before you flash: change the default root/1234 login, keep the device and your local repo_server on a network you trust, and expect some rough edges from a project that is less than four weeks old.

Sources