Five communities. Different cities, different protocols, different founding conditions. All of them building something the incumbents said couldn't be done.
Everyone who gets into mesh networking eventually reaches the same realization: the hardware is the easy part. You can buy a LoRa node for $30, flash firmware in ten minutes, and have a radio singing into the air by lunchtime. What you can't buy is a neighborhood of people who keep their nodes on, replace dead batteries, troubleshoot coverage gaps on their own time, and recruit their neighbors to do the same.
The communities in this guide figured that out. They are not the largest tech companies in the world. They are not government infrastructure programs. They are groups of volunteers — some with amateur radio licenses, some without, some with deep RF engineering backgrounds, some who just wanted a way to text their neighbors without going through a cell tower — who built something real. On rooftops. On hilltops. In Discord servers and parking lots and cramped back-offices with potato chips on folding tables.
This is a field report on what they built, how they did it, and what anyone trying to start or grow a mesh community can take from their experience.
The hardware is the easy part. What you can't buy is a neighborhood of people who keep their nodes on and recruit their neighbors to do the same.
This guide profiles four communities that represent distinct geographic conditions, protocol choices, and origin stories. They are not the only communities doing this work — Denver Mesh, Sacramento Valley Mesh, Sac Valley Mesh, Red Hook Digital Stewards, and dozens of others are building serious infrastructure and deserve their own coverage. These four are highlighted because together they span the full range of what "community mesh" can mean: a hobbyist collective turned resilience network, a disaster-prep coalition running a specific protocol stack, a multi-city regional spine, and a decade-old community ISP.
This is journalism, not advertising. Where communities have friction points or unresolved challenges, they are described plainly. The goal is an honest picture of the state of the art so that people building new communities have realistic expectations and can skip the mistakes others already made.
The Bay Area Meshtastic Community — known online as BayMesh and found at bayme.sh — is one of the densest and most organizationally developed LoRa mesh communities in North America. With roughly 250 active nodes visible on their real-time Meshview map at any given moment, spread across San Francisco, Oakland, San Jose, the East Bay, and further out to Hollister and Gilroy, BayMesh has achieved something most mesh communities only aspire to: genuine geographic density in a major metro area.
The community draws its membership from "diverse backgrounds" — their own description — and has become a hub for both licensed amateur radio operators and people who just want to communicate without cell infrastructure. That breadth shows in how they operate. They maintain a Discord server for off-mesh coordination, hold regular on-air net meetings, built their own custom Meshview dashboard (separate from the official meshmap.net), and even deployed a Discord bot called RATM (a backronym lost to community history) to bridge the on-air and off-air worlds.
BayMesh's coverage is built around a fundamental insight that distinguishes functional mesh communities from collections of nodes: topology-aware placement. Their documentation explicitly teaches this. They recommend "roof nodes" — client nodes installed on rooftops that act as relays for indoor portable nodes — because 900 MHz LoRa is significantly attenuated by walls, metal-backed siding, and tree canopy. The coverage you get inside your house isn't the coverage your neighbor's rooftop node gets.
The Mount Diablo installation is the clearest expression of this principle. Trevor Raty (KG6MDW) built and manages two nodes on the north peak of Mount Diablo — one on each of the two primary presets the community uses — and the setup was significant enough that it was featured on Ham Radio Crash Course during Pacificon 2024. Elevation is coverage. That's the whole lesson, and BayMesh has applied it systematically.
As of late 2025, BayMesh was actively migrating from the MediumSlow preset to MediumFast. This matters because the two presets aren't directly compatible — nodes on different presets can't hear each other — and coordinating a community-wide preset change across 250+ nodes requires sustained, organized effort. The fact that they're doing it at all says something about the maturity of the community's coordination capacity.
BayMesh has a genuine coverage problem in terrain-fragmented zones. The Bay Area's geography — the Oakland Hills, the Santa Cruz Mountains, the flat plains of the South Bay — creates pockets where the mesh simply doesn't reach without a hilltop relay. A Pinole Valley resident described spending weeks unable to connect to the mesh at all despite dozens of nearby nodes, because a ridgeline stood between them and every active relay. The LoRa band is essentially line-of-sight. The community knows this and documents it, but knowing doesn't make the terrain flat.
The MQTT bridge — the mechanism that connects the radio mesh to an internet-visible dashboard — also requires a centralized broker, which introduces the kind of infrastructure dependency the mesh exists to avoid. BayMesh runs their own broker rather than relying on the public Meshtastic MQTT server (which has been deliberately throttled and restricted to reduce abuse), but it's still a choke point worth noting.
Southern California has two parallel mesh communities, with a third emerging from the friction between them. The first is SoCal Mesh (socalmesh.org), a hobbyist-to-resilience community running hundreds of Meshtastic nodes across Los Angeles, Orange, Riverside, and western San Bernardino counties. The second is a disaster-communications-focused operation at socalmesh.com that runs the same branding but operates more as infrastructure for emergency communications with first responders in mind. And the third — West Coast Mesh, WCMesh — launched formally in August 2025 specifically because some SoCal operators hit the ceiling of what Meshtastic's flood-based routing could do at scale and pivoted to MeshCore.
All three are worth understanding because together they represent what happens when a mesh community gets large enough to develop internal pressure. Meshtastic works well in a neighborhood. It gets complicated when you're trying to coordinate hundreds of nodes across four counties of some of the most complex urban terrain in the country.
The community-facing SoCal Mesh operates as an open platform: they've deployed infrastructure nodes across Southern California and explicitly invite anyone to use the infrastructure and extend it. Their messaging positions the network as a text messaging system that covers a metro area — "without any external infrastructure, no cell phone towers, no internet" — and the community is growing continuously. It's an inviting model for new users precisely because the bar to participate is low: you join the Discord, you get a node, your node extends the mesh for everyone.
The story of WCMesh is a good case study in how protocol decisions get made in real communities. A group of SoCal operators, who ran loosely as "MeshCore pirates" in early 2025, found that Meshtastic's managed flood algorithm — the mechanism by which messages get rebroadcast across the network — was failing in large, dense deployments. Too many nodes, too much congestion, too many poorly placed routers amplifying the problem rather than solving it.
In July 2025, Discord conversations crystallized into a serious effort. In August, nine founding members gathered for lunch in Pasadena — known by handles K7, C2D, Ferret, Treehouse, PasadenaRadioUser, DaddyCTO, CrisprCAS9, Whitelightning, and Nerdherder — and WCMesh became a formal infrastructure project. Their defining choice: 100% MeshCore. Not because Meshtastic is bad, but because MeshCore's path-discovery routing scales to dense urban environments in a way that flood-based protocols struggle to.
WCMesh's administrator was explicit: the pivot to MeshCore was pragmatic, not ideological. At the time, MeshCore offered a path to solving problems that SoCal's scale had exposed. Meshtastic has continued improving — v2.6 introduced next-hop routing that addresses some of the flood limitations — but the WCMesh community had already committed and built around MeshCore's model. This is not unusual: communities that hit protocol ceilings usually don't wait for the next firmware update. They switch and build.
The Pacific Northwest mesh community — operating under Puget Mesh (pugetmesh.org) for the Puget Sound region and CascadiaMesh (cascadiamesh.org) for the broader corridor — is, by most measures, the most mature LoRa mesh community in the United States. MeshCore's Seattle deployment is described by community members as the largest MeshCore network in the world. The corridor from Vancouver, BC to Eugene, Oregon can be traversed in 12 hops using MeshCore under the right atmospheric conditions, and the community routinely communicates city to city across the region.
Understanding why this happened in Seattle, of all places, requires understanding the founding condition. The Cascadia Subduction Zone — a 600-mile fault capable of a magnitude 9.0+ megathrust earthquake — has concentrated minds in the Pacific Northwest in a way that doesn't have an equivalent in most US cities. Seismologists put the probability of a major event in the next 50 years at roughly 37%. The 2001 Nisqually earthquake, which was a fraction of a full Cascadia rupture, knocked out Seattle communications for hours. The community isn't building a toy. They're building a survival layer.
The PNW community's migration from Meshtastic to MeshCore is a recurring reference point in the broader mesh networking world. Here is the key detail: they had a Meshtastic developer living in Seattle. They tried every configuration. They could not make Meshtastic mesh reliably at the scale and density of the Seattle metro. The managed flood algorithm failed in practice, repeatedly. When MeshCore became available and promising, the switch happened quickly and decisively — and it worked. A community member described the result: reliable communication from Olympia to Vancouver, BC, with occasional atmospheric carries reaching Portland.
The topology helps. Seattle's hills — Queen Anne, Capitol Hill, Beacon Hill — are liabilities for roads and cables during earthquakes, but assets for RF. A well-placed repeater on Queen Anne has line-of-sight across vast stretches of the city, bridging neighborhoods that roads and fiber cannot. CascadiaMesh's mostly solar-powered node infrastructure is designed explicitly around the grid-down scenario: when the power goes out, the nodes stay on.
Puget Mesh holds in-person meetups at the Radio Club of Tacoma (W7DK) and the Shoreline Library. CascadiaMesh hosts open nights — no RSVP, just show up — and frames them explicitly for "nerds and non-technical people alike." Both communities coordinate primarily through Discord. The infrastructure is volunteer-deployed and maintained; CascadiaMesh collaborates with local clubs and technical communities to share best practices across the Cascadia region rather than operating as a single centralized organization.
A detail from a Portland observer working with both meshes is worth noting: even when coverage exists, it isn't always symmetric. A strong transmitter in Seattle can reach Portland, but Portland may not have a signal strong enough to reply. In packet radio, you can be "read-only" — lurking but unable to send. As the network grows and infrastructure fills in, this improves. But it's a real characteristic of the technology that new operators should understand before assuming coverage equals two-way communication.
NYC Mesh is a different kind of mesh community. It is not running LoRa. It is not primarily a disaster preparedness project. It is a full community internet service provider — the largest community-owned and operated wireless network in North America — that has been operating continuously since 2013 and now serves over 2,000 active member nodes across Manhattan and Brooklyn, with the remaining three boroughs in its expansion target.
Including NYC Mesh in a field guide focused on LoRa mesh communities is a deliberate choice. The community mesh movement has technical overlap with LoRa — both are about community-owned, decentralized communication infrastructure — but NYC Mesh represents what a community mesh becomes when it runs for a decade with serious organizational discipline. Everything the LoRa communities are trying to build, NYC Mesh has already built: self-sustaining membership model, rooftop infrastructure installed and maintained by volunteers, a routing protocol that actually scales, and a political identity as an alternative to incumbent ISPs.
NYC Mesh works through a layered infrastructure approach. Supernodes — major antenna installations with fiber internet connections — serve as the backbone. Rooftop nodes connect to supernodes via directional antennas and serve as local distribution points, each capable of connecting up to four apartments directly. Members pay what they can afford: $20 or $50 per month as a suggested residential contribution, $100 for business, plus $110 for hardware and a $50 installation fee. Subsidies are available. The network maintains net neutrality as a policy commitment, not just a talking point, and explicitly does not monitor, log, or monetize member traffic.
The Supernode 3 installation at Industry City in Brooklyn illustrates how the community scales. At roughly 50 times the capacity of the original Supernode 1, it opened coverage to Sunset Park, Park Slope, Gowanus, Red Hook, and surrounding neighborhoods — neighborhoods where a quarter to a third of residents had no broadband access at all. The community framed this explicitly as a digital equity project, and the framing is accurate: NYC Mesh operates at the intersection of infrastructure building and community organizing in a way most mesh communities haven't reached.
NYC Mesh is a non-profit project of the New York chapter of the Internet Society (ISOC-NY). Monthly meetings alternate between organizational meetings with presentations and breakout groups, and technical meetups. The community maintains "The Mothership" — a computer that reports node and supernode status across the city — and their online map shows every active node, connection type (wireless, fiber, VPN), and pending installation request.
"The idea that a community can just get together and bypass the ISPs and do infrastructure like this — I think it's a very inspiring thing."
Austin Mesh (austinmesh.org) has quietly become one of the most operationally sophisticated community mesh deployments in the United States — and one of the least talked about outside of Texas. They run both Meshtastic and MeshCore simultaneously, have accumulated hard-won engineering knowledge about solar node durability in extreme heat, and have done something no other community in this guide has managed: partnered with a public school district to put mesh networking into K–12 classrooms as a STEM curriculum.
The anchor of the Austin network is a node on top of the University of Texas Physics, Math, and Astronomy building — at approximately 80 meters above ground, with a 10dBi antenna and a 20W solar panel feeding a Voltaic Systems V50 battery. That single installation provides coverage across a significant portion of West, South, and East Austin. It is the textbook application of the elevation principle: one well-placed high node is worth dozens of ground-level nodes.
Austin Mesh has made a deliberate, documented decision to avoid MQTT — the internet bridging mechanism that most Meshtastic communities rely on to extend coverage and feed node maps. Their reasoning is worth reading in full, because it's the clearest articulation of a position that's implicit in how the best mesh communities operate: MQTT gives you a false sense of how robust your local RF network actually is. It makes the network look larger than it is, makes it harder to diagnose real coverage gaps, and — when pointed at a busy public broker — can flood the network with traffic and make local communication unreliable.
Austin Mesh's goal is to build a mesh that works when the internet is down. MQTT defeats that goal. So they don't use it. Every node on the network is a genuine RF relay, not an internet gateway in disguise.
Austin runs 80+ days above 100°F in summer. Austin Mesh has gone through five generations of solar enclosure design, iterating through component failures caused by extreme heat, humidity swings, lightning, and the basic challenge of keeping a low-power radio alive outdoors year-round without human intervention. Their published findings — specific component choices, enclosure configurations, failure modes, and what finally worked — are the most detailed publicly available solar node engineering guide for southern and desert climates anywhere in the mesh networking community. Other communities building solar infrastructure in hot climates should read it before buying anything.
The Austin Independent School District partnership is what elevates Austin Mesh from a well-run hobbyist community to something genuinely unusual. Teacher Raul Vallejo created a Meshtastic STEM Learning Initiative bringing hands-on mesh networking to students in grades 4 through 12 in Northeast Austin. Students assemble and configure their own Meshtastic devices, build local mesh networks, and use them to solve practical problems — emergency communication scenarios, environmental monitoring. The program is designed to be self-sustaining, with schools eventually maintaining their own mesh infrastructure.
This is the institutional anchor model operating at full power. A school district partnership means the community has access to rooftop locations, young people learning the technology, and the kind of institutional credibility that attracts future partners. It's the template other communities should be studying.
Austin Mesh demonstrates what happens when a community combines a clear no-MQTT RF-first philosophy, disciplined solar infrastructure engineering, and an institutional school district partnership. Each reinforces the others: the RF-only network proves the mesh works without internet, the solar nodes prove it works without power, and the school partnership proves it can outlast any individual volunteer.
These five communities differ significantly in their technology choices, founding conditions, and what "success" means to them. The comparison below is meant to help organizers understand which models are most relevant to their own context.
| Factor | BayMesh (SF) | SoCal Mesh (LA) | CascadiaMesh (PNW) | NYC Mesh | Austin Mesh |
|---|---|---|---|---|---|
| Founded | ~2020 | ~2021 | ~2020 (MeshCore pivot 2024) | 2013 | ~2021 |
| Primary tech | Meshtastic / LoRa | Meshtastic + MeshCore | MeshCore primary, AREDN + Meshtastic secondary | 802.11 wireless + fiber | Meshtastic + MeshCore (dual) |
| Scale | ~250 nodes | Hundreds | BC to OR corridor | 2,000+ member nodes | City-wide solar grid |
| Primary use case | Community comms, experimentation | Disaster / first responder support | Cascadia quake preparedness | Affordable internet access | Grid-down comms + STEM education |
| Grid-down capable? | Partial — MQTT bridge needs internet | Mostly — some nodes solar | Yes — mostly solar | No — backbone is internet-dependent | Yes — solar + no MQTT |
| Protocol rationale | Community standard, wide hardware support | Split — Meshtastic for accessibility, MeshCore for scale | Meshtastic failed at PNW scale; MeshCore works | 802.11 for speed; community ISP model | Both protocols, deliberately no MQTT bridge |
| Meetup culture | Discord-first, occasional IRL events | Discord + founding-lunch model | Strong — Radio club + library meetups | Very strong — bi-weekly structured meetings | Strong — bar meetups + AISD events |
| Funding model | Volunteer / donor | Volunteer / donor | Volunteer / donor | Suggested monthly donation ($20–$100) | Volunteer / donor + grant potential |
| Institutional partner? | MDARC (ham club) | None formal | Radio Club of Tacoma (W7DK) | ISOC-NY + NYCHA + HPD | Austin ISD K–12 |
| Best model for | Dense metro LoRa community building | Emergency services integration | Regional backbone with grid-down capability | Long-term community ISP / digital equity | Solar infrastructure + school / civic partnerships |
These communities are not competing with each other in any meaningful sense — they serve different needs, use different technology layers, and their success conditions don't overlap. NYC Mesh cannot help you communicate when the internet is down. BayMesh cannot give you high-speed internet access. CascadiaMesh's solar nodes won't deliver video calls. The right question for any new community is not "which of these should I copy?" but "what does our specific context actually need?" — and then look at which of these models most closely addresses that need.
Across all four communities, a handful of patterns show up consistently in what differentiates functional mesh communities from groups that stall at ten nodes. These aren't opinions — they're observations repeated across four independent communities in four different cities with four different technology stacks.
The communities that are still operating in ten years will have found ways to anchor themselves to institutions that outlast people.
If you're in a city or region without an active mesh community, the playbook from these four groups is reasonably consistent. You don't need to invent a new approach — you need to execute the basic model with consistency.
Not "mesh networking is cool" — that won't hold a community together for three years. What is the specific gap or threat that your city has that a mesh network addresses? Earthquake preparedness? Wildfire evacuation communication? Digital access for an underserved neighborhood? The clearer your answer, the easier it is to recruit people who share that concern.
Your first nodes are not about coverage. They are proof of concept. They need to actually talk to each other reliably, which means placing them with elevation and line-of-sight rather than convenience. A rooftop node on a three-story building is worth a dozen ground-level indoor nodes. Get the first link right before worrying about anything else.
Before you have a Discord, host a meetup. A library meeting room, a coffee shop back corner, a maker space. Announce it wherever local nerds gather — Nextdoor, local Facebook groups, Reddit, Mastodon, Bluesky. Show up, bring hardware, let people touch the nodes. The people who show up to that first meeting are your founding community. That group's culture will shape the community for years.
Meshtastic has the largest hardware compatibility and the most accessible on-ramp. MeshCore has better performance at density and scale. AREDN and 802.11-based community mesh (like NYC Mesh's model) provide higher throughput but higher installation complexity. Pick one for your initial build based on your use case. Document the choice. Plan to revisit it when you hit 50 nodes.
Look for a local amateur radio club, a makerspace, a digital equity organization, or a neighborhood preparedness group that would benefit from the mesh. Offer them something real — communication infrastructure for their events, a disaster preparedness layer for their neighborhood, a technical project for their members. An institutional relationship gives you meeting space, credibility, and continuity that a Discord server alone cannot.
Node Star Networks exists to support exactly this kind of community building. If you're starting a local mesh community and want hardware, documentation, or advice on getting the first nodes in the right places, get in touch at the contact form or find us on Mastodon. We want to know who's building.
| Community / Resource | URL | Protocol |
|---|---|---|
| Bay Area Meshtastic (BayMesh) | bayme.sh | Meshtastic |
| SoCal Mesh | socalmesh.org | Meshtastic |
| SoCal Mesh (disaster comms) | socalmesh.com | Meshtastic |
| Puget Mesh | pugetmesh.org | MeshCore + Meshtastic + AREDN |
| CascadiaMesh | cascadiamesh.org | MeshCore |
| NYC Mesh | nycmesh.net | 802.11 / Fiber / OSPF |
| Meshtastic (official) | meshtastic.org | — |
| MeshCore | meshcore.co.uk | — |
| Meshmap (global node map) | meshmap.net | — |
| MeshExplorer (MeshCore map) | map.meshcore.io | — |
| Austin Mesh | austinmesh.org | Meshtastic + MeshCore · solar-first |
| Sac Valley Mesh | sacvalleymesh.com | Meshtastic |
| ColoradoMesh (Denver) | denvermesh.org | Meshtastic · MeshCore · Reticulum |
| DC Mesh | dcmesh.org | Meshtastic · MeshCore · solar-first |
| Node Star Networks | nodestar.net | Meshtastic · Reticulum · Community |
| Node Star Labs | labs.nodestar.net | Deployment support for orgs & institutions |
These communities are not hobbyist clubs. They are building the communication infrastructure that will matter when commercial networks fail — and commercial networks fail. Wildfires, earthquakes, floods, winter storms, and power grid events have all demonstrated this in the last decade. The communities profiled in this guide are doing the slow, hard, unglamorous work of building something real before it's needed. The best time to build a mesh community in your city was five years ago. The second best time is now.