Starting a Community Mesh How to bootstrap a new regional mesh network and grow your community. 📖 Start Here — Starting a Community Mesh Guide This book is for people who want to start or grow a LoRa mesh community - from bootstrapping the first nodes to governing a multi-network region. 🚀 Starting From Zero How do I start a mesh network where there are none? (FAQ) Starting from Zero: Your First Repeater Is There Already a Network in Your Area? Choosing Your Protocol and Channel 📚 What's In This Book Planning Your Network Setting Channel Keys and Network Identity Infrastructure Agreements and Permissions - Site host relationships, rooftop access Growing Your Community Finding Volunteers and Repeater Sites Recruiting Repeater Hosts Onboarding New Members Effectively Community Events and Meetups Running Mesh Events and Demonstrations Network Hygiene and Documentation Naming Conventions and Network Hygiene Network Documentation Standards Handling Network Growth and Congestion Community Operations Community Governance and Decision-Making Emergency Preparedness Integration Using RegionMesh Geographic Scoping ➡️ Related Books North American Networks - See what existing communities have done Network Planning - Technical planning tools Emergency Communications - EmComm integration with community networks Planning Your Network Is There Already a Network in Your Area? Is There Already a Network in Your Area? Before starting a new mesh network, check whether an existing network already covers your area. Joining an established network is almost always better than starting from scratch - you immediately have more repeaters, a larger community, and tested infrastructure. How to Check Live Node Maps map.meshcore.io - live worldwide MeshCore nodes meshmap.net - worldwide Meshtastic nodes that uplink to the public MQTT server (community map; nodes with MQTT uplink off do not appear) map.wcmesh.com - West Coast Mesh node map Community Search Search Discord for "[your city/state] mesh" or "[your city/state] meshtastic" Search Reddit for r/meshtastic or r/meshcore posts in your area The official MeshCore project Discord is at meshcore.gg - ask in a general channel if anyone covers your area. For RegionMesh-specific coverage questions, use RegionMesh's own community channels (regionmesh.com/community). Existing Networks by Region Region Network Website Nationwide US RegionMesh regionmesh.com North Dakota & surrounds NoDakMesh nodakmesh.org West Coast WCMesh wcmesh.com Pacific Northwest CascadiaMesh cascadiamesh.org If No Network Exists If you genuinely can't find an existing network in your area, you have the opportunity to start one. A few considerations: Start with RegionMesh: If in the US, consider deploying MeshCore repeaters that join RegionMesh rather than a proprietary local network. You get national infrastructure from day one. Two nodes minimum: A single repeater is not a "network." You need at least two nodes to demonstrate mesh functionality and attract more participants. Elevation first: Your first repeater should be your highest-elevation option. One hilltop repeater can enable dozens of low-elevation nodes to communicate. Document your settings: Publish your channel name, frequency, and preset on a simple webpage or in a Discord server so others can join. Choosing Your Protocol and Channel Choosing Your Protocol and Channel The two dominant LoRa mesh protocols for community networks are MeshCore and Meshtastic. They are not interoperable - nodes must use the same protocol to communicate. Protocol Comparison Feature MeshCore Meshtastic Infrastructure model Dedicated repeaters + companion nodes Peer-to-peer; any node can relay Room servers Yes - built-in store-and-forward No full equivalent (an optional Store & Forward module on a PSRAM node is a partial analog, not a room-server/bulletin board) MQTT gateway Community brokers (e.g. letsmesh.net, meshmapper.cc) Official public broker (mqtt.meshtastic.org) Regional scoping Yes - operator-defined region labels (lowercase alphanumeric + hyphen, max 29 bytes) hashed to 2-byte transport codes; no official registry or ISO standard No App MeshCore companion app Meshtastic app (iOS/Android) Hardware compatibility Commonly ESP32 and nRF52840 boards with SX1262 radio (e.g. Heltec V3, RAK4631, T114, T-Beam); some SX1276 boards are also supported. Verify the current board list at flasher.meshcore.io / docs.meshcore.io. ESP32 and nRF52 boards Large existing network RegionMesh (a growing national MeshCore network; see the live map at regionmesh.com for current coverage) Meshtastic worldwide (meshmap.net, a community map - the official map link is on meshtastic.org) General Guidance If your area has an existing RegionMesh presence or you want to contribute to a nationwide infrastructure, choose MeshCore. If your community already uses Meshtastic or you need nRF52 hardware compatibility, choose Meshtastic. Running both is possible but means operating two separate device fleets (the protocols cannot share a radio), which adds operational complexity. Channel Selection for MeshCore Most North American MeshCore networks use the USA/Canada preset: 910.525 MHz / 62.5 kHz BW / SF7 / CR5 (as of 2026-06). This is the default for RegionMesh and many other communities; confirm current settings with your local network before deploying, as presets are periodically revised. If your area has a pre-existing local MeshCore deployment on different settings, match those settings to join that network. Check locally first - then default to the USA/Canada preset. Channel Selection for Meshtastic LongFast preset is the documented Meshtastic default and the most widely used (as of 2026-06); some communities migrate to MediumFast/MediumSlow as they grow. Default channel key: AQ== (the publicly known default key, base64 for the single byte 0x01 - default-channel traffic is readable by any Meshtastic node) Hop limit: 3 (default; increase only if you have specific reason to) Do not use a custom channel key unless your community has a specific reason to create a private channel. Using the default key ensures maximum interoperability with travelers and other local nodes. Setting Channel Keys and Network Identity Your channel configuration defines who can communicate on your mesh. Getting it right from the start saves painful re-configuration later as your network grows. Understanding Channel Keys Both Meshtastic and MeshCore use a shared channel key (Pre-Shared Key or PSK) that all nodes on a given channel must share to communicate. The key serves two functions: Confidentiality - Nodes without the key cannot decode messages, preventing outsiders from reading your mesh traffic. Note this is confidentiality, not authentication: because every member shares the same key, any member can forge or impersonate messages on the channel. A shared PSK does not prove who sent a message. Network segmentation - Multiple community networks can coexist on the same frequency by using different keys Important: If you use the Meshtastic default key ("AQ==", which is base64 for the single byte 0x01 - the publicly known default key, not "all-zeros"), the firmware expands it into the well-known default PSK and your messages are readable by every Meshtastic node in range. For a community network, always set a custom channel key. Generating a Strong Channel Key Meshtastic channel encryption uses AES-256-CTR when a 32-byte (256-bit) key is used. Custom PSKs can be 0, 128-bit (16 bytes), or 256-bit (32 bytes). Generate a strong 256-bit key: # Generate a random 256-bit key (32 bytes, base64 encoded) python3 -c "import os, base64; print(base64.b64encode(os.urandom(32)).decode())" Distributing Channel Keys Methods for sharing your channel key with new members: QR code - Meshtastic generates a channel QR code that encodes the full channel configuration (name, key, modem preset). Share via your website or print at events. The most convenient method. Deep link URL - Meshtastic channel QR codes encode as an HTTPS web URL of the form https://meshtastic.org/e/#, with the channel settings carried in the URL fragment after the #. Can be posted as a clickable link in your community documentation. Manual entry - For MeshCore and technical users, document the key as a base64 string in your private community documentation. Key distribution security: Your channel key doesn't need to be secret from trusted community members, but don't publish it on your public website. Share it in your community Discord/Signal or at in-person events. Multi-Channel Strategy Consider running multiple channels for different purposes: Channel Name Key Purpose Community-Public Published freely General community chatter, newcomer welcome Community-Ops Members only Network operations, node status updates EmComm Emergency teams only Your group's own coordination and drills (see caveat below) EmComm channel caveat: A private "EmComm" channel is fine for your own group's coordination and drills under unlicensed Part 15 (915 MHz ISM) operation, but it is not a substitute for authorized public-safety or amateur-radio emergency channels. Two limits apply: an encrypted channel cannot be used by stations operating under amateur radio (Part 97), which prohibits messages encoded to obscure their meaning; and formal ARES/RACES/served-agency traffic must stay on authorized, often monitorable channels. During a real activation, follow your served agency's and ARES/RACES communication plan rather than relying on a private encrypted hobby-mesh channel. Network Name and Node Naming Conventions Establish naming standards early. Consistent naming makes the node list immediately informative: Meshtastic long name format: [City/Area]-[Location]-[Type] - e.g., "PDX-WestHills-Repeater" or "SEA-Capitol-Hill-Node" Short name (4 bytes): Use initials + number - "WH01", "CH02" Repeater nodes: Include "Rpt" or "Rep" in the name to distinguish from client nodes Room servers: Include "RS" - "PDX-RS01" Infrastructure Agreements and Permissions Getting your repeater or backbone node onto high-elevation infrastructure dramatically improves coverage - but it requires agreements with property owners. (High-elevation, line-of-sight siting is core Meshtastic guidance; see the Meshtastic siting tips.) Types of Infrastructure Sites The best sites for backbone nodes (roughly in order of typical access difficulty): Your own property - On property you own you generally need no third-party agreement, but it is not automatically unrestricted: check HOA covenants, local zoning/permit rules for antenna masts, and (if you rent, or for a friend's house) the applicable lease. Start here: your house, or a friend's house with a tall tree or roof peak. Amateur radio repeater sites - Existing ham radio clubs often have hilltop sites with tower space, power, and sometimes internet. Approach club leadership to discuss hosting. Note: default Meshtastic runs in the license-free 902-928 MHz ISM band (Part 15), where there is no ham frequency coordination and encryption is allowed. Formal ham-frequency coordination only applies if you operate in HAM mode under Part 97 (licensed, and encryption is not permitted) - clarify which regime applies before discussing "frequency coordination." Commercial buildings - Restaurants, shops with flat roofs. Pitch: "We're a community communications nonprofit. We'd like to install a small weatherproof box the size of a paperback book on your rooftop. No wiring to your building, runs on its own battery/solar." Expect the owner to ask for proof of commercial liability insurance naming them as additional insured (see Insurance Considerations below). Municipal property - Parks department, public works, and fire departments sometimes allow installations for emergency-preparedness benefit, but expect a formal license/use agreement requiring proof of commercial liability insurance (municipality named as additional insured), an indemnification clause, and sometimes risk-management or council approval - not just an informal MOU. Highly jurisdiction-dependent. Water towers - Managed by municipal water utilities, and among the highest-liability, hardest-to-permit sites. Utilities universally require commercial general liability insurance naming the utility as additional insured, a formal site/license agreement, and often background checks and trained climbers, because access involves fall hazards and potable-water security. Do not treat a water tower as an informal site. Cell towers - Carrier-grade macro tower and managed-rooftop colocation typically runs $1,000-$3,000+/month (urban higher); small-cell sites run roughly $100-$250/month. More importantly, many tower operators will not lease space for a device this small at any price - treat commercial tower colocation as a last resort. Amateur-radio repeater sites and municipal buildings are far more accessible. What to Include in a Site Agreement Even for informal arrangements, a simple one-page written agreement protects both parties: Description of the hardware (size, weight, power source) Exact mounting location Duration (1 year renewable, or at-will with 30-day notice) Your responsibility for maintenance and removal Liability and insurance - the operator/nonprofit carries Commercial General Liability insurance and will name the property owner as additional insured on request (specify coverage limits). Note: a written agreement does not by itself transfer liability for structural/roof damage or injury during access; adequate insurance does. Contact information for both parties Insurance Considerations Most institutional partners will ask whether you carry liability insurance. Coverage scope varies - confirm specifics with a licensed agent before relying on any policy. Options: ARRL Affiliated-Club Liability Insurance - ARRL does not provide individual members with liability insurance. ARRL administers a separately-purchased Club Liability Insurance Program (up to ~$2,000,000/year aggregate) for ARRL-Affiliated amateur radio clubs - the club buys and pays for the policy (roughly $200/year). It is not an automatic individual-membership benefit and does not cover a personal repeater site. An individual host or operator needs their own Commercial General Liability coverage; confirm scope at arrlinsurance.com. Nonprofit general liability (CGL) policy - The primary coverage most hosts will ask for. If you've formed a 501(c)(3), small-org premiums vary, commonly a few hundred to low thousands of dollars per year (industry average ~$500/year per Insureon, 2026), depending on limits, activity, and whether additional-insured endorsements are needed. Get a quote rather than budgeting from a rule of thumb. (An "umbrella" policy is separate excess coverage layered on top of CGL, not the primary policy itself.) Personal homeowner/renter's policy - Generally does not cover a transmitter you install and operate on a third party's commercial, municipal, or utility property, and cannot add the owner as an additional insured (which water towers and municipalities require). Such policies cover your own residence and personal liability and routinely exclude business pursuits and hosted third-party equipment. For installations on someone else's property you need a Commercial General Liability (CGL) policy - typically held by the nonprofit - that can name the site owner as additional insured. Maintaining Relationships with Site Hosts Annual "thank you" message or card Invite them to community events Update them when you add features or upgrade hardware Be responsive if they ever have concerns - a 24-hour response time builds trust Proactively reach out before any work at the site; never surprise a host Growing Your Community Finding Volunteers and Repeater Sites Finding Volunteers and Repeater Sites The practical limit on any mesh network's coverage is the number and location of repeaters. Growing a community mesh means finding both people willing to host hardware and locations with good RF exposure. Identifying Good Repeater Sites The best repeater sites share these characteristics: Elevation: Hilltops, building rooftops, water towers - any location that has line-of-sight to a wide area Permanent power: AC power or solar with battery backup means no maintenance visits for power Internet connectivity: Enables MQTT gateway functionality and remote management Willing host: Someone at the location who can assist with initial install and occasional physical access Where to Find Volunteers Amateur radio clubs: Many hams are already interested in digital modes and emergency communications; LoRa mesh is a natural extension Community preparedness groups: CERT, neighborhood emergency response teams, and ARES/RACES members often see immediate value in mesh Tech and maker communities: Hackerspaces, makerspaces, and local tech meetups Community maps: Public maps such as meshmap.net (Meshtastic, opt-in MQTT-reporting nodes only) and map.meshcore.io (MeshCore) can help you spot existing operators nearby — though they show only nodes that uplink, so they undercount private networks Existing mesh Discord servers: The official MeshCore Discord at meshcore.gg, RegionMesh's community channels, and other communities often have "looking for volunteers in [state]" discussions The Repeater Volunteer Pitch The cost and effort for a volunteer are minimal. Emphasize: Hardware cost: ~$32 for a single Heltec V3 (less in multipacks); a basic repeater build with antenna and enclosure runs somewhat more (as of June 2026) Power draw: under 1 watt continuous (negligible electricity cost) Maintenance: essentially zero once installed and configured Contribution: one well-placed rooftop repeater can meaningfully extend neighborhood coverage, depending on terrain, antenna height, and line of sight Coordinating Through the Community If you are deploying as part of a regional MeshCore network like RegionMesh, coordinate through the official MeshCore Discord at meshcore.gg and the regionmesh.com community resources. There is no single official "5-step RegionMesh process"; practices vary by community and are set by local consensus. Sharing your repeater's location and settings with nearby operators helps the broader community find and route through it. Tracking Your Network As you grow, keep a simple inventory of deployed nodes: location, hardware, firmware version, radio settings, and host contact. This becomes critical for maintenance, upgrades, and troubleshooting. Using RegionMesh Geographic Scoping Using RegionMesh Geographic Scoping RegionMesh is a third-party community naming convention for MeshCore (not Meshtastic), built around MeshCore's region/scope feature. It is documented at the community site regionmesh.com and is not an official MeshCore registry or a single operated national mesh. As participating communities grow, using a shared region name helps you manage channel capacity and create region-specific communications without flooding every reachable repeater. A MeshCore "region" is simply an arbitrary, operator-chosen plain-text name (lowercase alphanumeric plus hyphens, maximum ~29 bytes UTF-8) that the firmware SHA-256-hashes into a 2-byte transport code. There is no ISO 3166-2 system, no built-in country/state code table, and no central firmware registry. A name like us or nd works only because it is a valid arbitrary string the firmware hashes — the firmware never interprets it as a standardized region code. RegionMesh is a convention for getting nearby operators to agree on the same names, adopted by local consensus rather than registered with any authority. The Problem Scoping Solves Within a connected MeshCore mesh, every message without a scope floods all repeaters it can reach. That flood is bounded by RF range and hop limit (and by MQTT bridging where enabled) — it does not literally travel coast-to-coast over the air, because LoRa nodes only relay within radio range. But on a dense local network, or across MQTT-bridged segments, unscoped traffic consumes channel capacity that nearby communities do not need to carry. A neighborhood alert in Fargo, ND does not need to be relayed by repeaters that only serve other metros. How to Enable Regional Scoping On each repeater, configure the relevant regions using the MeshCore CLI (these are MeshCore commands, not Meshtastic). A child region requires its parent as an argument, and you allow flood forwarding for each name before saving. Verify exact syntax against docs.meshcore.io and regionmesh.com, as the CLI evolves: region put us region put nd us region allowf us region allowf nd region save This example configures a North Dakota repeater to carry both national us traffic and a North Dakota-scoped nd region. The region put nd us form establishes nd as a child of us; the parent argument is required for the hierarchy to take effect. There is no advert step in this flow. Creating a Regional Channel When messages are scoped to your region (e.g., nd), they are only forwarded by repeaters that have that region configured. This creates an effective regional "channel" over shared infrastructure without requiring separate hardware or frequencies. Choosing a Metro Code If your community covers a metro area not well served by a state name alone (e.g., Dallas/Fort Worth), you can propose a community metro name. There is no central registry — codes are adopted by local consensus. A typical approach: Join the official MeshCore Discord at meshcore.gg (where much RegionMesh coordination happens), or check regionmesh.com Propose the name in the appropriate channel (format: lowercase alphanumeric and hyphens only, max 29 bytes UTF-8, e.g., dfw) Achieve consensus among local mesh operators The name is then documented and shared so nearby operators adopt the same one — there is no formal registration step Existing Metro Codes RegionMesh's documented metro names are bare strings with no us- prefix. Examples (confirm the current list at regionmesh.com rather than assuming): dfw - Dallas/Fort Worth bay-area - San Francisco Bay Area greater-atlanta - Greater Atlanta See regionmesh.com or the official MeshCore Discord for the current complete list. Onboarding New Members Effectively Your onboarding process determines whether new members stay active or quietly disappear after their first week. A smooth, welcoming, and technically successful first experience converts curious newcomers into committed network participants. The Onboarding Journey Discovery - They learn the network exists Acquisition - They obtain hardware Configuration - They get the node on the network First contact - They exchange messages with another member Deeper engagement - They explore features, attend events, consider contributing infrastructure Hardware Recommendations Standardize on 1-2 recommended hardware options. Prices below are approximate single-unit retail as of mid-2026 and vary by retailer and region. Current recommended starter kit: Budget option: Heltec WiFi LoRa 32 V3 (~$32 single-unit; sub-$20 only in bulk/multipacks) - USB-C, built-in OLED, no GPS. Good for indoor/desktop use. All-in-one option: LILYGO T-Beam (roughly $30-45 depending on retailer/region) - GPS built in, battery connector, excellent for portable use Premium: RAK WisBlock Starter Kit (~$60-80, depending on bundled modules) - Modular, excellent build quality, best for fixed outdoor installations Pre-Configured Firmware Distribution Create a saved configuration file with your community channel key, frequency preset, and node naming convention pre-filled Host it on your community wiki or website Flash firmware at flasher.meshtastic.org, then share your channel settings separately via a Meshtastic channel QR code or URL (meshtastic.org/e/#...). The web flasher loads firmware onto the device; it does not bake your channel config into the firmware link - that is a separate step. Document: "Flash this firmware, scan this channel QR code, done." - Two steps maximum. First-Week Checklist for New Members Node powered on and flashed with community firmware Channel key loaded (via QR code scan or manual entry) Node name set to community naming convention Sent a test message received by at least one other member Joined community Discord/Signal channel Node visible on your community map (note: a node only appears on meshmap.net if MQTT uplink is enabled, which private community channels usually keep off - so absence from meshmap.net is not a failure) Assign a "buddy" - an experienced member who agrees to be on-call for a new member's first week. A quick DM check-in on day 3 dramatically improves retention. Managing Stale and Orphaned Nodes Every network accumulates abandoned nodes - nodes still visible on the map but owned by someone who has moved on. Management strategies: Annual "node census" - Message all known node operators, ask for a check-in. Non-responders after 30 days are marked as inactive. Last-heard tracking - Meshtastic shows a "last heard" timestamp per node in the app. Some community map tools then style nodes not heard in 30+ days differently; that styling is a property of the map software, not the Meshtastic firmware itself. Node decommission policy - Backbone/shared infrastructure nodes require formal handoff if an operator leaves. Document the process. Community Events and Meetups Regular events keep the community engaged and accelerate network growth. Events serve three purposes: recruitment of new members, skill-sharing among existing members, and public demonstration of the network's value. Build Nights Monthly hands-on sessions where newcomers build their first node with help from experienced members. Format that works: Venue: Makerspace, library meeting room, or restaurant private room. 2-3 hours. Format: 15 min intro presentation → 90 min guided build → 15 min test on the live mesh Materials: Pre-order 4-6 extra kits to sell at cost to walk-ins. Keep spare USB cables, soldering irons, and spare antennas on hand. Cost to participants: Hardware cost only - roughly $30-50 for a single-unit entry node depending on the board (see the Onboarding page for current single-unit hardware pricing). Experienced helpers volunteer their time. Document and promote the event on social media. "Before and after" photos of someone building their first node and seeing it appear on the map are highly shareable. Annual Range Test A fun event where participants drive, hike, or bike to test the limits of the network. Structure: Designate a base station at a high-elevation location Participants spread out across the coverage area with mobile nodes Track who can communicate from the farthest point Record SNR/RSSI at each test location Share results in a coverage report - excellent content for your community map The range test also generates real coverage data that helps you identify gaps for future backbone expansion. Tabletop Exercises Simulate a disaster scenario where the mesh is used as a coordination tool. Good exercise scenarios: Extended power outage - Cell networks are down, no internet. How does the community coordinate? Objective: verify which of your own repeaters actually stay up during the outage (battery/solar reserve) - a mesh is only available in a grid-down event if its infrastructure nodes have independent power. Evacuation coordination - Simulated wildfire. Use the mesh to coordinate shelter-in-place vs. evacuation by zone. Search and rescue - Member is "lost" in a park. Use the mesh to coordinate the search team. Tabletop exercises reveal gaps - in coverage, in procedure, and in member skills - before they matter. Document findings and publish improvements. Meetup Frequency Guidelines Event Type Frequency Time Investment Build night / intro session Monthly 3-4 hrs to organize, 2-3 hrs to run Infrastructure work party Quarterly Full day Annual range test Annually Weekend event Tabletop exercise Annually (before storm season) Half day Virtual sync call Monthly 1 hr Bootstrapping a New Network Starting from Zero: Your First Repeater Every community mesh started with one person who put up the first node. This page is for that person. The core insight A community mesh doesn't need to be large to be useful. A single well-placed repeater can cover a neighborhood, a rural township, or a county road corridor - and become the seed that grows a larger network. Start small, start working, and others will join. The minimum viable network You can have a functional, useful mesh with just: 1 fixed repeater in a good location 2 - 3 participants with portable nodes A well-placed repeater can cover a surprisingly large area. A rooftop-mounted repeater on the highest building in a small town can, under good line-of-sight conditions, reach much of the town and several miles of surrounding open farmland. Actual coverage varies widely with terrain, obstructions, antenna height, and the receiving nodes — hills, trees, and buildings can shrink it substantially, so treat "covers the whole municipality" as a best case to verify by testing, not a guarantee. Step 1: Pick your protocol Before deploying anything, decide which protocol your community will run: MeshCore Meshtastic Best if Joining an existing regional MeshCore network (CascadiaMesh, WCMesh, RegionMesh, NoDakMesh) or planning a larger community infrastructure Starting fresh with no nearby infrastructure; large global community; simpler initial setup Check first Is there existing MeshCore infrastructure in your area? (regionmesh.com — a third-party community site — and cascadiamesh.org; or map.meshcore.io) Are there existing Meshtastic nodes in your area? (meshmap.net — community map, opt-in MQTT nodes only) Key rule: Join the existing protocol in your area rather than fragmenting the community. Two separate protocols cannot interoperate. Step 2: Get your first repeater up The single highest-impact thing you can do is install one good, well-located, permanently-powered repeater. See the Hardware section for build guides. The minimum for a good first repeater: A device that can run 24/7 without attention (solar, mains, or long-life battery) Located at the highest accessible point in your area A quality external antenna (5 - 6 dBi vertical) mounted above obstructions. In the US 902-928 MHz ISM band the conducted power limit is 1 W (30 dBm); a 5-6 dBi gain antenna raises EIRP above the transmitter output, so be aware of the antenna-gain-to-EIRP relationship when choosing higher-gain antennas Flood advertisements enabled (so it announces itself across the network) A name that indicates location (e.g., MILL-HILL-SOUTH, TOWNNAME-WATER-TWR) Step 3: Tell people it exists A mesh nobody knows about has no community. Before anything else: tell people the repeater exists and how to connect. Post in local Facebook groups, Nextdoor, amateur radio clubs Add your repeater to the regional network map (contact your regional network admin) Put up a simple info page or join the regional Discord Reach out directly to local emergency management - they're often interested in off-grid communication options What to expect in year one Growth is rarely explosive. A realistic year-one trajectory for a rural or small-town mesh: Months 1 - 2: You + 1 - 3 curious early adopters, mostly testing Months 3 - 6: 5 - 15 active participants; a few more repeaters added by enthusiasts Month 6+: Real use cases emerge (emergency preparedness groups, ARES coordination, outdoor enthusiasts) The community builds around real use, not around technology. When people find a genuine reason to use it, they stick with it. Recruiting Repeater Hosts The fastest way to grow coverage is to recruit hosts for additional repeaters - people who will let you mount a node on their property. A good host needs to provide: height, power, and patience. The ideal host profile Owns or has access to a high point (tower, tall building, hilltop property, water tower access) Has mains power available at or near the mount point (or accepts solar) Is comfortable with a small device mounted on their property for years Lives in an area that extends your coverage map Where to find hosts Amateur radio operators Ham operators already have antenna infrastructure, understand RF concepts, and are culturally aligned with community communication projects. Local radio clubs are the first call for any mesh network builder. Many hams already have hilltop or tower access and are open to co-locating additional equipment. Farmers and rural landowners Rural property owners often want better communication options themselves. A repeater on a grain elevator, water tank, or farm outbuilding benefits the farmer (they get a node) while extending your coverage into underserved rural areas. Frame it as mutual benefit. Local businesses on tall buildings Rooftop access to commercial buildings dramatically improves urban coverage. Property managers are more receptive if the installation is visually minimal (a small white antenna on an existing mast) and the equipment is professionally installed. Before any commercial-rooftop install, confirm who actually controls the roof (owner vs. property manager vs. tenant) - a property manager rarely owns the building and is bound by the owner's lease and insurance requirements. Expect to provide a certificate of commercial liability insurance naming the owner as additional insured, sign a roof-access/structural-penetration waiver, and obtain landlord and any HOA/condo-board approval. Antenna or structural changes may also require a local permit. Fire stations and public works facilities Many local government facilities are interested in off-grid communication resilience. Fire stations in particular often have tall buildings, 24/7 power, and emergency-preparedness motivation. Making the ask The pitch that works best: Explain what mesh radio is in one sentence: "It's like a community text messaging network that works without cell towers or internet." Show them the current coverage map and where their location fits in Offer to handle the installation completely - they don't have to do anything Describe the equipment: a small weatherproof box, one antenna, and very low power draw (a typical node averages well under 5 watts; continuous transmit is higher but the low duty cycle keeps the average small) Where budget allows, offering the host their own device can sweeten the ask so they can actually use the network - treat this as a planned, recurring cost (roughly $30+ per device), not a default promise you make to every host Host agreement basics Keep it simple but clear. A simple one-page document covering: What equipment is being installed and who owns it Who is responsible for maintenance and removal Power consumption (a solar node draws no grid power at all; a mains-powered node at roughly 1-5 W continuous costs on the order of a few dollars per year in electricity) How to contact you if there's a problem That you'll remove it on reasonable notice if they ask Don't over-engineer this for private or residential hosts - most will never look at the agreement again, but having it shows professionalism and prevents misunderstandings years later when personnel change. However, commercial, government, and utility hosts (fire stations, public works, businesses) typically require a formal license or lease plus proof of commercial general liability insurance naming them as additional insured - an informal one-pager will not be enough for those sites. Naming Conventions and Network Hygiene Good naming conventions make the network easier to use, debug, and grow. Establish them early - renaming nodes later requires coordinating with the host. Node naming conventions Community networks that work well use consistent, descriptive names. The goal: someone who has never seen the network should be able to understand what each node is and roughly where it is, just from the name. Recommended format LOCATION-TYPE or LOCATION-DESCRIPTOR Examples: OAKHILL-RPTR (Oak Hill, repeater) DOWNTOWN-RTR (downtown area, router) SMITH-FARM (Smith Farm, named location) I90-MP45 (Interstate 90, mile post 45) N-COUNTY-TOWER (North County tower site) What to avoid Personal names ("Bob's Node") - doesn't convey location information Generic names ("Repeater 1", "Node A") - ambiguous when you have many nodes Emoji or special characters - may not display on all devices All lowercase or all uppercase inconsistently - pick a convention and stick to it Overly long names - Meshtastic nodes have a Long Name (up to ~37 bytes) and a Short Name (4 bytes, used on space-constrained displays). There is no "20-character" limit, but keep the long name concise and make the 4-byte short name meaningful, since the short name is what shows where display space is tight. Network hygiene practices Document every node Maintain a simple spreadsheet or wiki page tracking each node: Node name and ID Physical location (general description, not exact address if security is a concern) GPS coordinates (for the network map) Hardware: board type, firmware version, antenna, power system Host name and contact Installation date and last maintenance Known issues Monitor for dead nodes Nodes that go offline and stay offline silently degrade coverage. Set up a monitoring system: Use a room server with MQTT output + a monitoring script to alert when a node stops advertising Or simply check the network map weekly and follow up on nodes whose "last heard" time shows they haven't been seen recently (the "last heard" value reflects when a node was last directly received, i.e. its presence, not a usage count) Keep firmware updated Firmware updates fix bugs and improve performance. For each significant release, update your permanent infrastructure nodes. This requires either physical access (USB) or an OTA update mechanism if your firmware supports it. Channel and frequency discipline Every node on your community network must use the same channel and preset. A mismatched modem preset (or region/frequency slot) is a symmetric failure: neither node can decode the other, so a misconfigured node can neither hear nor be heard by the rest of the network - it is not a one-way "can hear but not be heard" situation. Provide new participants with: Exact preset name or frequency settings Channel name and PSK (if using a private channel) Recommended role settings (Client for personal devices, Router/Repeater for infrastructure) Community Operations Community Governance and Decision-Making Most successful community mesh networks are lightly governed but clearly structured. Too little structure leads to chaos; too much bureaucracy kills volunteer participation. Here's what works. Minimal viable governance Network coordinator(s): 3 - 5 people who make final decisions on network settings, new repeater standards, and community direction. Usually the founders or most active contributors. These informal "coordinator" roles describe operational decision-making; if the mesh is run by a 501(c)(3) nonprofit, the board of directors still retains the formal legal and fiduciary responsibility regardless of the coordinator structure. Discord or forum: Primary community space for announcements, help, and coordination. Wiki or docs: Written reference for setup guides, network standards, and node documentation. Network map: Visual representation of active nodes. Decisions that need explicit consensus Some decisions affect everyone and need community buy-in, not just coordinator fiat: Changing the default preset or frequency: Migrating an existing network to a new preset requires coordinating every node simultaneously - a major disruptive event. Don't do this casually. Adding a private or encrypted channel: If community nodes are being used to bridge a private channel, other participants should know. This is not only a courtesy issue - confirm your regulatory basis first. Encrypted channels are permitted under Part 15 (ISM, 915 MHz), but are prohibited for stations operating under amateur radio (Part 97), so an encrypted channel is incompatible with callsign-identified ham operation. Hosting policies: What standards do infrastructure nodes need to meet? Who can call themselves part of the network? Managing contributions from outsiders As the network grows, people will want to add nodes. This is good - but uncoordinated growth causes problems: Wrong settings: New operators who configure incorrectly fragment the network - nodes must share matching settings (region, modem preset, channel) to communicate at all Poorly placed nodes: A ground-level node in a bad location can add airtime congestion without contributing coverage. This applies to relaying nodes (any Meshtastic node) and badly-placed repeaters, not to non-relaying MeshCore companion nodes. Abandoned nodes: Nodes that go offline and are never maintained degrade the perceived reliability Solution: Create a brief onboarding checklist for new node operators. It doesn't need to be formal - a Discord message template works. Cover: preset/channel settings, naming convention, role configuration, how to get on the network map, and who to ask for help. Handling network conflicts Occasional conflicts arise: two operators disagree on the right preset, a node is causing interference, someone deploys with wrong settings. Keep these principles in mind: The coordinator's job is to be a technical arbiter, not a bureaucrat. Make technically correct decisions and explain the reasoning. Document the standards. "The network uses X because Y" is much easier to enforce than "the coordinator said so." Be welcoming to newcomers who made honest mistakes. Getting the settings wrong is easy. Help them fix it rather than shaming them. Emergency Preparedness Integration A well-established community mesh is a natural complement to emergency preparedness programs. Many mesh networks find their most compelling use case in disaster response and preparedness exercises. Important: A community LoRa mesh is a best-effort, low-bandwidth, supplemental tool. It is NOT a replacement for established emergency communications (public-safety radio, amateur radio nets, 911). Delivery is not guaranteed, and the mesh works only where its own powered nodes remain within RF range. Do not build life-safety plans that depend on it as the primary or sole channel. Why mesh is valuable for emergency preparedness Independent of cellular/internet infrastructure: A mesh does not rely on cell towers or the internet, so it can keep working when those are down - but only for nodes that still have power and remain within RF range of a working repeater. It depends entirely on its own infrastructure (repeater siting, battery/solar reserves, RF propagation) and is best-effort and low-bandwidth, not guaranteed delivery. Treat it as a supplement to, not a replacement for, established emergency communications. No subscription: Critical communications infrastructure shouldn't depend on a vendor's servers being up Group awareness: Position sharing can give a rough shared picture of team locations, but updates are best-effort and may be delayed, stale, or dropped under congestion or marginal RF. On a public channel, positions are visible to anyone in range. Use it as supplemental awareness, not authoritative tracking; consider a private channel for team operations. Optional store-and-forward: By default, mesh messages are not stored - a recipient who is offline when a message is sent generally does not receive it later. Store-and-forward re-delivery is optional: Meshtastic requires a dedicated PSRAM-equipped Store & Forward server node (usually on a private channel), and MeshCore provides it via Room Servers. Plan for missed messages and scheduled re-check-ins, not automatic re-delivery. Low training burden: Text messaging is a skill everyone has Building relationships with ARES/RACES and CERT Amateur Radio Emergency Service (ARES) and Community Emergency Response Teams (CERT) are already organized around exactly the use case mesh networks address. Approaching these groups early builds the human infrastructure alongside the technical infrastructure. Practical steps: Attend a local ARES or CERT meeting and introduce the mesh network Offer to demo the network at a training exercise Provide devices to ARES section and club leadership at no cost (community investment) Run a mesh-integrated tabletop exercise with emergency management Emergency preparedness network design A preparedness-focused mesh should prioritize: Resilient power Aim for infrastructure nodes that can ride through a multi-day outage - a common target is 72+ hours of reserve - but treat this as a sizing goal, not an automatic property of any solar node. Size the battery for worst-case (winter/overcast) solar yield, account for cold-weather battery cutoffs, and verify real runtime by test. A repeater that fails when the grid goes down is worthless for disaster response. Review your power systems annually before storm season. Known coverage gaps Document where coverage fails. Know which valleys, neighborhoods, or facilities are in shadow from your current repeater network. Plan secondary coverage nodes for those areas before a disaster, not during one. Designated net control Identify which node serves as net control during an emergency (typically the best-connected infrastructure node or a dedicated gateway with internet uplink). Pre-establish procedures: how will net check-ins work? What's the reporting format? Paper backup procedures Mesh configuration should be documented on paper and stored physically at net control locations. If the operators who know the settings are unavailable, someone else must be able to deploy a node correctly. Include the actual reproducible fields: Region, Modem Preset, LoRa frequency slot, channel name, PSK/key, role settings, and the network map. Region and Modem Preset must match across all nodes for them to communicate. Running a mesh-integrated exercise A simple first exercise to demonstrate value: Scenario: Simulated grid-down event; cell towers overloaded or offline Participants: 5 - 10 people, each at a different location across the coverage area Exercise: Each participant checks in with their GPS position and a status report; net control acknowledges and tracks all positions Evaluation: Which nodes didn't check in? What coverage gaps were revealed? What configuration issues appeared? After the exercise, write up the after-action report and share it with emergency management. This demonstrates real operational value and opens doors for formal integration. Connecting to existing emergency communication systems As noted at the top of this page, mesh radio is not a replacement for existing emergency communication infrastructure - it's a supplemental addition. Key integration points (note the amateur-radio licensing requirements below): APRS: A gateway node running APRS bridge software (e.g. aprstastic) can relay position data to the APRS network, making mesh positions visible on aprs.fi to operators with no mesh hardware. Transmitting onto the APRS RF network (e.g. 144.390 MHz) requires a licensed amateur operator and proper station identification (a valid callsign); only a licensed ham may operate an RF APRS gateway. Unlicensed APRS RF gating is not permitted. WINLINK: Winlink is an amateur-radio email system; sending or receiving over RF requires a licensed amateur operator, and there is no standard supported mesh-to-Winlink bridge - any link is a custom, manually operated arrangement. Consult your regional ARES coordinator and a licensed Winlink operator before attempting this. ICS-213 forms: Many emergency management teams use ICS forms for structured reporting; a simple template-based approach for mesh messages can align with this Growing Your Network How to recruit hosts, run community events, document your network, and manage growth at scale. Running Mesh Events and Demonstrations The fastest way to grow a mesh community is to let people experience the network firsthand. Events and demonstrations convert curious bystanders into active participants in a way that no amount of documentation can match. The Mesh Meetup Format A mesh meetup requires no special venue and minimal equipment. The basic format: Gather 5 - 10 people at a park or open community space. Each participant brings or borrows a Meshtastic node. Power them on, watch the mesh form in real time. Run through the basics: send a message, observe who receives it, check the map to see each other's positions, walk to the edge of the park to test range. The goal is not to teach technical details - it's to create a "this actually works" moment that participants will describe to others. Keep it relaxed. Keep it short. Follow up with a Discord or group message so attendees can stay connected. Integration with Existing Events You do not need to organize a standalone event to demonstrate the mesh. Bring it to events that already draw the right audience: Ham radio field days - A natural fit. Many operators have never seen Meshtastic; a working demonstration at a field day generates more interest per hour than almost any other venue. CERT and ARES exercises - Emergency preparedness audiences respond strongly to a practical off-grid messaging tool. You do not need a full exercise; a side-table demo during setup or break time is enough. Maker faires - Technically curious attendees who enjoy seeing novel hardware in action. Outdoor clubs (hiking, camping) - Groups that go into areas with no cell coverage are interested in off-grid messaging. Be clear in demos that mesh is best-effort and, without nearby repeaters, only short-range between handheld nodes (often well under a few miles in terrain) with no guaranteed delivery and no connection to emergency services. It is not a substitute for a satellite messenger or personal locator beacon (PLB) in a life-safety situation. Bring 3 - 5 pre-configured nodes. Let people pick them up and try them. The hands-on experience is the entire pitch. EmComm Exercise Integration One of the highest-value moves for community credibility is proposing a mesh communications component to your county's next emergency management tabletop exercise or ARES drill. Contact your county emergency manager or ARES/RACES leadership and offer to run a Meshtastic messaging segment. Demonstrating value in a formal exercise context creates buy-in from officials who influence future infrastructure decisions. An emergency manager who has seen the mesh work in a controlled setting is far more likely to support permanent installations on municipal buildings. Demo Kit Maintain a dedicated loaner kit for events: 3 - 5 nodes, all pre-configured with your local channel settings Charged batteries or power banks for each node A one-page quick-start card: how to turn it on, how to send a message, what the map view shows A way to track who has each device (a simple sign-out sheet is enough) Get the kit back at the end of every event. Pre-configured nodes that leave your possession and are never returned are nodes that may end up causing interference or confusion on the network later. Online Presence A simple online presence makes it dramatically easier for newcomers to find your local mesh community, learn the channel settings, and get involved: Discord server - Many cities have active Meshtastic Discord channels. Search before creating a new one. If one exists, become active there; if not, a new server is easy to set up. Simple website - Even a single static page with your channel name, modem preset, and a contact link is sufficient. New participants should be able to find this without joining a private group first. Don't publish the channel PSK publicly; share it via QR code to participants you trust. But understand what the PSK does and does not do: it provides message confidentiality (outsiders without the key can't decode traffic), not access control or sender authentication. Because every participant holds the same shared key, anyone who has it can read and even forge messages on the channel, so distributing it to many "verified" participants offers only limited security. Don't treat a shared PSK as making the channel truly secure. Measuring Success Track concrete, observable metrics rather than relying on impressions: Node count on meshmap.net - Check month over month. A growing trend is the clearest indicator that the community is healthy. (Note: meshmap.net only shows nodes that report to the public Meshtastic MQTT server, so it undercounts a private community network - use your own node database or app for an accurate count.) Active repeater count - Nodes that are consistently online over multiple weeks, not just at events. Set written goals - "10 active nodes in the metro area by year end, 3 hilltop repeaters." Goals create shared direction and make progress visible. Celebrate milestones publicly in your Discord or website. Recognition keeps volunteers engaged. Network Documentation Standards A community mesh network that isn't documented is one resignation or one hardware failure away from being unrecoverable. Documentation is not overhead - it's the infrastructure that makes the physical infrastructure maintainable. What to Document For every permanent repeater, record: Location - Address or GPS coordinates, plus a plain-language description (e.g., "roof of First Baptist Church, southwest corner") Hardware - Device model, enclosure type, antenna type and gain Firmware version - Current version and date of last update Channel configuration - Channel name, modem preset, and whether a custom PSK is in use (do not record the PSK in shared documentation) Power system - Solar + battery, wall power, PoE. Battery capacity if applicable. Maintainer contact - Name and contact method for the person responsible for this node Beyond individual nodes, document: Network topology - Which repeaters link to which under typical conditions. A simple diagram is worth pages of prose. Channel settings - The canonical record of your community's channel name and modem preset. This is what you share with newcomers. Coverage map - Based on tested range, not theoretical propagation. Mark areas where coverage has been verified by walking tests or field days. Using the Library Keeping node information in a shared wiki rather than a single operator's notes means the network survives personnel changes. Maintain a repeater reference entry for every permanent node in your network, capturing the fields listed above. Update the library entry whenever hardware changes, firmware is updated, or maintainer contact information changes. Stale documentation is worse than no documentation because it misleads the next person who needs to act on it. Repeater Naming Conventions Choose a consistent naming scheme before you deploy your first permanent repeater. Changing it later is painful - nodes appear on maps and in message logs, and inconsistency creates confusion. Common options: Location-based: MeshAmerica-WestHills-1 - Human-readable, easy to orient on a map Callsign-based: KD9XYZ-SiteA - Ties a node to a licensed amateur. Use this ONLY if the node operates under amateur (Part 97) rules, which means open, unencrypted operation with no obscured content. Do NOT put a callsign on a node running a private/PSK-encrypted channel, or on a default Part 15 node on 915 MHz ISM - mislabeling such a node with a callsign can imply unlawful amateur operation. Callsign-as-identity only provides "EmComm accountability" in unencrypted Part 97 mode. Sequential: PDX-Repeater-01 - Simple, scales cleanly Pick one scheme and document it. New nodes added by new community members should follow the same convention. Channel Documentation Publish your channel name and modem preset publicly - on your Discord, website, or wiki. New participants need this information to join the network. Do not publish the PSK publicly if your community uses a private channel for security. Share the PSK via QR code (or channel URL) to verified participants only - the QR/URL carries the PSK, which is why it must be shared carefully. The QR code / channel URL encodes the shared channel(s) you choose to include plus the LoRa/modem-preset settings - it is the standard mechanism for onboarding new nodes. Review which channels are included before sharing it. Firmware Version Tracking Maintain a log of when each node was last updated. Meshtastic firmware is actively developed; nodes running outdated versions may miss bug fixes, compatibility improvements, or security patches. Schedule a quarterly firmware review: check each node's current version, identify which nodes need updates, and coordinate with site maintainers to get access for updates. A node that hasn't been updated in over a year should be treated as a maintenance priority. Incident Log When a node goes offline - whether due to weather, power failure, hardware failure, or vandalism - document: What happened When it was detected What was done to restore service What (if anything) changed to prevent recurrence This institutional knowledge prevents repeat failures. The second time a solar controller fails in a cold snap, the person responding should be able to find a record of what worked last time. Succession Planning Community networks outlast individual operators. Plan for turnover: Ensure at least two people have physical and administrative access to every critical node. Document access procedures (who has the key to the rooftop, who has the admin channel QR code). Store admin channel QR codes securely, with a trusted backup outside your own household. A fireproof envelope with a co-maintainer is a reasonable standard. Review the succession plan annually. People move, change jobs, and lose interest. The plan is only useful if it's current. Handling Network Growth and Congestion A Meshtastic network that works well with five nodes may behave poorly at fifty. Managing growth proactively - rather than reacting after congestion degrades performance - is what separates a durable community network from one that works great until it doesn't. Early Stage: 1 - 10 Nodes At this scale, almost any configuration works. Long Fast is a reasonable default - it has good range and is the most common preset, making it easy for newcomers to join. Focus at this stage belongs on placement, not optimization. A single well-placed repeater on a hilltop or water tower does more for network coverage than ten ground-level nodes. Get repeaters in good locations first. Growth Stage: 10 - 50 Nodes As the network grows, start monitoring channel utilization. The Meshtastic app displays this metric; check it periodically. Channel utilization is generally healthy below ~25% - the firmware defers transmitting until utilization drops below 25% (packets are deferred, not dropped). As a rule of thumb on the app's 1-minute window, green is under 25%, orange is 25-50%, and red is over 50%. Sustained utilization above ~25% (and especially above 50%) is a warning sign. Actions at this stage: Audit hop limits. High hop limits cause individual messages to generate multiple retransmissions across many nodes. A hop limit of 3 is appropriate for most community networks; higher values compound congestion (the Meshtastic maximum is 7). Review node density. Clusters of nodes in the same small area all hear and retransmit each other's traffic. Nodes that add density without extending coverage add congestion without benefit. Begin discussing a potential preset migration with the community before it becomes urgent. Scaling Stage: 50+ Nodes At this scale, Long Fast will likely show sustained high utilization. Seriously consider migrating to Medium Fast or Medium Slow, which use higher data rates and shorter airtime per message to reduce congestion - in exchange for some range and receiver sensitivity compared to Long Fast. The point of the migration is to gain channel capacity, not range: Long Fast actually reaches farther, while the Medium presets are faster but shorter range. That capacity tradeoff is what matters when node count is high and airtime is the remaining problem. This migration must be coordinated as a community. All nodes must change simultaneously, or you split the network - nodes on different presets cannot communicate. Preset Migration Process Pick a date and time for the migration window. Announce in all community channels at least two weeks in advance. Post in Discord, on the website, and in any mailing lists. Include the specific preset being adopted. Document the change procedure - a step-by-step guide for changing the preset in the Meshtastic app, for both Android/iOS and the web client. Change infrastructure repeaters first. These are the reference points that participants will see when they join on the new preset. Ask all participants to update within the migration window. A specific two-hour window on a weekend afternoon works better than "sometime this week." Keep one repeater on the old preset temporarily. Leave a repeater on the old preset for 1 - 2 weeks after migration so not-yet-migrated stragglers still have something to join. Note this does not bridge the two presets - a node on the old preset cannot hear or relay to nodes on the new preset (different modem settings mean no interoperability). It only continues serving users who haven't migrated yet, giving them a way to see a message like "Network has migrated to Medium Slow - update your preset to rejoin" and self-serve the fix. True bridging between two presets requires a dual-radio gateway running both presets at once. Managing the Public Channel You cannot control what strangers do on the public channel. Trolling, spam messages, and misconfigured nodes that flood the network with repeated traffic are occasional realities on any open mesh. Mitigation strategies: Maintain a secondary private channel for your community's operational use, regardless of network size. The public channel is for newcomers and casual use; the private channel is for your community's serious coordination. Document and enforce a community hop limit recommendation. Node roles and rebroadcast settings can limit how infrastructure nodes relay traffic, which helps limit cascading retransmissions. Treat persistent disruptive nodes as a maintenance issue, not a personal conflict. Document the node ID and behavior, and discuss with your community whether any technical mitigations are warranted. Tracking Growth Health Watch these indicators month over month: Node count - use your own node database or the Meshtastic app for accurate total and online counts. Note meshmap.net only shows nodes that report to the public Meshtastic MQTT server, so a private community network (with MQTT uplink off) will not appear there in full and it is not a reliable node-count dashboard for your network. Channel utilization during peak hours Ratio of infrastructure repeaters to client nodes (more repeaters relative to total nodes = better network health) Growth that outruns infrastructure is the most common failure mode for community meshes. Adding repeaters ahead of demand keeps the network healthy through growth phases.