How to Use Affordable and Open-Source Software Tools for Community Network Mobilization

Through the Benton Opportunity Fund fellowship, Dr. Esther Jang will be publishing how-to guides or recipes to help community-based organizations establish and operate local connectivity projects for low-income and marginalized groups.

October 2025

---

The Seattle Community Network (SCN) is a volunteer-based, grassroots community nonprofit with a small operating budget (currently averaging $10-$50K in grants, donations, or in-kind contributions per year) that installs and provides internet access for homeless shelters. This post describes the software infrastructure we use to run our network and operations.^[1] The solutions detailed here will be most apt for other community networks that feature similar organizational styles and seek to minimize operating costs. The time, technical labor, and expertise that our volunteers contribute allows us to save money. As a DIY “community learning network,” we collectively enjoy and gain valuable experience from configuring and maintaining SCN's software stack. Doing so, and writing public documentation about it, also furthers our mission of contributing technical knowledge and facilitating learning experiences for the broader public.

Our software “stack,” a set of technologies that work together, is a dynamic, evolving system that reflects volunteers’ interests, capacities, and opinions on how we should operate and organize.^[2] Operations vary widely between community networks, so it may not be necessary or worthwhile for all groups to deploy or maintain the same software.

When our network was bootstrapping in 2019, we started with just a simple free website hosted on GitHub, a shared Google Drive folder for documentation, a Slack group for team communications, and a management virtual private network (VPN) for remote site access that we self-hosted on Azure (Microsoft’s public cloud) using $2000/year of free credits available to qualifying nonprofits (for which we have to re-certify each year). Since that time, we have grown the number of services we self-host to support our activities and migrated most of them to an on-premises server to save money.

The software stack described here^[3] is used to support and manage:

• External publicity for recruiting volunteers, partners, donations, and users;
• Internal collaboration, communications, and community-building among volunteers,
• Information retention in the face of volunteer turnover,
• Remote monitoring, management, and troubleshooting of network sites by volunteers,
• Core network and routing functions for both volunteer- and user-facing services, and
• Authentication and credential access for our internal infrastructure.

A Note on Open-Source Software and Self-hosting

We use many open-source software tools in our production network. Free and open-source software (FOSS) describes any computer program for which the source code is free and open for the public to read, download, and use for their own purposes, often hosted on public platforms such as GitHub and GitLab. Utilizing FOSS is powerful because it dramatically reduces the cost of enterprise-grade functions for our network that many of our volunteers with tech industry backgrounds want to get more experience with. Examples of the FOSS we use range from an internal site management VPN that helps our volunteers conduct remote troubleshooting to a custom-written Discord bot that allows us to create and manage shared volunteer tasks in a ticketing system.

An example ticket in our custom Discord Bot-Redmine ticketing system, called "Netbot" (actively in development by volunteer Paul Philion).

We self-host much of this software, or run an instance of it on a physical computer (or server) that we own, located in a facility that we have physical access to, instead of paying someone to depend on their instance of the software hosted somewhere else. Self-hosting increases our ownership and privacy rights over the data held in the software, allowing us to customize and integrate different software applications in ways that best meet our needs.

However, self-hosting is not a panacea; it comes with the risk and responsibilities of managing our own hardware and software. The responsibility of maintaining hardware redundancy, disaster recovery procedures, and data backups falls to us, which means sometimes physically going on-site to repair hardware failures, and occasionally losing access to our own services due to small human mistakes. Every new software we deploy needs regular maintenance, and at least one committed volunteer to care for it—someone who understands how it works and is willing to jump in and save the day when its failure is affecting someone else’s day-to-day operations. Our current resilience strategy is to keep our most critical software and data—those necessary to help us recover from a catastrophic failure in our self-owned resources—either backed up to or hosted on a commercial public cloud. For example, these most critical services include our shared file storage containing details about our network, and our organization’s password manager containing access credentials for all our software and field hardware. We may eventually add enough hardware redundancy to become largely independent of public cloud solutions except for occasional backups.

A Snapshot of our Infrastructure in 2025

Here is a summary of our current software infrastructure,^[4] organized by type of solution.

Externally Hosted

We use some software that we host externally because it either needs to integrate with external technology ecosystems (such as payments or social media) or is critical enough that we do not want to be able to mess up and take it down by accident. As our organizational capacity grows over time, we may change some of these services to self-hosted options.

• Channel-based Chat Server: Our internal communications are our most critical infrastructure for organizing. This needs to remain online (or easily recoverable) at all times so we can coordinate solutions if the rest of our network catastrophically fails. We use a publicly accessible, free-tier Discord server for real-time communication among volunteers through channel-based text, voice, and video chat. We moved from Slack to Discord a few years ago because Slack’s free tier became more restricted, a few vocal volunteers expressed a strong preference for Discord, and it was considered more accessible for youth participants.

A screenshot of our Meetup group webpage, which lists public events such as monthly hack nights and community meetings.

• Public Event Listing Site: We use Meetup.com, a popular platform for listing public interest group events (which costs about $12/month). Our regular monthly public events, an open community meeting and a hands-on “hack night” where we work on current technical projects, result in a slow but steady stream of new volunteers. At these events, people new to our work can find out more about our activities and decide whether to become more deeply involved.
• Public Website: Our website is a public information hub for potential users and volunteers, containing information on how to get involved (such as a public calendar and Discord server invitation) or donate. This could easily be self-hosted, but as a static site it’s also free to host on GitHub. We pay about $17 per year for our custom domain name (regardless of hosting solution).
• Donation Portals: Our Paypal, Stripe, and Gofundme enable community- and crowd-based fundraising is a slow but important strategy that builds resilience in times of low grant funding. The cost for these is paid through fees of a few percent on each transaction.

Our Gofundme page.

• Collaborative Document Storage and Editing: We currently use Google Suite, which includes a shared Google Drive for document storage, though we are actively looking to migrate to a self-hosted Nextcloud. Google Suite provides a cloud-hosted file store for documentation and information about our network sites, with user login-based permissions built in. Google Suite was initially chosen because it is free, commonly used, permits unlimited collaborators, is redundantly backed up, and allows easy file and photo upload from mobile apps during field work. Google Suite is $5 per month via TechSoup’s nonprofit discount and includes email addresses, with an additional $10 per month for a Google Voice phone number. The convenience of so many integrated critical services has been hard to escape. Even so, volunteers are interested in self-hosted alternatives for knowledge management (such as a wiki), primarily because our documentation in Google Drive has grown to an unwieldy size. A temperamental “search” function is often the only reasonable way to find the documents we need to understand our software configuration and history.
• Social Media: We currently maintain accounts on X, Instagram, Facebook, LinkedIn, and BlueSky, though one of our biggest challenges is finding volunteers who are willing to update them. (Most of our volunteers are technical people largely uninterested in social media posting.) We recently made it an official community board member responsibility to post on social media, which has been somewhat successful.

Self-Hosted or Self-Managed on Public Cloud

The services that we self-host or self-manage on a public cloud are critical services we want to fully own and control, but we also need them to remain functional if the rest of our network has an outage. We try to keep this set of services minimal so that we can stay within our annual budget of free nonprofit credits.

• Site Management VPN: A VPN connects our community network internet sites to a central server in Azure, as well as other internal software tools such as a monitoring service that alerts us when the sites become disconnected. Trusted volunteers are given access to the VPN via a unique, secure private key that encrypts their communications with the central server and the field machines. Some options for a VPN that you can self-host include OpenVPN Community Edition and WireGuard. Some other community-managed networks use Tailscale for remote site management.
• Active Directory Server for Authentication: An Active Directory server provides a listing of each volunteer and their permissions, as well as a standard protocol for authenticating them to arbitrary other software applications that support that protocol. We use the software FreeIPA, which uses the Lightweight Directory Access Protocol (LDAP) for managing user authentication, along with plugins for LDAP support (if possible) on each other software service we use. We are also testing out Keycloak which is an open-source single-sign-on (SSO) application that can log volunteers into and out of all of our other compatible services at once.
• Configuration & Data backups: We use backups to Azure “Blob storage” (cloud storage) for software service configuration files, as well as critical logs and databases for some of our software services. We could also expand this to include our network device configurations. Backup storage that does not need to be accessed frequently can cost as little as a few cents per month.
• Domain Name Service (DNS): A DNS server translates domain names (i.e. human-readable URL strings such as “facebook.com” or “seattlecommunitynetwork.org”) to IP addresses, directing web browsers and other networked applications looking for those services to the correct servers that are hosting them. We currently use Azure’s DNS service for a few dollars per month, which provides self-managed, reliable DNS for both our external and internal VPN-access-only domain names.

Self-Hosted “on Premises” (on our own physical Server)

Self-hosted on premises services are those services for which we have enough expertise and/or hubris at this point to take full responsibility for keeping alive.

• SCN Private Cloud: We use Proxmox, an open-source hypervisor (a special type of server that can run and manage virtual machines), on a physical server that we own in a datacenter. This essentially creates a private cloud we can use to self-host software services instead of paying for the use of virtual machines in Azure cloud.
• Core Network Routers: We use an instance of the open-source router software Vyos, running in a virtual machine inside of our Proxmox server, to connect our internal software services to each other and to the internet. We also use Vyos on another dedicated physical “core router” that connects our network to the global internet. This core router is another server in the same datacenter that is connected via fiber-optic cables to the Seattle Internet Exchange; the router runs the Border Gateway Protocol (BGP) so our network can peer with other internet service providers’ networks. We physically separate the internal and external routing onto different machines so that internal network changes will not accidentally disrupt the public-facing router and cause chaos on the public internet. These functions are currently critical to our network, and require hardware- and software-redundant configurations for reliability.

Our self-hosted password manager Vaultwarden, with built-in password generation functions

• Shared Password Manager: We use Vaultwarden, a self-hosted password manager that securely stores sensitive credentials—like passwords, SSH keys, and API tokens—that volunteers need to remotely access network sites and any other machines running our internal software services. This service is critical for recovery during a network outage; however, we recently moved this service over from Public Cloud hosting after implementing daily offsite backups that would be straightforward to recover.
• Network Documentation Software: We are starting to use NetBox, a device inventory and documentation system meant to establish a “source of truth” (what device and network settings should be) for network infrastructure in datacenters. In an ideal scenario, live device configurations pulled from field-deployed devices using other software tools can be compared to the records in NetBox, and discrepancies can be automatically flagged. The software’s design is not perfect for field-deployed equipment, and it’s pretty laborious to maintain for volunteers (often a chore in IT workplaces). Our instance is currently underutilized due to volunteer process gaps, but we are looking at possible automations to help. This service is also potentially critical in an emergency, and requires backups.
• Network Monitoring (SNMP Aggregator): We use LibreNMS, network monitoring software that collects and displays device health and internet connectivity stats from devices on our network using a standard network monitoring protocol called Simple Network Management Protocol (SNMP), support for which is built into a lot of networking equipment. LibreNMS lets us track device status in real-time, generate usage statistics, and receive alerts when devices have gone offline or need maintenance. If the LibreNMS instance failed, we would temporarily lose some monitoring functions, but nothing else would be affected.

An example of a site monitoring dashboard on our self-hosted Unifi configuration server.

• Managed Wi-Fi Configuration Servers: We self-host software applications called UniFi (from the device manufacturer Ubiquiti) and Omada (from TP-Link) that allow us to remotely manage and configure the Wi-Fi access points we deploy in the field from these respective manufacturers. UniFi and Omada are directly competing wireless product lines that are essentially equivalent in functionality; having both types of servers allows us to deploy either equipment brand depending on the hardware we have on hand. However, in general, we recommend standardizing on one type of hardware if possible to simplify management and volunteer training. If either of these services failed, the Wi-Fi would remain unaffected at our sites (though we would temporarily lose the ability to change anything about the devices’ configuration until the services recovered).

Our current ticketing system back-end, Redmine (on the left), along with an example ticket created in a Discord thread using our custom "Netbot" ticket management tool (on the right), which interfaces with Redmine.

• “Ticketing” System or Issue Tracker: We use Redmine, a project management software that allows us to track, categorize, and assign tasks to volunteers and teams. One of our volunteers has also written a custom Discord bot that allows us to manage and organize tickets entirely within Discord threads. Due to the lack of desired “Kanban” or visualization board functionality (e.g., as provided in Jira or Trello), we are currently exploring alternatives that can also be integrated with the Discord bot.

How Software Supports Our Operations

Preparing to install a new site

(as in the previous blog post)

Volunteers coordinate on Discord to make an install plan, typically in Discord threads synced with our ticketing system. We share information, coordinate dates for site surveys and installs, and organize attendance. Since we’re all volunteers, we can’t take for granted who exactly will come, and what skills, tools, or familiarity with SCN they will bring.

We write up the install plan in a shared doc, with a drawing tool for site maps and diagrams, and spreadsheets for equipment budgets. These documents are shared before the install so volunteers can coordinate what to expect and bring, and they are kept on file to maintain a record of what was done.

Ideally, all devices are pre-configured before the install, including their connections to our management VPN, which volunteers can use to troubleshoot the devices remotely. We attempt to pre-enter IP address assignments and other configuration details in our NetBox instance ahead of time. However, sometimes things change during the install, and we usually have to update the NetBox entries afterward. We also make sure all the device login passwords are stored in Vaultwarden so that other volunteers can help with remote troubleshooting. The Vaultwarden administrators are responsible for giving individual volunteers’ accounts access to just the sites and services they will be helping out with. Finally, for any devices that support the SNMP protocol, we configure them to provide device health and status updates to our LibreNMS monitoring server over its management VPN connection.

We may have to take additional steps to prepare any Wi-Fi Access Points (APs) made by Ubiquiti or TP-Link that use the UniFi or Omada configuration servers, respectively (see Managed Wi-Fi Configuration Servers in the Self-Hosted section above). We would “adopt” these devices to a self-hosted server instance by putting our own server’s URL in their configurations, and then manage any additional changes from the remote server.

Conducting a site repair or troubleshooting

On one occasion several years ago, our computer at the Filipino Community Center (running an LTE “Evolved Packet Core” or EPC) suddenly failed; however, we did not know that immediately and had to figure it out over a number of steps.

At the time, our LibreNMS monitoring service was poorly tuned and had been registering numerous false alarms, including spurious over-temperature warnings, which meant volunteers did not closely track it. As a result, we did not notice the network failure for about half a day. I finally noticed a complaint about the internet not working through one of our user support platforms. I happened to be the person living closest to that site at the time (a 20-minute walk) and had been the install lead in 2021, so I was the most familiar with the site and its users. I initiated the following protocol:

• Respond back to the home users of that site that the outage is being addressed. Here I used an email list with all of that site’s users that we had set up beforehand. I knew at least some of them had a backup internet connection they could use to receive email (e.g., cellular data), and most of these users lived in the same apartment complex so they could share information with each other.
• Use the management VPN to try to remotely check on each device at the site, starting with the gateway router. This check can help verify at which device the chain of connectivity is broken from the rest of the internet (where my traffic was coming from) to the end-user. I was able to see that the gateway router at the site was alive and reachable over the VPN, but the EPC computer connected to it was not. I used credentials from our shared password manager to log into the router, and check if any kind of direct connectivity from the router to the computer was still possible. This could happen if, for example, just the VPN software on the computer had crashed, or some networking functions on the computer had stopped but others were still working. No communication was possible, indicating a bigger problem with the unreachable computer. At this point I started looking around for other computers to substitute, in case it turned out to be unrecoverable within the same visit.
• Check in with others for confirmation and remote help. I informed the SCN Discord of my findings and intention to go on-site to check out the issue immediately. It is always helpful to have a remote buddy (or several) who can help you check on device statuses, especially if you’re at a site with malfunctioning internet access, or who can simply validate your findings. For example, I could have failed to access the computer because I was missing information about a configuration change, or because of the network I happened to be using, my own VPN configuration, etc.
• Schedule physical access. Thankfully, it was a Friday afternoon and the community center was open, so I was able to call the facility manager to ask for access and arrive within the hour, monitor and USB keyboard in hand. In the past, another outage had lasted almost two days because I couldn’t get in during a weekend when the community center was closed. This can be a big problem in shared or public spaces, increasing response times. While there’s no generic solution, having an emergency access agreement or responsive enough communications in place with partner organizations to gain quick access is recommended.
• Bring and prep any needed equipment for the repair. On-site, I confirmed that the old machine would no longer boot normally. I fortunately had a spare laptop on hand that I could configure to run the same software (open5GS) before we could purchase a replacement. The device configuration details at the time were stored as a shared doc in Google Drive, so I replicated them manually following a tutorial I had written for myself several years ago—luckily not too many steps. (Today, we are exploring more automated ways of storing, checking, and applying configuration using NetBox and Ansible.) I also thankfully had a backup of the user database (then manually stored in Google Drive, now automatically in Azure), which was needed to re-register the users in the new machine’s LTE software. This interim solution was in place for about a week before we were able to install a replacement.
• Confirm that the fix is working for end-users. While still on-site, I was able to chat with one of the site’s users on Discord to confirm the internet was now working. Sometimes this has to happen after a technician leaves the site, but it occasionally means that another visit might be required to tie up loose ends.

LTE Evolved Packet Core setup tutorial hosted on the SCN documentation website.

Not everyone needs the same things

Finally, every community network has different parameters and needs. In SCN, we aim to build and maintain a volunteer community that can deliver and maintain internet services with minimal operating costs. While I’ve detailed in this post some affordable software services and open-source tools that work for us, it’s possible to operate with or without these tools, or using different tools.^[5]

Briefly, here are the core challenges we face that other organizations might share, for which your organization may establish or have different solutions, including those that do not require software:

1. Managing volunteer turnover, and/or retaining volunteers

• Sustaining regular activities and practices that support a positive internal culture of sharing, skill-building, learning and teaching, and having fun while building and maintaining networks. This helps build relationships internally and retain volunteers.
• Building relationships and trust with both community partner organizations and network users. Trust is easiest to build via in-person collaborative work (for example, to establish network sites), though digital communications channels may initially help build bridges, and they work best by minimizing personnel turnover.
• Keeping organized and sharing network details, statuses, and access securely between diverse and changing hands.
• Maintaining in-house volunteer capacity and time for all our needed functions, which requires constant new volunteer recruitment and onboarding.
• Timely responses to user needs, which require quick internal coordination over digital means, as well as timely and gracious communications letting users know when they can be soonest available. Working together as a whole, our community can usually provide this, as some volunteers have flexible working schedules and a lot of dedication.
• Achieving reliable and regular software and hardware maintenance across the whole network. This is currently in total a lot of manual effort, with at least one site needing to be visited or worked on remotely nearly every week (and sometimes the volunteers can’t make it so tasks pile up).

2. Keeping the network reliable across sources of infrastructural churn

• Turnover of diverse free or low-cost “backhaul” internet connections we use at sites, often through temporary arrangements. Strong documentation practices and flexible management configurations (such as our VPN) can help with this.
• User self-fixes or network changes that, while generally welcome as they teach users to manage their own infrastructure and offload on-site labor from volunteers, may include mistakes that create more work (for example, unplugging and re-plugging cables into the wrong places, which happened in one case). Robust communications and rapport with users, for example the ability to debug problems together over a phone or video call, can reduce the labor for these fixes.

 

Volunteers moving our equipment and tools into our new SCN community lab space, July 2024.

3. Acquiring funding or donations (cash or hardware/technology)

• Funding and resources are required for new site installs, upgrades, or repairs—activities that are needed to maintain volunteer community engagement and skill-building. However, grant writing and fulfillment require sustained effort, commitment, and accountability to these tasks, which necessitate effective volunteer retention.

Ready to tackle some of these challenges? Let’s begin.