Meshtastic MQTT: Uplink, Downlink, and Privacy

Meshtastic’s MQTT feature lets a node with internet access act as a gateway, copying mesh packets to an MQTT server (uplink) and, if you allow it, bringing packets from that server back onto your local radio mesh (downlink). It’s how separate meshes get linked over the internet and how mesh data reaches dashboards, home automation, and online node maps. It is off by default, and turning it on has real privacy implications.

This guide is based on the official MQTT module and MQTT integrations docs. LoRa Mesh Atlas is not affiliated with Meshtastic.

What MQTT is, briefly

MQTT is a publish/subscribe messaging protocol. Devices publish messages to named “topics” on a server called a broker, and anyone subscribed to those topics receives them. In Meshtastic, a gateway node publishes mesh packets to topics based on region and channel name.

How a Meshtastic MQTT gateway works

The Android docs illustrate the flow (Android MQTT):

Your node → radio → gateway node with internet → MQTT broker → remote gateway → radio → remote node

Key points from the official docs:

• Any node with internet can be a gateway, whether via its own Wi-Fi or Ethernet or via a connected phone (“client proxy”) (MQTT integrations).
• Packets are published as protobufs wrapped in a ServiceEnvelope. If JSON is enabled, some packet types are also published as JSON (JSON isn’t supported on nRF52).
• Topics follow msh/REGION/2/e/CHANNELNAME/USERID, for example msh/US/2/e/LongFast/!abcd1234. The default root topic becomes msh/<REGION> once a region is set.
• Duplicates happen when several gateways serve one mesh, so subscribers should deduplicate by packet ID.

Uplink vs downlink

Uplink and downlink are set per channel, not in the MQTT module, and both default to off (Channel config).

Setting	Direction	Effect
Uplink enabled	Mesh → broker	Packets on this channel are published to MQTT
Downlink enabled	Broker → mesh	Packets from MQTT are transmitted onto your local mesh

The Android docs suggest uplink-only if you just want to monitor your mesh remotely, and caution that downlinking from busy topics consumes your local mesh’s airtime.

Main MQTT module settings

From the MQTT module docs:

Setting	What it does
Enabled	Turns the module on
Server address	Broker to use; blank means the default public server
Username / password	Broker credentials; defaults are used for the public server if left blank
Encryption enabled	Publish packets still encrypted with the channel key (on) or decrypted (off)
JSON enabled	Also publish/consume JSON (unencrypted; not on nRF52)
TLS enabled	Encrypt the connection to the broker
Root topic	Custom topic prefix, useful for private brokers
Client proxy enabled	Use the connected phone or computer’s internet connection
Map reporting enabled	Periodically publish an unencrypted map report (firmware 2.3.2+)

About “Encryption enabled”: the module docs warn that if it’s off, “all messages are sent to the MQTT broker unencrypted … even when your uplink channels have encryption keys set.” The Android docs describe it as choosing which copy of the packet is published, not an extra layer, and say to turn it off only on a broker you own.

About TLS: per the Android docs, a radio connecting to the public broker over its own Wi-Fi or Ethernet uses the TLS setting as stored, connecting in the clear on port 1883 if TLS is off. When the Android app relays MQTT for the radio, it always uses TLS on port 8883 for the public broker.

The public MQTT server

The Meshtastic project runs a public MQTT server, at mqtt.meshtastic.org according to the Android docs. The integrations page lists restrictions to protect LoRa meshes:

• Zero-hop policy. Traffic from the public server reaches directly connected nodes but doesn’t spread further through the local mesh.
• Traffic filtering. On the default key, only certain packet types pass: NodeInfo, text messages (including compressed), position, telemetry, map reports, and routing.
• Location precision filtering. On the default key, only imprecise positions (10–16 bits of precision) are shared.

In August 2024, the project removed the ability to subscribe to all topics on its server, citing concern that public maps were storing and tracking node positions over time. Regional topics such as msh/US/# remain available (MQTT broker changes).

The module docs also warn that the default LongFast channel on the public server “usually has a lot of traffic” and can overload a device, recommending a different channel or your own server if you see problems.

OK to MQTT and Ignore MQTT

Two LoRa settings control how your node interacts with other people’s gateways (LoRa config):

• OK to MQTT (default: off). When on, you approve your packets being uplinked by gateways. When off, nodes receiving your packets “are requested not to forward packets to MQTT.” It applies only to channels using the default keys; custom-key channels ignore it. “This is not a cryptographic solution but a polite request that is enforced in the official firmware.” The Android docs add that on a public broker, a gateway uplinks other nodes’ packets only when they have OK to MQTT on, while your own traffic bridges either way.
• Ignore MQTT. When on, your node ignores packets that arrived via MQTT somewhere along their path (requires firmware 2.2.19+ on both ends). A header flag marks packets that came through MQTT.

Privacy implications

MQTT is the main way local mesh data ends up on the internet:

• Readable by subscribers. The Android docs note that “messages on the public broker are readable by anyone subscribed,” and default-channel traffic is “effectively unencrypted” because the key is well known.
• Neighbors’ data, too. The tips page warns that connecting a node to the public MQTT server “may publish the locations of all nodes in your mesh to the internet.” The OK to MQTT default and the server’s precision filtering reduce this on default keys.
• Map reports are unencrypted. When enabled, they include your node ID and names, position (default precision is a maximum deviation of about 1,459 m), altitude, hardware model, role, firmware version, region, preset, primary channel name, whether you’re reachable on the default channel, and the number of local online nodes. The default and minimum publish interval is one hour (MQTT module).

For more on what’s visible in general, see Meshtastic privacy and encryption.

Private brokers

You can run your own broker (the docs mention Mosquitto, HiveMQ, and EMQX as examples) and point your gateway at it. The integrations page cautions against using the default key on a private broker: private brokers don’t enforce the zero-hop policy, which “can flood the mesh with traffic.” Private brokers are meant for private channels with custom keys. Both gateways in a bridge need the same channel name, key, and root topic.

Common reasons MQTT isn’t working

From the Android docs’ troubleshooting list:

• The gateway has no working internet connection (MQTT doesn’t run over LoRa).
• Wrong broker credentials, or ports 1883/8883 blocked by the network.
• Only uplink or only downlink enabled where you need both.
• Mismatched channel name, key, or root topic between gateways.
• Ignore MQTT turned on in receiving nodes.
• Neighbors’ packets not bridging because their OK to MQTT is off.

Should you enable MQTT?

It depends on why. Uplink-only to a private broker is a common pattern for monitoring your own nodes. Bridging distant meshes is possible but adds airtime on each side. If your goal is seeing nodes on a map, see finding Meshtastic nodes near you, which explains how online maps get their data from MQTT and why they’re incomplete.