# MeshCore: multi-hop LoRa routing for embedded developers

> MeshCore is a C++ library and firmware set for multi-hop packet routing over LoRa radios. It targets developers who want a decentralized network without the internet, and it ships prebuilt firmware so you can flash a supported board before you compile anything.

**meshcore-dev/MeshCore** — A new lightweight, hybrid routing mesh protocol for packet radios

- Repository: https://github.com/meshcore-dev/MeshCore
- Website: https://meshcore.io
- Stars: 3,767 · Forks: 1,391
- Language: C
- License: MIT
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/meshcore-dev-meshcore

## Who MeshCore is for, and the problem it removes

The README frames MeshCore as a lightweight, portable C++ library that adds multi-hop packet routing to embedded projects using LoRa and other packet radios. The problem it addresses is range: a single radio reaches only so far, so nodes relay messages through intermediate nodes to extend coverage. The project positions this for off-grid, emergency and tactical situations where no traditional communication infrastructure exists.

The audience is narrower than the feature list suggests. MeshCore is for developers building custom embedded solutions, not for people who simply want to chat over LoRa. The README draws that line explicitly against Meshtastic, which it describes as tailored for casual LoRa communication, and against Reticulum, which it describes as offering advanced networking. MeshCore's stated position is a balance of simplicity and scalability. If you want an app and a default configuration, the companion firmware and the published clients cover that, but the repository is organized around example applications you are expected to modify.

## Fixed node roles and hop limits: how the routing is constrained

The routing model rests on two constraints rather than on a routing table you tune per packet. First, hops are configurable, and the README says the limit exists to balance network efficiency against excessive traffic. Second, nodes have fixed roles, and the README states that Companion nodes do not repeat messages at all, specifically to prevent adverse routing paths from being used. That is a deliberate refusal of flexibility: a companion radio attached to a phone will not quietly become part of the backbone.

The repository layout reflects this split. The examples directory contains companion_radio, kiss_modem, simple_repeater, simple_room_server, simple_secure_chat and simple_sensor. Repeating is the job of the repeater example, and the room server example is described as a simple BBS server for shared Posts. The roadmap confirms the direction: enhanced zero-hop neighbour discovery and standardized bridge mode for repeaters are marked done, while standardized transport codes for zoning and filtering, round-trip manual path support, and multiple sub-meshes in the companion apps remain unchecked. Those unchecked items are where the current design still has rough edges.

The contribution guidelines are unusually opinionated and tell you what the codebase will accept: no dynamic memory allocation except during setup and begin functions, and no unnecessary layers. That constraint shapes what you can build on top of MeshCore as much as the routing does.

## Flashing prebuilt firmware before you touch PlatformIO

The fastest path does not involve compiling. The README directs you to launch the flasher, select a supported device, and choose one of three firmware types: Companion, Repeater or Room Server. Flashing is done in the browser, and the README mentions Adafruit ESPTool as one of the tools used for this.

Open the flasher page in a browser and pick your board from the supported list.

```bash
# no local command: flashing happens in the browser at
# https://meshcore.io/flasher
```

After flashing completes, the README says you connect with one of the MeshCore clients. Companion firmware connects over BLE, USB or Wi-Fi depending on the firmware type you flashed. Repeater and room server firmware is configured over USB using the web config tool at https://config.meshcore.io, and can also be managed over LoRa from the mobile app through the Remote Management feature.

If you would rather build from source, the README's developer path is PlatformIO inside Visual Studio Code. Clone the repository, open it in VS Code, and start from one of the examples. Unit tests run through PlatformIO's test runner against the native environment:

```bash
pio test --environment native --verbose
```

The repository also carries a platformio.ini, a build.sh, a build_as_lib.py, a library.json and a default.nix, so the library can be consumed as a PlatformIO or Nix dependency rather than only as an application.

## Where the documentation is thin and the design costs you

Hardware support is the first constraint. The README states that MeshCore is designed for devices listed in the MeshCore Flasher, and the hardware section offers no second source. The README names Heltec and RAK Wireless as supported LoRa radio families, but the flasher list is the authority. If your board is not there, the prebuilt path is closed and you are compiling from source against a target that may not exist.

Rollback is undocumented. The README describes flashing a prebuilt binary and connecting a client, and it does not describe reverting a device to its previous firmware. Anyone flashing a repeater that is already deployed should treat that silence as a gap to resolve before, not after.

The role model also removes an option. Because Companion nodes never repeat, you cannot stretch coverage by leaving a spare companion radio on a hill. You need repeater firmware on that device, and the roadmap item for multiple sub-meshes in the companion apps is still unchecked, so segmenting one radio across several meshes is not something the README claims today. Zoning and filtering via standardized transport codes are likewise on the unchecked list. If your deployment depends on partitioning traffic by group or region, that work is described as planned, not present.

## MeshCore compared with Meshtastic and Reticulum

The README itself makes both comparisons, which is more useful than a third-party framing. Meshtastic is described as tailored for casual LoRa communication. Reticulum is described as offering advanced networking. MeshCore is placed between them, prioritizing lightweight multi-hop packet routing for embedded projects.

In practice the difference shows up in what you are handed. A casual-oriented stack gives you a working configuration and a client, and you accept its defaults. An advanced networking stack gives you more layers and more concepts to configure. MeshCore gives you example applications and a small set of node roles, and expects you to write the application. The contribution guidelines reinforce that expectation: think embedded, keep code concise, avoid layers. The trade is real. You get a codebase small enough to read and modify, and you give up the abstractions that make a network stack convenient to extend without touching the core.

If your goal is a network that works out of the box with minimal code, the casual-oriented option is the better fit. If your goal is a network you can reshape at the packet level, the advanced option offers more surface. MeshCore is for the case in between: you want multi-hop routing, you are willing to write firmware, and you want the routing core to stay small.

## Licence, releases and the cost of keeping up

MeshCore is released under the MIT License, and the README states you are free to use, modify and distribute it for personal and commercial projects. That is permissive and imposes no copyleft obligation on your own firmware. It also means the project makes no warranty claim, so the fitness of a flashed repeater for an emergency deployment is yours to establish. Nothing here is legal advice; read license.txt in the repository for the operative text.

The release cadence is visible in the tags. Companion, Repeater and Room Server firmware all reached v1.17.1 on 2026-08-14, three releases within a minute of each other. That synchronized versioning is convenient: you can track one number across the three firmware types instead of reconciling three independent schemes. The last push to the repository was on 2026-09-23.

Upgrade cost is concentrated in the field devices. Repeaters and room servers are typically installed at height or in remote locations, and the README's management story for them is USB configuration or LoRa remote management from the mobile app. A version bump therefore means either a physical visit or a remote management session, and the README does not describe a rollback path if a new firmware misbehaves on a deployed node. Budget for that before you standardize on a version.

## Conclusion

Adopt MeshCore if you are building an off-grid or infrastructure-free network on supported LoRa boards and you want a small C++ codebase with fixed node roles and no dynamic allocation after setup. Do not adopt it if you need a long-range network on hardware outside the flasher list, or if you expect the README to document rollback, since it does not. Before committing, open https://meshcore.io/flasher, confirm your exact board appears there, and read docs/faq.md alongside the docs site for the firmware type you intend to run.

## FAQ

### What is MeshCore?

It is a lightweight, portable C++ library for multi-hop packet routing on embedded devices using LoRa and other packet radios. The repository also ships prebuilt Companion, Repeater and Room Server firmware and a set of example applications.

### Which is better, Meshtastic or MeshCore?

The README describes Meshtastic as tailored for casual LoRa communication and positions MeshCore as a balance of simplicity and scalability for custom embedded solutions. The choice depends on whether you want a ready-made setup or a routing core you modify yourself.

### Is MeshCore free to use?

Yes. It is released under the MIT License, and the README states you are free to use, modify and distribute it for personal and commercial projects.

### Does MeshCore work in the US?

The README does not discuss regional availability or radio regulations. It only states that MeshCore is designed for devices listed in the MeshCore Flasher, so hardware support is the documented constraint rather than geography.

### How do I install MeshCore on a supported device?

Launch https://meshcore.io/flasher, select a supported device, and flash one of the Companion, Repeater or Room Server firmware types. Once flashing is complete, connect with one of the listed MeshCore clients.

### How do I set up a MeshCore repeater?

Flash the Repeater firmware, then configure it over USB with the web config tool at https://config.meshcore.io. The README also notes that repeaters can be managed over LoRa from the mobile app using Remote Management.

## Sources

- [License: MIT](https://github.com/meshcore-dev/MeshCore/blob/main/LICENSE)
- [meshcore-dev/MeshCore on GitHub](https://github.com/meshcore-dev/MeshCore)
- [Project website](https://meshcore.io)
- [README](https://github.com/meshcore-dev/MeshCore/blob/main/README.md)
- [Releases](https://github.com/meshcore-dev/MeshCore/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/meshcore-dev-meshcore