Planning a Public Meshtastic Network

A public Meshtastic network is community-owned radio infrastructure that people can join with compatible equipment. It may begin with a few enthusiasts, but it becomes genuinely useful only when its coverage, configuration and maintenance are coordinated. The goal is not to fill a map with node icons. The goal is to create dependable radio paths between the places where people live, travel and gather.

This page introduces the complete planning process and links to focused guides for each decision. It is intended for neighborhood groups, radio clubs, rural communities, volunteer organizations, landowners and businesses considering a public node.

Start with a service, not a shopping list

Define what the network should accomplish. A town-center messaging network, a rural valley link, hiking-route coverage and a regional backbone have different requirements. Write down the intended area, likely users, important locations, expected traffic and whether the network must work without internet access.

A useful first objective is specific and testable: “provide handheld coverage through the town center and connect it to the neighboring municipality” is better than “cover the region.” Mark homes, schools, community centers, road corridors, mountain huts and gathering places. Then note the ridges, hills and tall buildings that may provide infrastructure sites.

Understand what creates coverage

LoRa can decode weak signals, but it cannot pass efficiently through mountains, reinforced concrete or poor antenna installations. Height, clear line of sight, antenna quality and feed-line loss usually matter more than transmitter power. A well-sited modest node can connect areas that dozens of indoor nodes cannot.

Use terrain maps and line-of-sight tools to identify candidates, but treat predictions as hypotheses. Buildings, vegetation, local noise, antenna pattern and installation details affect real results. Confirm every important path with field tests in both directions.

Give nodes clear jobs

Most personal devices should use the normal CLIENT role. Infrastructure roles should be reserved for carefully selected sites because aggressive rebroadcasting consumes shared airtime. Meshtastic uses managed flooding: a newly received packet may be rebroadcast, its hop limit is reduced, and duplicate packets are suppressed. Adding unnecessary routers or increasing hop limits can therefore increase congestion rather than coverage.

A public plan should distinguish user nodes, neighborhood coverage nodes, elevated backbone sites, gateways and monitoring stations. Internet-connected MQTT gateways are optional and should not be mistaken for the radio network itself. The mesh must still have a coherent local configuration and useful RF paths.

Standardize the shared radio configuration

Nodes must use a legal regional setting and compatible LoRa parameters to communicate. A community should agree on the primary public channel, modem preset, frequency slot, hop policy, naming convention and reasonable broadcast intervals. Meshtastic recommends leaving the maximum hop count at three unless a tested edge case requires otherwise. Changes at the center of a busy mesh have wider effects than changes at its edge.

Do not enable every telemetry or topology feature simply because it exists. Position, device information, environment telemetry, Neighbor Info and range-test packets all use airtime. Choose intervals that suit the value of the information and the capacity of the local network.

Build in phases

Survey: map demand, terrain, existing nodes and possible hosts.
Pilot: deploy two or three controlled sites and test the intended links.
Coverage: add nodes that solve verified gaps rather than adding them uniformly.
Redundancy: create alternate paths around the most important sites.
Operations: assign owners, document configurations and establish maintenance routines.
Expansion: connect adjacent communities only after the local core is stable.

Plan for ownership and failure

Every infrastructure node needs an owner or steward. Record who may administer it, who can enter the site, how it is powered, what firmware and configuration it uses, and what spare parts are required. Back up settings before changes. For inaccessible locations, configure secure remote administration before installation and retain a safe physical recovery method.

Assume that batteries age, antennas loosen, water enters boxes, firmware changes and hosts move. A network dependent on one mountain node is a demonstration, not resilient infrastructure. Prioritize alternate paths around sites whose failure would divide the region.

Coordinate without exposing private sites

A public directory should identify the node’s purpose, approximate service area, status, frequency profile and responsible community. It need not publish exact coordinates for a private roof or restricted tower. Exact access details, administrator keys and host contact information belong in a controlled operations record.

Agree on how new sites are proposed, tested, accepted and marked inactive. A small coordination group can maintain the shared configuration and map without owning every node. Transparent technical rules matter more than formal hierarchy.

The planning series

Authoritative technical references

Before finalizing a local plan, read Meshtastic’s current mesh algorithm, configuration tips, device roles and radio settings. Firmware behavior evolves, and legal frequency and power rules must always be checked for the country where each transmitter operates.