Digital Sovereignty for Communities: A Guide

Digital sovereignty for communities is what happens when a group — a housing co-op, a small town, a library, a tenants association, a mutual aid network — owns and governs the digital infrastructure it depends on, instead of renting it from companies whose incentives point somewhere else. It is the collective version of an idea most people first meet as a personal one. If you want the individual framing, start with what is digital sovereignty. This page is about the harder version: doing it as a group, on purpose, in a way that survives people leaving.

The technology part is largely solved. You can run a file server, a chat system, a login system and a neighborhood radio network today using well-documented free software and a used computer. What is not solved is the rest of it: who holds the root password, who decides moderation rules, who pays the electric bill in year three, and what happens to everyone’s files when the volunteer who built it moves away. Those questions are the actual subject here.

What Changes When Sovereignty Is Collective

Individual digital sovereignty is mostly a set of personal choices. You move your photos off a cloud service, you run a password manager you control, you change search engines. If you get bored and quit, the only person affected is you.

Collective sovereignty is a promise to other people. A server holding two hundred neighbors’ documents is not a hobby project any more, it is an obligation. The moment someone else stores something they cannot afford to lose on hardware you control, you have taken on duties that look a lot like the ones a small utility has: uptime, backups, privacy, notice before changes, and a way out.

That shift turns three quiet technical questions into governance questions. Who owns the hardware? Who holds the keys? Who decides? Large platforms answer all three the same way, and the answer is never you. A community that wants sovereignty has to answer them out loud, in writing, before anything important gets stored on the machine.

The Four Layers a Community Can Own

It helps to stop treating “our technology” as one thing. There are four layers, and a group can own any of them independently. Most communities own none at the start and one or two after a few years. That is a normal outcome, not a failure.

Owning the bottom layer is the most expensive and the most durable. It is why mesh networks keep coming up in these conversations: a mesh is one of the few ways a group can build usable connectivity without a carrier’s permission. Low-power LoRa mesh gear, like the off-grid hardware sold by Blackout Labs, is slow by broadband standards, but it works when the broadband does not.

Owning the top layer costs almost nothing and is the one people skip. A group that rents every server but writes its own rules is further along than a group with a beautiful rack and no agreement about who may read what.

Who Actually Does This, and What Legal Shape They Take

The legal form you pick is not paperwork trivia. It decides who you are accountable to, what money you can accept, and what happens if something goes wrong.

• Co-operative. Members own it, one member one vote, dues fund it. This is the model behind rural electric and telephone co-ops, and it maps cleanly onto a community ISP or a shared server. Slow to set up, and very hard for an outsider to capture.
• Municipal. A town, county or library district owns the infrastructure. Real budgets and real staff, but also procurement rules, public records obligations, and a governing body that can change its mind after an election.
• Nonprofit. A 501(c)(3) or similar can take grants and donations and answers to a board. Good for services given away rather than sold. The WOPR Foundation is one of these.
• Unincorporated group. A neighborhood association or a handful of friends. Fastest to start, but no bank account, no liability shield, and no clear owner of the hardware if the group splits.

You can start unincorporated and formalize later, and many groups should. The trigger for incorporating is usually money moving or data mattering: the first time you collect dues, sign for internet transit, or store something a member would be genuinely hurt to lose.

Governance: Who Holds the Keys

Root access is power. Whoever can log into the server as an administrator can read private messages, delete accounts and change the rules without asking anyone. Pretending otherwise is the most common failure in community technology, and it is social rather than technical.

Write down the answers to these before launch, in a document members can actually read:

• Who currently holds administrator access, by name, and how that list gets changed.
• What administrators are permitted to look at, and what they must never look at without consent.
• What gets logged, how long logs and backups are kept, and where the offsite copy lives.
• How a member deletes their account and takes their data with them.
• How a moderation or suspension decision is appealed, and to whom.
• What happens to the data and the hardware if the group dissolves.

Name at least three key holders. Two is a coin flip; one is a countdown. Separate routine operations, which one person should be able to do at midnight without calling a meeting, from constitutional changes, which should require a real vote. If your group needs votes that members can verify rather than simply trust, verifiable voting software such as Folkmoot exists for exactly that gap.

Paying for It Without a Corporate Sponsor

Community infrastructure has five recurring costs: hardware that eventually dies, bandwidth or transit, electricity, domains and certificates, and offsite backup storage. Then there is a sixth cost, labor, and it is almost always the largest. Volunteer hours are not free simply because nobody invoices for them.

Funding models that work in practice include member dues on a sliding scale, a municipal line item, fiscal sponsorship through an existing nonprofit, grants, and paid service contracts with local organizations that subsidize the free tier for everyone else. Most durable projects use two or three rather than betting on one.

One warning worth stating plainly: grants love to buy hardware and hate to fund maintenance. It is far easier to raise money for a new mesh deployment than for the fourth year of keeping it patched. Budget the boring years first, and treat a grant that only covers capital as a partial win rather than a plan.

Publish the numbers to members once a year, even when the numbers are small. Financial opacity kills community projects faster than technical problems do.

A Starting Stack Made of Real Software

None of this requires custom code. A community stack is assembled from mature, boring, well-documented free software running on Linux, usually in Docker containers behind a reverse proxy such as Caddy or nginx.

• Files, calendars and shared documents: Nextcloud.
• Accounts and single sign-on: Authentik or Keycloak, so members have one login for everything.
• Chat: Matrix with the Element client, which can also federate with other communities.
• Public posting: Mastodon or Akkoma, joining the wider fediverse instead of starting an island.
• Passwords and shared secrets: Vaultwarden.
• Backups and monitoring: restic or BorgBackup, plus Uptime Kuma so you find out about an outage before your members do.
• Off-grid messaging: Meshtastic running on LoRa radios.

Pick one service that solves an annoyance people already complain about, and ship only that. A shared calendar that actually works beats a half-finished platform every time. If your members are trying to move off Google in particular, the sequence in degoogle your life step by step maps well onto a group rollout.

Single sign-on is the highest-leverage second step. Once one login works everywhere, adding a third and fourth service stops feeling like starting over each time.

What Community Sovereignty Is Genuinely Bad At

An honest page has to say where this loses. Groups that pretend otherwise tend to collapse loudly.

It is not cheaper in the short run, and may never be cheaper if you count labor honestly. Free software is free to download. Somebody still has to patch it at eleven at night.

Reliability is now yours. Large providers run staffed operations centers. Your community server has whoever answers the phone on a holiday weekend. Tell members that in advance rather than apologizing after the first outage.

Self-hosting moves risk, it does not delete it. An unpatched Nextcloud instance is worse for members’ privacy than a commercial cloud drive, not better. Sovereignty without maintenance is just a slower breach. That tradeoff is covered further in what is data sovereignty.

Sovereignty is not immunity. Your server sits in a jurisdiction. Subpoenas, takedown notices and your upstream provider’s terms all still apply. What changes is that you receive the request and can respond to it, instead of never learning it happened.

A mesh is not an internet connection. Local mesh gives a neighborhood resilient local capacity and communication when infrastructure fails. It does not replace a broadband uplink for streaming video to the wider world.

The most common cause of death, though, is none of the above. It is one person becoming the sysadmin for everybody, getting tired, and quietly stopping.

A Realistic First Year

Sequence matters more than ambition. This ordering leaves the project still worth something if you stop at any step.

1. Months one to three. Decide the legal shape. Write the governance document described above, even if it is only two pages. Find three people willing to hold keys, and say publicly who they are.
2. Months three to six. Stand up exactly one service on one machine. Announce a realistic uptime expectation. Do not add a second service yet.
3. Months six to nine. Add single sign-on, set up backups, and then actually restore from one onto a spare machine. Backups that have never been restored are decoration.
4. Months nine to twelve. Add the second service, publish a plain-language accounting of what the year cost, and run a succession drill where someone other than the founder completes a full maintenance cycle alone.

One rule is worth adopting permanently: never launch a service you have not personally restored from backup at least once. It is the cheapest insurance in this entire field.

More background on the individual pieces mentioned here is collected in the WOPR learn guides.

Frequently asked questions

How many people do you need to start community-owned infrastructure?

Fewer than most groups expect. Three people willing to hold administrator keys and share the maintenance is enough to run a real service for dozens of users. The limiting factor is almost never headcount. It is whether responsibility is genuinely shared or quietly resting on one volunteer who will eventually burn out.

What is the difference between digital sovereignty for a community and for an individual?

Individual sovereignty is a set of personal choices you can reverse alone. Community sovereignty creates obligations to other people: their files, their accounts, their expectations of privacy. That means it needs written governance, named key holders and a succession plan, none of which a personal setup ever requires.

Does running our own servers put a community outside the law?

No. Your hardware sits in a jurisdiction and stays subject to it, including subpoenas, takedown notices and your upstream provider terms of service. The practical change is that legal requests arrive at your door, so your community can see them and decide how to respond, rather than a platform handling them invisibly.

Can a town or city legally run its own network?

It depends heavily on where you are. Several US states restrict or complicate municipal broadband, and the rules differ again for a library district or a co-op. Check your state law and talk to a local attorney before planning a build, because the legal answer often shapes the technical design.

Do we need a mesh network to have digital sovereignty?

No. Mesh addresses the network layer, which is the hardest and most expensive one to own. Plenty of communities get real sovereignty by running their own applications and identity system over rented connectivity, then add local mesh later for resilience rather than treating it as the starting point.

How do we keep this running when the person who built it leaves?

Document the setup while building it, not afterwards. Keep at least three key holders, rotate credentials whenever someone departs, and run a drill where a second person performs a full maintenance cycle alone. If nobody except the founder has ever patched the server, the project already has an expiry date.