I started self-hosting seriously around 2015, then mostly stopped between about 2018 and 2024 because reliability won out. Hosted services were easier to operate, easier to recover, and required much less attention.
That experience changed how I think about digital sovereignty. I no longer see it as a question of whether everything should run on hardware I own. The more useful question is whether I can leave a service when I need to: can I move the data, replace the provider, and rebuild the service somewhere else?
That is what sovereignty means to me now.
The cloud won for good reasons
Self-hosting provides control, but it also means owning the operational burden: hardware, power, storage, backups, patching, monitoring, certificates, networking, failed drives, and recovery.
Power has become a more important constraint for me than it was when I started. Old hardware can be inexpensive to acquire but relatively expensive to leave running indefinitely, especially once storage and AI workloads are involved.
My own setup uses a mixture of older SATA storage, SSDs, local model storage, caches, and development data. It works, but it also reinforces the point that local ownership is not automatically the best answer. Sometimes renting the service is the sensible thing to do.
I take a similar approach to storage. Nextcloud covers a large part of what I need from consumer cloud storage, but local capacity is only useful if recovery works. Important data still needs another copy somewhere else. Self-hosting without off-site recovery is just a different kind of dependency.
Email is a good example
Email cured me of a lot of self-hosting enthusiasm. Running an SMTP server is easy enough; running one that reliably delivers mail to Gmail, Outlook, corporate gateways, and telecom systems is not. Reputation, DKIM, SPF, DMARC, blocklists, spam filtering, backups, and availability all become operational responsibilities.
Earlier in my career I worked at LinuxMagic, which provides email infrastructure for ISP and telecom environments, so I had some exposure to what sits behind something most people experience simply as an inbox.
For critical email, I would rather pay somebody who is good at operating it. Proton is one option I like. It is Swiss rather than Canadian, but that still provides useful diversification from the large American platforms. ISP mail can also be a reasonable, deliberately boring alternative.
The important part is not that every service be Canadian or self-hosted. It is that no single provider becomes impossible to replace.
DNS and regulation both help
I currently use Cloudflare for DNS because it is reliable and convenient, although I could also run an authoritative BIND server myself. What matters more is that I control the domain, which gives me a stable interface while the infrastructure behind it changes.
Moving a stateful service is obviously more involved than changing a DNS record. Databases, certificates, authentication, replication, and queues may all be involved. Still, keeping the name independent of the machine lowers the cost of moving.
There is a legal version of the same idea. The GDPR established stronger rights around portability and erasure in many circumstances. Those rights are not absolute, but the principle is useful: export should work, deletion should work, and migration should be possible.
An exit is stronger when it is supported both technically and legally.
Git is technically sovereign and socially centralized
Git is almost ideal for sovereignty because the repository itself is distributed. I can run Forgejo, keep mirrors, and move repositories without changing the underlying version-control model.
The complication is GitHub. It has become part of the software industry’s public infrastructure: recruiters look at profiles, open-source projects live there, and issues, releases, CI, and project history accumulate there. I do not see much value in abandoning it for public work.
I think of GitHub as the public storefront while keeping the repository itself portable. An independent Forgejo instance can remain a mirror or alternate origin, and emerging Canadian projects such as CanForge may eventually provide another option. Connexxia currently presents CanForge as part of its upcoming Sovereign One stack, so I see it as promising rather than a mature replacement today.
The point is not to avoid GitHub. It is to avoid making GitHub the only place the work can exist.
Rebuildability matters
My current home infrastructure is centred around a machine I call Dubnium. The hardware itself is not especially important. I started with relatively inexpensive parts, and I expect the machine to change as the workloads grow. GPUs will change, storage will change, and the host may eventually become several machines.
That is exactly why I care about declarative configuration. A lot of Dubnium is described with NixOS, so the useful asset is less the current box than the ability to reproduce its behaviour on different hardware. The goal is for Dubnium’s hardware to evolve without making the current machine itself part of the architecture.
I think of sovereignty in four layers:
That same approach works for smaller services. Scheduled jobs, automation, CI runners, small APIs, file storage, and remote-administration tooling are all reasonable candidates to bring home when the operating cost is low enough. Self-hosted CI is a good example: GitHub can remain the public control plane while some execution happens on infrastructure I own.
AI is harder
AI is probably the hardest dependency for me to reduce. I run models locally on Dubnium, and they are useful, but they are not always competitive with the strongest hosted models. Giving up frontier models entirely would still carry a real productivity cost, so I treat local inference as one execution option rather than a complete replacement.
The architecture I prefer is a supervisor/specialist model, which I have also been exploring in the Dubnium orchestration design:
The boxes describe roles, not vendors. The supervisor might use OpenAI today, Anthropic tomorrow, Cohere, Augure, or eventually a local model. A specialist for coding, RAG, MIDI, or document processing can also be local or hosted depending on cost, capability, privacy, and latency.
A smaller specialist model may be cheaper, faster, or simply better suited to a narrow task than the general model coordinating the work. More importantly, switching the supervisor does not require replacing the rest of the system. That is a more practical form of AI sovereignty for me than insisting everything must run locally.
I am also exploring Polar Grid, loosely comparable to SETI@home for AI: spare GPUs contributed to a shared inference network rather than all compute being concentrated inside a few providers. There are hard problems around privacy, trust, verification, model distribution, latency, and malicious nodes, so I do not treat that as a solved alternative. It is another possible execution target for specialist workloads.
Location is not the same as control
A Canadian data centre is useful, but it does not automatically mean Canadian sovereignty. A foreign company can operate servers in Canada and keep the data physically here. That solves a residency problem, but it does not necessarily solve a control problem.
Under normal conditions, contracts and privacy rules matter. Under abnormal conditions, including sanctions, emergency powers, or war, practical control can matter more than residency. The server being in Toronto does not change who ultimately controls the company.
| Question | Concern |
|---|---|
| Where is the data? | Residency |
| Who can ultimately control it? | Sovereignty |
For ordinary workloads, residency may be enough. For infrastructure that needs to remain available through geopolitical disruption, local storage without local control may not be enough.
The same reasoning applies to network access. I use Tailscale today because it works very well, while keeping the underlying system portable enough that I could move toward self-hosted NetBird, plain WireGuard, or another control plane if necessary.
I am also interested in a simple policy switch for public infrastructure:
| Mode | Purpose |
|---|---|
| Global | Normal public access |
| Canada only | Coarse geographic reduction of exposed surface |
| Private only | Administrative or private-mesh access only |
A Canada-only mode would be a coarse firewall policy, not authentication. GeoIP is too imprecise for identity, but the mode could still reduce exposed network surface and provide a contingency control that belongs to infrastructure I operate rather than to a VPN or cloud provider.
Consumer technology is harder
Phones are one of the more difficult areas. BlackBerry is gone, and some European Linux phones are appealing, but Apple makes very good hardware and Google provides very useful services. There is no real value in pretending those ecosystems are easy to replace.
Not every category needs a perfect sovereign replacement. The practical goal is to know which dependencies matter, which ones are acceptable, and which ones I need a credible exit from.
Where I ended up
My first period of self-hosting was mostly about ownership. Then I moved away from it because reliability mattered more. Now I care more about optionality.
I want data I can move, backups I can restore, machines I can rebuild, domains I control, services behind interfaces I can replace, AI roles I can move between providers, and network policies I can change myself.
I will self-host where that makes sense and use commercial services where they are better at the job, including American services when they are genuinely the best option. The important part is making sure convenience does not quietly become dependence.