Cover Photo: Pont'Ecciu, 1st century AD Roman bridge, restored and enlarged in 1157 during the period of the Giudicati, Allai, Sardinia. CC-SA 2.0 Carole Raddato
I've spent most of my life trying to understand how information technology and people interact. Technology does what it says on the tin: it transforms people's lives, whether for better or for worse. It's also a proxy for power. When the people who control technological infrastructure are not the same ones who depend on it, more often than not that technology does not serve the interests of those dependents. The intentions of the people who control the technology are of little interest to me. It's the effects of that control that matter.
This series is about how much control I can exercise over my own infrastructure, and the technical, policy, and physical limitations and trade-offs I hit along the way.
I run Linux and Windows. I use Thunderbird and Gmail. I use both Delta Chat and WhatsApp, Mastodon and Bluesky. You get the point. I contribute to and advocate for open source. I've argued publicly that democratic control over technological infrastructure is a precondition for meaningful sovereignty.
The gap between what I advocate and how I actually operate is not unusual. Most people who care about digital autonomy still have dependencies on the same concentrated infrastructure they don't own, or even critique.
I always tinkered with self-hosting. Nothing consistent, but I'd run things, experiment, break them, learn. The instinct was there. But in my early thirties, I moved around a lot. New country, new ISP, new apartment, new priorities. When you're rebuilding your life every year or two, setting up a mail server is not high on the list. "I'll just use Gmail for now" seems like a rational choice when you don't know where you'll be in six months.
Each move eroded another layer of control. First email went to the cloud. Then files. Then calendar, contacts, passwords. Not because I chose to give them up, but because I didn't have the stability to maintain the alternative. The problem is that "for now" has no natural expiration date. Once you're in, the switching cost only grows. More accounts linked to that email. More files in that Drive. More OAuth connections you forgot you granted. Every month you don't migrate is another month you're more locked in.
And the platforms play into that. There's a reason why Microsoft Word documents look terrible on LibreOffice, or why my Nextcloud calendar doesn't sync cleanly with the Mac Calendar app. Incumbents make interoperability painful by design. And once you're locked in, the terms change. Do you want to lose your whole Google Drive, or give Google Gemini access to your data? Your "choice."
By the time life stabilised, my personal infrastructure debt was enormous. And even though I knew it was a lot, I hadn't even realised the full scope of it. When I finally sat down to audit what had built up around me, the scale surprised me. Hundreds of services. Multiple email identities I'd forgotten about. Recovery emails that pointed to each other in a loop. Subscriptions quietly accumulating month after month.
None of it was careless. Each compromise made sense at the time. Settling for the relatively easy choice was a relief when everything else was in flux. But defaults compound quietly, and by the time life stabilised, the dependency graph felt overwhelming. Doing that inventory gave me a starting point. Divide and conquer. I made a systematic plan to migrate my personal infrastructure to a self-hosted, FOSS-first stack. Email, files, calendar, passwords, code hosting. All of it moving to infrastructure I control.
So what does that actually look like? Some of it will run on a VPS. Some will run on hardware in my home. Some I'm genuinely not sure about yet. The architecture decisions will be documented with actual reasoning: threat models, trade-off analysis, and honest assessments of where the self-hosted option is genuinely worse than what it replaces. This time, the concessions will come with a plan B.
I won't always make the optimal choice that reflects who I aspire to be. I'm keeping Spotify for now. My Riot launcher isn't going anywhere. These are *informed, intentional* dependencies rather than *default, unexamined* dependencies. Every proprietary service that remains will be a conscious choice, and shouldn't get too comfy. I might come for it next when I have the energy and time.
Why document this
Self-hosting guides are abundant. What's rarer, I believe, is honest documentation of the decision-making process: why one tool over another, what the real operational costs are, where the pain points live, and what trade-offs feel acceptable.
I've written about how architecture matters more than choices. I'm applying the same to my personal life. Picking Nextcloud or Forgejo is the easy part. Building a stack that you'll actually maintain, one that survives the Wednesday morning where something breaks and Google is one click away, requires thinking about sustainability, not just capability. I'll make some bold choices. I'll make some stupid choices. But if I'm right, the system should tolerate those. That's what I'm trying to demonstrate with this series. I won't be reinventing the wheel here, but rather applying years of learnings systematically.
The migration starts with an inventory: auditing my essential services, devices, and data silos to understand the actual dependency graph before touching anything. Then architecture, resolving structural questions first, because where each service runs and how they connect constrains everything downstream. Then migration, one service at a time. Deploy, test, verify backups, move on. No dramatic exit. Each phase will get documented here, including the reasoning, the journey, and the mistakes. We'll see how it holds up.
---
*This is part of the Autonomous Stack series, documenting my migration from proprietary services to self-hosted infrastructure.
**Previously: Welcome to Do Flamingos Know They're Pink.
Next week: Taking Inventory (stay tuned).*