Meshtastic Node Roles
Every Meshtastic node runs exactly one role, and that single setting decides whether the node rebroadcasts other people’s packets, whether it shows up in the mesh’s node list, and how hard it hits the battery. Choosing the wrong role is the most common way a well-meaning node quietly harms a mesh — a ground-level ROUTER in a city, for example, floods the channel instead of helping it. This reference lists the 12 active roles plus the one deprecated role (ROUTER_CLIENT), with what each does, whether it rebroadcasts, whether it appears in the node list, its relative power cost, and honest “best for / avoid when” guidance.
All behaviour below is transcribed from the official Meshtastic device-configuration documentation and verified on 15 July 2026. Role definitions can change between firmware releases — always confirm against the current docs for your firmware version.
Quick rules of thumb: most nodes should stay on CLIENT (the default). Use ROUTER or REPEATER only for a fixed, elevated, permanently-powered node that is genuinely improving coverage. Use CLIENT_MUTE where you want to talk but not add relay traffic. For a node whose main job is reporting telemetry — for instance a Bitaxe bridged onto the mesh by DCENT_Raven — SENSOR is the closest documented fit.
| Role | What it does | Rebroadcasts | In node list | Power | Best for | Avoid when |
|---|---|---|---|---|---|---|
CLIENT (default) | Default role. App-connected or standalone messaging device; rebroadcasts a packet only when no other node already has. | Yes (only if no closer node did) | ✓ Yes | regular | The default for handhelds and everyday user nodes that should also help relay for the mesh. | You want a silent listener (use CLIENT_MUTE) or a dedicated always-on relay (use ROUTER or REPEATER). |
CLIENT_MUTE | A user device that does NOT forward other nodes' packets — cuts congestion on dense meshes. | No | ✓ Yes | lowest | Nodes in an already well-covered area where you want to send and receive but not add relay traffic. | You are the only link between two parts of the mesh — muting yourself breaks that path. |
CLIENT_HIDDEN | Broadcasts only as needed for stealth or power savings; does not appear in other nodes' lists. | Local only | — No | lowest | Privacy or low-power deployments where the node should stay off the public node list. | You want the node to be discoverable or to relay for others. |
CLIENT_BASE | Personal base station that always rebroadcasts to and from your favorited nodes. | Yes (favorites only) | ✓ Yes | regular | A home base that should reliably relay for your own favorited devices without acting as full public infrastructure. | You need to relay for the whole mesh — use ROUTER instead. |
TRACKER | Broadcasts its GPS position as priority packets. | Awake only | ✓ Yes | regular / low | GPS trackers and moving assets whose main job is reporting location. | The device has no GPS, or you need a dedicated relay. |
LOST_AND_FOUND | Periodically broadcasts its location as a message on the default channel to help recover a lost device. | Yes | ✓ Yes | regular | Temporarily locating a misplaced node. | Normal operation — it chats on the default channel and is not a general-purpose role. |
SENSOR | Broadcasts telemetry (sensor) packets as priority and sleeps between reports (no rebroadcast while asleep); for environmental or device-telemetry reporting nodes. | Awake only | ✓ Yes | regular / low | Environmental or device-telemetry nodes whose primary job is reporting sensor metrics. | You need a dedicated always-on relay — use ROUTER or REPEATER. |
TAK | Optimized for ATAK (Android Team Awareness Kit) integration; reduces routine broadcasts. | Yes | ✓ Yes | regular | Nodes paired with ATAK for tactical or team situational awareness. | You are not using ATAK. |
TAK_TRACKER | Standalone TAK node that automatically sends position (PLI) broadcasts and reduces routine traffic. | Yes | ✓ Yes | regular | A GPS-equipped TAK node reporting position without a paired phone. | You are not using ATAK, or the device has no GPS. |
REPEATER | Infrastructure node that extends coverage by always rebroadcasting each packet once; no local user interface and does not appear in the node list. | Yes | — No | high | Elevated, permanently-powered relay sites (hilltop or rooftop) whose only job is coverage. | Battery-critical or poorly-sited nodes — a REPEATER always rebroadcasts and is hidden from the node list, making faults hard to diagnose. |
ROUTER | Infrastructure node that extends coverage by always rebroadcasting each packet once; appears in the node list. | Yes | ✓ Yes | high | Well-placed, mains- or solar-powered backbone nodes that should relay for the whole mesh. | Ground-level or battery-limited nodes — a misused ROUTER congests the mesh. Use CLIENT instead. |
ROUTER_LATE | Infrastructure node that rebroadcasts each packet once, but only after all other roles have taken their turn. | Yes (after other roles) | ✓ Yes | high | A secondary or backfill relay behind existing routers, filling gaps without being the first hop. | You want the primary relay at a site — use ROUTER. |
ROUTER_CLIENT DEPRECATED — firmware 2.3.15 | DEPRECATED in firmware 2.3.15. Formerly combined ROUTER relaying with normal client messaging; removed to prevent misuse. Use CLIENT for a user device, or ROUTER / ROUTER_LATE for a dedicated relay. | n/a (deprecated) | n/a | n/a | — (deprecated; do not use) | Always — it no longer exists in current firmware. Choose CLIENT, or ROUTER / ROUTER_LATE. |
“Power” and “Rebroadcasts” are the relative values published in the Meshtastic device docs. Full machine-readable data — including the deprecation note — is in the JSON download, the CSV download, and the REST API (add ?status=active or ?status=deprecated to filter).
Why ROUTER_CLIENT is gone
ROUTER_CLIENT used to combine ROUTER relaying with normal user messaging on one device. It was deprecated in Meshtastic firmware 2.3.15 because it encouraged badly-placed nodes to act as routers and congest the mesh. If you see it recommended in an older guide, use CLIENT for a user device, or ROUTER / ROUTER_LATE for a dedicated relay instead.
Related
Pick hardware in the Meshtastic / LoRa device database, compare devices in the Meshtastic device comparison, or start at the Mesh Networking hub. Building a fixed relay? See the solar Meshtastic node build guide.
Credit to the Meshtastic Project for publishing the open documentation this reference is built on.