Recommended Settings for a Public Meshtastic Network

A conservative baseline for interoperable public infrastructure, with reasons and exceptions.

A public network benefits from a published baseline because compatible radios can discover and relay one another without bilateral setup. The recommendations below are a starting profile for ordinary community Meshtastic networks. They are not a substitute for the correct national region, a measured network plan or local agreement.

Firmware evolves, and applications do not always expose every setting with identical labels. Record the firmware version and export or document configuration before changing remote infrastructure.

Baseline radio settings

Setting	Recommended start	Reason
Region	Legally correct local region	Frequency, power and duty-cycle compliance
Modem preset	LONG_FAST	Default public interoperability and balanced airtime
Frequency slot	Regional/default coordinated value	All participants must use the same physical slot
Maximum hops	3	Project default and recommendation for most uses
Transmit power	0 / legal automatic default	Avoid arbitrary maximums; include antenna gain in compliance
Duty-cycle override	Off	Preserve legal firmware protection

Do not copy a region from a neighboring country merely because the frequency looks similar. Verify the national rules and the Meshtastic country table.

Channels and security

Keep the default public primary channel if interoperability with ordinary users is the goal. Add private groups as secondary channels with strong random keys. If the primary name is customized, explicitly coordinate the frequency slot because its automatic selection can depend on the name.

Use separate administrative credentials with restricted distribution. Never put admin keys in a public QR code, website or node listing.

Roles and rebroadcasting

Use CLIENT for most handhelds, home nodes and fixed sites. Use CLIENT_MUTE for devices that should not relay. Assign ROUTER or REPEATER only to a small number of measured, strategic backbone sites. Default rebroadcast mode ALL supports the widest public mesh; select a restrictive mode only as an explicit policy decision.

A good antenna and site do not by themselves justify privileged behavior. Observe whether normal managed flooding already provides the needed path.

Automatic broadcasts

Leave NodeInfo at the documented three-hour default. For fixed position, use a conservative 15-to-60-minute interval and appropriate precision. If device or environmental telemetry is useful, begin at 30-to-60-minute intervals and enable only the categories someone will monitor.

Mobile position may use smart broadcast, but communities should discourage unnecessarily small time or distance thresholds on the public mesh.

MQTT and modules

Treat MQTT as optional backhaul. Disable downlink unless the community deliberately wants internet-originated packets on RF. Avoid uncontrolled bridging between distant regions. Leave Range Test, Neighbor Info, Store and Forward and specialized modules disabled unless they have a current purpose and traffic budget.

Enable a diagnostic module for a defined test, collect the result and turn it back off.

Change control and exceptions

Publish the baseline, keep a configuration record per infrastructure node and nominate maintainers. Test changes on one non-critical node first. Preserve local or independent recovery access to remote sites.

An exception should name the problem, evidence, expected benefit and review date. Examples include a fourth hop at a remote edge, LOCAL_ONLY for a private facility or a faster preset for a separate event network. Exceptions should not silently redefine the public standard.

Quick commissioning checklist

Confirm region and legal antenna system.
Set LONG_FAST and coordinated slot.
Keep hops at 3 and role CLIENT initially.
Configure public and private channels without exposing keys.
Set fixed or privacy-reduced position where appropriate.
Disable unused modules and MQTT downlink.
Record firmware and export configuration.
Test two-way delivery and observe utilization.
Publish the node’s maintainer and approximate service area.

What not to standardize blindly

Do not impose one exact position interval on hikers, fixed relays and rescue exercises. Do not require precise public coordinates for privately hosted sites. Do not make ROUTER the badge of an official installation. A standard should protect compatibility and capacity while leaving room for documented use cases.

Likewise, transmit power should follow the regional rules and complete antenna system. Maximum hardware output is not a community goal. Height, line of sight and receiver environment usually deliver more benefit than arbitrary power.

Publishing the profile

Present the baseline on one stable page and include a machine-readable or QR configuration only when it does not expose private keys. Date the page and retain a change log. Link the legal country guide and explain how operators can report a problem.

Review the profile after major firmware changes or when utilization and network size materially change. Stability matters: avoid forcing a region-wide reconfiguration for minor theoretical gains.

How these settings work together

No setting should be evaluated in isolation. A slower preset increases packet airtime; a larger hop limit multiplies that airtime across more relays; frequent position and telemetry packets create a permanent load; and privileged repeaters can produce additional copies. Conversely, a well-sited node using ordinary CLIENT behavior may extend the mesh effectively without special privileges.

For a public deployment, document the complete profile and the reason for every exception. Test delivery in both directions, during quiet and busy periods, and retain a way to reverse remote changes. Revisit the profile as the network grows.

Related configuration guides

Official sources

Meshtastic firmware and documentation change over time. Confirm setting names, defaults and regional requirements in the current official documentation before changing live infrastructure.