Meshtastic MQTT and internet bridging

Meshtastic works without the internet. Its normal purpose is to let nearby LoRa radios exchange short messages and data directly, with other radios relaying packets when necessary. MQTT is an optional addition that can connect a Meshtastic node to an internet service and bridge traffic between physically separate radio meshes.

That bridge can be useful. A community in one city can exchange selected traffic with a community in another city or country. A node operator can also monitor a local mesh remotely, feed telemetry into another application, or report a node to an online map. The trade-off is that traffic is now passing through internet infrastructure, so the system is no longer purely off-grid and new privacy and security questions apply.

This article explains the difference so you can decide whether MQTT belongs in your network. For the radio-only foundation, read What is Meshtastic and how it works.

What is MQTT?

MQTT originally stood for Message Queuing Telemetry Transport. It is now commonly known simply as MQTT: a lightweight publish-and-subscribe messaging protocol designed for the Internet of Things (IoT), meaning connected devices such as sensors, controllers and small computers. It uses little bandwidth and can run on devices with limited memory and processing power. MQTT.org describes MQTT as an OASIS-standard lightweight publish/subscribe protocol for IoT systems.

A simple analogy is a set of labelled notice boards:

A device publishes a message by placing it on a particular notice board.
That notice board is called a topic.
Other devices subscribe to the topics they want to follow.
A central server, called the broker, accepts published messages and distributes them to subscribers.

The broker is an internet service, not a LoRa radio. Gateways reach it through Wi-Fi, Ethernet or supported client-proxy functionality. MQTT does not increase a LoRa signal’s physical range; it adds an internet path between radios or software.

How Meshtastic uses MQTT

A Meshtastic node with internet access can act as a gateway between a local LoRa mesh and an MQTT broker. The official MQTT configuration documentation says that the module forwards packets to an MQTT server when the device is connected through Wi-Fi or Ethernet; selected channels must also have uplink and/or downlink enabled. See the official Meshtastic MQTT module configuration.

A typical path looks like this:

A user sends a message through a Meshtastic app and local radio node.
The message travels over LoRa and is heard by an internet-connected Meshtastic gateway.
If MQTT uplink is enabled for that channel and the packet is allowed to use MQTT, the gateway publishes it to the configured broker and topic.
A second gateway, perhaps in another city or country, is subscribed to the same broker topic.
If that gateway has downlink enabled for the matching channel, it receives the packet from MQTT and injects it into its local radio environment.
Nearby Meshtastic nodes can receive the packet over LoRa, subject to the broker policy, channel settings and local rebroadcast rules.

The packet header contains a one-bit Via MQTT flag. When set, it tells receiving software that the packet entered the radio mesh through an MQTT gateway rather than arriving solely through LoRa. This distinction is part of the current Meshtastic packet format. See the official Meshtastic technical overview and packet-header description.

The Via MQTT flag is useful because an internet-assisted connection can otherwise look deceptively like extraordinary radio coverage. A node in Europe seeing a node in North America does not mean a LoRa transmission crossed the Atlantic; it probably arrived through MQTT.

What MQTT bridging enables

MQTT can support several practical uses:

Connecting selected traffic between Meshtastic communities in different towns, regions or countries
Viewing activity from a remote mesh without keeping a local radio within direct range
Publishing node information and approximate positions to public maps
Sending telemetry to dashboards, home-automation systems or logging tools
Building alerts and data-processing integrations around mesh traffic
Providing an internet-assisted path around a mountain, coverage gap or other radio obstruction

The official integration guide describes global bridging, monitoring integrations and MQTT-fed applications. It also explains that the Meshtastic device can publish raw protobuf packets and, in some versions and configurations, selected JSON representations. See the official Meshtastic MQTT integration overview.

MQTT does not merge every radio into one unrestricted mesh. Broker, topic, channel, encryption, direction and service restrictions determine which traffic moves between locations.

Uplink and downlink

Setting	Direction	Practical effect
Uplink	LoRa mesh to MQTT	The gateway publishes eligible packets heard on the selected channel to the broker.
Downlink	MQTT to LoRa mesh	The gateway receives eligible packets from the broker and transmits them into the local radio environment.
Both	Two-way	The local mesh can send to and receive from the MQTT-connected network.
Neither	No channel bridge	Enabling the MQTT module alone does not bridge that channel.

Uplink-only is a sensible starting point when the goal is remote monitoring or map reporting. Downlink deserves more caution because every packet transmitted from the internet into LoRa consumes scarce local radio airtime.

The Meshtastic public MQTT service currently applies a zero-hop policy to traffic coming from the public broker: a directly connected gateway transmits the data, but that traffic is not allowed to continue propagating throughout the local mesh. The service also filters traffic types and reduces location precision on the default public key. These restrictions exist to protect local meshes and broker capacity. The current public-broker restrictions are documented here.

Configuration basics

MQTT is disabled by default. On Android, the settings are under Settings and MQTT. Apple applications place them under Settings, Module Configuration and MQTT. The Web client and Python command-line interface also expose the module settings. Menu names can change between app releases, so use the current official configuration page if your screen differs.

The main settings are:

Setting	Meaning	Guidance
Enabled	Turns the MQTT module on or off	Leave it off for a purely off-grid node.
Server address	The hostname of the MQTT broker	The documented default is `mqtt.meshtastic.org`.
Username and password	Credentials used to authenticate with the broker	Use the broker-issued credentials for a private service. The firmware supplies public-service defaults when its default broker is selected and fields are not overridden.
Root topic	The base path under which messages are published	If no custom root is configured, the integration documentation describes `msh/REGION`, where the region separates traffic such as `US` from other radio regions.
Encryption enabled	Controls whether the Meshtastic MQTT packet remains encrypted	Do not disable it merely for convenience; the official configuration warning says disabling it sends messages to the broker unencrypted even when the uplinked channel has a key.
TLS enabled	Requests Transport Layer Security for the connection to the broker	Use TLS with a broker that supports it. TLS protects the network connection, not information after it reaches the broker.
Map reporting	Sends a special unencrypted map report	Enable it only after choosing an acceptable position precision.

For the public service, the current official configuration reference lists mqtt.meshtastic.org as the default address and documents the default credentials used by firmware. It also warns that the public LongFast channel can carry enough traffic to overload a device, recommending another channel or a private broker if problems occur. Verify current defaults and warnings before configuring a node, because public-service details can change.

A basic setup is:

Connect the gateway node to the internet through supported Wi-Fi, Ethernet or client-proxy functionality.
Open the MQTT module settings and enable MQTT.
Select the public broker or enter the address and credentials for your private broker.
Choose the root topic. Gateways intended to communicate must use compatible topic paths.
Enable TLS when supported by your broker and device.
Open the channel configuration and enable uplink, downlink or both for only the channels that should cross the bridge.
Confirm that remote gateways use compatible channel names and keys.
Test with limited traffic before leaving downlink enabled permanently.

Frequency regions remain relevant worldwide. MQTT may connect gateways in the United States, Europe, Australia, Asia or elsewhere, but each gateway’s LoRa transmission must use the correct legal region for its physical location. MQTT does not permit a US radio to transmit European frequencies, or vice versa. Consult Meshtastic’s region-by-country guide and the national regulator where the transmitter operates.

Maps and public node directories

MQTT provides the internet path used by Meshtastic map-reporting services. The official map is available at map.meshtastic.org, and other community directories may consume compatible public data.

Map reporting is separate from ordinary channel traffic. When enabled, a node periodically publishes an unencrypted report containing its node ID, long and short names, position with configurable precision, altitude, hardware model, role, firmware version, LoRa region, modem preset, primary-channel name and related network information. The documented default report interval is one hour, and one hour is also the minimum. The default position precision allows a substantial location deviation rather than publishing an exact point. The complete map-report fields and precision controls are listed in the MQTT module documentation.

Do not assume that map reporting is harmless because its default position is approximate. A stable approximate point, node name and repeated reports may still reveal a home, workplace, hilltop installation or travel pattern. Publish only what you are comfortable making public. For a broader discussion, read Maps, coverage, and public node directories.

Privacy and security implications

A LoRa transmission is already observable by nearby radio receivers. MQTT expands the potential audience from people within radio range to broker operators, internet-connected subscribers and systems that store or process the broker’s data.

Important risks include:

Public-broker subscribers may collect messages, node identifiers, timestamps and other exposed data.
A broker operator may log traffic or connection metadata.
Messages may be retained by integrations even if the MQTT broker itself does not retain them.
The default Meshtastic public channel uses a publicly known key and should be treated as public, not confidential.
Disabling MQTT packet encryption exposes message content to the broker even when the radio channel was configured with a key, according to the official module warning.
Map reports are deliberately unencrypted and designed for online visibility.
TLS protects data between a gateway and broker from network interception, but it does not hide data from the broker or authorized subscribers.

MQTT authentication answers “who may connect to this broker?” Topic access-control lists answer “which topics may that account publish or subscribe to?” TLS answers “is the connection protected in transit?” Meshtastic channel encryption answers “can someone without the channel key read the application payload?” These are different layers and none should be treated as a substitute for all the others.

For private communication, use a private channel with a strong, non-default pre-shared key, a private broker with individual credentials and restrictive topic permissions, and TLS. Even then, remember that routing metadata and operational logs may exist. Read Channels, encryption, and privacy before bridging sensitive traffic.

Protobuf and JSON over MQTT

Protocol Buffers, usually called protobuf, are a compact binary format for structured data. Meshtastic’s native MQTT bridge carries raw protobuf MeshPackets inside a protobuf ServiceEnvelope. This is efficient and preserves Meshtastic packet information, but a normal text viewer cannot make the binary payload readable without the Meshtastic protobuf definitions and a decoder.

JSON, or JavaScript Object Notation, is a human-readable text format commonly used by dashboards, scripts and home-automation tools. Older and some current Meshtastic documentation describes JSON topics for selected packet types and notes that JSON is not supported on nRF52 devices. However, the newer official Android MQTT page says firmware JSON output has been removed and that json_enabled remains only for legacy compatibility.

Because the official pages currently disagree, treat native protobuf as the dependable current bridge format. Before designing a new JSON integration, verify the behavior of your exact firmware, device platform and client release against both the general MQTT integration guide and the current Android MQTT guide. Do not assume that seeing a JSON switch in an application means the firmware still publishes JSON.

When to use MQTT

MQTT is a reasonable choice when:

You intentionally want to connect geographically separated communities.
You need uplink-only remote monitoring of a mesh or fixed installation.
You want selected nodes to appear on public maps.
You are integrating telemetry with a controlled dashboard or automation system.
You understand that the internet path is an additional dependency.
You can manage broker access, channel keys and radio airtime responsibly.

Avoid MQTT, or keep it disabled, when:

The purpose of the deployment is fully off-grid operation.
Participants expect all traffic to remain within local radio range.
The network carries sensitive information and you cannot operate a suitably protected broker.
The local LoRa channel is already congested.
You do not control which internet traffic would be downlinked into the mesh.
Publishing node identity or position would create a privacy or site-security risk.

A community can use both approaches without confusion by keeping its ordinary local channel radio-only and creating a separate, clearly documented channel for MQTT experiments. Node roles and MQTT are independent settings: changing a node to router or repeater does not automatically make it an internet gateway. See Meshtastic node roles explained.

Public broker or private broker?

Public Meshtastic broker	Private broker
Quick to test and maintained for community use	Requires installation, updates, monitoring and backups
Shared infrastructure with service restrictions	You choose users, credentials, topics and access rules
Suitable for public community traffic and experiments	Better suited to a defined group or private integration
Traffic and metadata leave your control	More control, but not automatic security
Public LongFast traffic may overwhelm some nodes	You must prevent loops, excessive downlink and mesh flooding yourself

The official integration guide warns against using the default public channel key on a private broker. Private brokers do not automatically enforce the public service’s zero-hop policy, so careless downlink configuration can flood local radio meshes. Use private channels with custom keys and deliberately restricted topics. See Meshtastic’s private-broker warning.

MQTT and the off-grid philosophy

MQTT does not undermine Meshtastic merely by existing. It offers a different operating mode.

A pure LoRa mesh is locally independent. If mobile networks, power and internet services fail, battery-powered radios can continue communicating within the limits of their radio coverage. An MQTT-bridged network trades some of that independence for reach, remote access and integration.

The clearest way to describe the distinction is:

LoRa-only Meshtastic: off-grid radio communication with no internet requirement.
Meshtastic with MQTT: local LoRa meshes connected or observed through optional internet infrastructure.

Neither model is universally better. A hiking group may want no internet dependency at all. A worldwide community experiment may deliberately use MQTT. A resilient local network may use MQTT during normal operation but retain radio-only channels and procedures for outages. The important point is to configure and describe the network honestly.