The Invisible Infrastructure: Power and Labor in Decentralized Networks

I’ve deployed and nurtured more nonprofit websites than I can count. Most of them were small, well-meaning projects — a WordPress instance here, a Drupal site there. A few years ago, though, I decided to get clever.

“If we’re going to do this,” I thought, “let’s do it right.”

So I spun up containers, pushed them into ECS, wrote Terraform scripts to manage the infrastructure. It was elegant — maybe even beautiful — and, from the outside, it looked effortless. The sites just ran. Updates deployed cleanly, backups were automated, uptime was rock-solid.

And I’d accidentally turned myself into a single point of failure.

The nonprofits didn’t know what Docker was, let alone how to debug a failing container or interpret a Terraform error. To them, the infrastructure was invisible — and perfect. Until I walked away. Then it wasn’t invisible anymore. It was terrifying.

That’s the thing about so-called “horizontal” or “decentralized” systems: they’re never actually flat. The infrastructure that keeps them running is full of quiet hierarchies, invisible labor, and hidden dependencies — and unless those dynamics are surfaced and supported, they have a way of collapsing when you need them most.

The Myth of Neutral Infrastructure

We like to tell ourselves that decentralized systems are inherently egalitarian. No bosses, no single points of control, just networks of peers. It sounds great until you realize that even the simplest infrastructure carries technical and social weight.

I’ve seen it in every project: the moment the servers are up, someone becomes the admin. Not because they wanted the role, but because they’re the one who knows where the SSL certificates live, or how to restart the database when it falls over, or what to do when the site gets flooded with spam.

Infrastructure is never neutral. It encodes power — sometimes subtly, sometimes painfully.

Quiet Hierarchies of Expertise

Another nonprofit ran Jenkins for automated build tasks. It was one of those “set it up now and lock it down later” situations from some time past where picking two from "good, fast, and cheap" always involved "cheap." Twice.

SSH open to 0.0.0.0. Password authentication enabled.

While investigating a redline CPU, we discovered that the server was compromised. Someone — or, more accurately, some bot — turned it into a cryptominer. The machine sat there for weeks, running hot, before anyone noticed.

Suddenly, I was the de facto security team. Not because I was on staff, not because I’d volunteered — but because I was the only one who understood enough to clean it up.

That’s how quiet hierarchies form. The person who can decipher logs or patch a firewall becomes indispensable, whether they want to be or not. And once you’re indispensable, you’re also stuck.

These dynamics aren’t just technical. They intersect with class, with education, with gender. Who gets called an “expert” — and who gets quietly sidelined in conversations about infrastructure — isn’t random. It’s shaped by who had the time and opportunity to learn, by who feels comfortable asking “dumb” questions, by who’s allowed to say no when the pager starts buzzing.

The Labor Problem

The labor of keeping decentralized systems alive is almost always invisible — until something breaks.

That first WordPress site I built? It started as a weekend project. Then came the plugin updates. The database optimizations. The backups. The spam filtering. The late-night texts when the site went down because someone pasted raw HTML into the editor.

Suddenly, my “quick favor” had turned into a part-time job — unpaid, unacknowledged, and absolutely essential.

Or take the nonprofit that ran its Drupal site on local servers. During Drupalgeddon, automated scripts exploited an unpatched vulnerability, took over the server, and installed a cryptominer. The breach didn’t just tank performance — it happened during their annual fundraiser. Their donation portal went down in the middle of the campaign. The cleanup cost more than they’d saved by self-hosting, and the reputational hit lingered for months.

This is the reality of invisible infrastructure: when it works, no one notices. When it fails, everyone does.

Hybrid Strategies and Tactical Trade-Offs

After a few years of living through this cycle, you start to see why organizations adopt hybrid strategies.

The Tech Workers Coalition, for example, uses Slack for coordination, Signal for secure discussions, and a lightweight, self-hosted wiki for documentation. Mutual aid networks during COVID paired Google Sheets with Signal and Airtable because they needed speed and reliability, not architectural purity.

In Hong Kong during the 2019 protests, organizers used Telegram for rapid broadcast, but fell back on AirDrop and peer-to-peer mesh apps when networks went down or surveillance intensified.

These aren’t failures of decentralization. They’re lessons learned. They’re organizations recognizing that complexity without capacity is a trap as much as a lack of organizational resiliency — and that often means choosing the tool that’s “good enough” rather than the one that’s “technically perfect.”

Rethinking Dependency

Recently, I was evaluating Amazon’s Bedrock for an organization exploring AI integrations. It seemed like the obvious move — flexible, powerful, enterprise-ready. Then someone asked:

“Can’t we just use NotebookLM instead?”

At first, I bristled. Bedrock was the serious option. NotebookLM was simple, limited, tied to a personal Google account. But the question was right. What were we optimizing for?

Bedrock meant autonomy, but it also meant ongoing maintenance and technical expertise the organization didn’t have. NotebookLM meant lock-in and privacy concerns — but it also meant zero setup time and an interface staff could start using immediately (although someone higher up had to sign off on what they could and must not upload to a personal account).

That’s the thing about dependencies: they’re not inherently bad. What matters is intentionality — knowing what you’re trading away, and building processes to manage those trade-offs over time.

The danger isn’t in relying on Google, or AWS, or Slack. It’s in doing it accidentally, without documentation, without redundancy, without a plan for what happens when the person holding the keys leaves or the platform changes its terms overnight.

Beyond Technical Fixes

None of this is just a technical problem. It’s cultural. It’s organizational.

You can spin up the most elegant, decentralized infrastructure in the world — but if the labor to maintain it isn’t recognized, supported, and distributed, you’ve built a system designed to fail.

That means budgeting for maintenance: not just in the limited dollars you have, but in person-hours and in-house upskilling. Writing down the boring stuff — passwords, runbooks, exit plans. Cross-training staff so knowledge isn’t trapped in one brain. Building redundancy into your human systems, not just your technical ones.

Toward Equitable Infrastructure

The WordPress sites, the Jenkins server, the Drupalgeddon fundraiser — they’re not just stories about bad luck or human error. They’re reminders that autonomy without support is fragility.

Resilient networks don’t eliminate power. They surface it. They make expertise visible, distribute it intentionally, and build the cultural habits and organizational scaffolding to sustain it.

Infrastructure will always be invisible until it isn’t. The question isn’t whether you can build systems that never fail — you can’t. The question is whether you can build systems where failure doesn’t mean collapse, where no one person becomes the irreplaceable hero keeping the lights on.

True decentralization isn’t about servers or protocols or tools. It’s about sharing the labor that keeps the network alive.