Sovereignty Is Having an Exit

Part I of After Scarcity, Before Sovereignty: Sovereignty Is Having an Exit, What If Work Became Optional?, and Globalization and the Problem of Exit.

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, but an address tied to an internet provider is harder to take with me when I switch providers. Using an address on a domain I control lets me move mail hosting without asking everyone to learn a new address.

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 Canadian projects such as CanForge now provide another option. Connexxia describes CanForge as Forgejo-based sovereign Git, CI/CD, and container-registry infrastructure within its Sovereign One stack. Its broader builder and marketplace are still being rolled out, so I would treat the surrounding platform separately from the underlying Git hosting capability.

A Git mirror preserves the repository and its history, including tracked CI workflow files, but not the whole forge. Issues, access permissions, CI secrets, runners, release assets, and project metadata need separate exports, backups, or a migration plan. A portable repository is necessary, but it is not a complete recovery strategy.

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. Declarative configuration is a starting point, not proof of recovery: periodically restoring data and bringing a service up on another machine or provider is how I can test whether an exit actually works.

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 interested in moving more of my current ChatGPT usage toward Augure, but that migration exposes an important limit to the idea of provider portability. Replacing an API endpoint is much easier than replacing an integrated product.

Model quality is one part of that. Augure provides its own Canadian-hosted models and an OpenAI-compatible API, which makes experimentation comparatively cheap, but compatibility at the protocol level does not guarantee equivalent reasoning quality across the work I actually do. Coding, architecture review, research, long-context synthesis, and agentic tool use all need to be evaluated against representative tasks rather than assumed from a model label or benchmark.

The product ecosystem is at least as important. ChatGPT is useful to me not only because of the model, but because it can work across services such as Gmail, Google Calendar, and GitHub in the same environment. I have not yet found documented Augure equivalents for those integrations. Recreating them myself would move some dependency from the model provider back into my own infrastructure, but it would also create engineering, authentication, authorization, maintenance, and security work that the hosted product currently absorbs.

That makes this a migration rather than a switch. I can move bounded workloads first, especially ones that already pass through my own supervisor or an OpenAI-compatible API, while retaining ChatGPT where model quality or integrated tooling still provides a meaningful advantage. The sovereign outcome is not that every workload ends up with a Canadian provider. It is that those dependencies become visible, testable, and progressively easier to replace.

Sovereignty can exist at more than one scale

One thing Dubnium has made clearer to me is that sovereignty does not have to mean one person operating every service alone.

At the personal scale, Dubnium is a rebuildable workstation and AI control plane. More and more, I care about the boundaries inside it rather than local ownership for its own sake: model access is separated from host effects, authorization is separated from execution, and credentials can stay with the smallest component that actually needs them.

That changes the question from “is this local?” to “who is allowed to do what, where can the workload move, and what survives when one dependency disappears?”

There is also a useful community scale between a personal workstation and a hyperscale provider. Vancouver’s Z-Space Local AI Collective is an early place-based example: members pool resources to operate locally hosted AI infrastructure, access models through a shared gateway, experiment with community knowledge systems, and keep inference in Vancouver. It is still a prototype rather than proof that every governance or security problem is solved, but the model matters. Shared infrastructure can be locally operated without requiring every participant to own a GPU server.

I am also exploring a complementary model I call Polar Grid. Instead of concentrating the shared hardware in one place, participants could contribute spare GPUs to a distributed inference network, loosely comparable to SETI@home for AI. That introduces harder questions around privacy, trust, verification, model distribution, latency, and malicious nodes, so I do not treat it as a solved architecture. But it extends the same sovereignty idea: community compute can be federated as well as co-located.

That suggests a spectrum rather than a binary choice:

The sovereign property is not the box on the left. It is the ability to choose the appropriate scale for a workload without surrendering the ability to move again later.

There is a national ecosystem dimension too. The Linux Association of Canada lists open-source procurement, open standards, and digital sovereignty among its government-relations objectives. In September 2026 it also reported more than 5,300 downloads from its Canadian open-source software library. A download count is not proof of sovereignty, but it does show practical use of a Canadian open-source ecosystem alongside the policy discussion. Open-source software can contribute to sovereignty because source availability and open standards can make systems easier to inspect, reproduce, and move, but those properties still depend on licensing, documentation, data portability, and operational capability.

Credentials are part of sovereignty

There is another sovereignty benefit to keeping the AI control plane local: credentials can stay out of places that do not need them.

Desktop Commander is a concrete example. Its bounded project container can work inside a mount such as /home/ryjen/Projects: inspect a repository, edit files, run repository-defined tests, and prepare a candidate change. That local filesystem authority does not mean the container should also inherit my interactive SSH agent, private keys, broad GitHub tokens, or host-control sockets.

The next step in Dubnium is to separate local repository mutation from remote repository authority:

The useful security property is that the model and the project container do not need the effective remote credential. In that design, a push, pull-request mutation, issue update, merge, or other consequential remote operation would be performed by a narrow host-side worker using an exact repository identity and a short-lived, repo-scoped credential. The credential would never have to enter the model context, the project worktree, the container environment, or a forwarded SSH_AUTH_SOCK.

That makes the local Supervisor Gateway useful even when the selected model is hosted elsewhere. The sovereignty comes from keeping model selection, execution, authorization, and credential custody as separate replaceable boundaries. Changing the model provider should not silently change who can mutate a repository.

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.

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.

A current Dubnium provider-qualification thread uses Augure as a concrete test case. A Canadian AI provider can improve residency and jurisdictional fit, but “Canadian” is not sufficient evidence by itself. Inference location, retention, subprocessors, cross-border failover, and contractual guarantees still have to be checked.

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.

Network access is another exit

VPNs fit the same principle because access is a dependency too. A private VPN lets me administer services without exposing every service publicly. A commercial browsing VPN changes the network carrying my traffic and the operator I trust; neither gives me control over the destination service.

Tailscale encrypts device-to-device traffic, while its hosted coordination service helps devices discover each other and manage identity and policy. Established connections can often continue through a coordination outage, but onboarding, key changes, policy updates, and some reconnection paths still depend on that service. For sovereignty, the test is whether I can replace the coordination dependency or recover access another way—not just whether the traffic is encrypted.

I am also interested in a simple policy switch for public infrastructure:

A Canada-only mode would be a coarse firewall policy, not authentication. GeoIP sees the apparent source of a connection, not where the person is: someone outside Canada could use a Canadian VPN exit or a compromised Canadian host. It 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.

Disconnected communication is another exit

The internet itself is also a dependency.

I have been thinking about Meshtastic as a fallback communications layer. It can carry low-bandwidth traffic over LoRa without cell towers or an internet connection, including encrypted channel traffic when the participants share the appropriate keys.

Meshtastic now publishes packages for OpenWrt-supported routers. The package does not turn an ordinary Wi-Fi router into a LoRa radio; the Linux host still needs compatible LoRa hardware. But an OpenWrt node with a radio could bridge local Wi-Fi or Ethernet services to a low-bandwidth mesh.

LoRa airtime is scarce, so this is not a replacement internet. “Large message” here means something larger than a single mesh packet, not bulk file transfer. The interesting property is that the message can survive intermittent connectivity and arrive in pieces without losing its identity.

Meshtastic is already experimenting with some of those primitives. Its Store & Forward++ port is specifically described for Native Linux nodes as providing a “Git-style chain of messages.” The current protobuf defines message, commit, and root hashes, chain queries and link requests, plus first-half and second-half fragment messages. That is useful precedent, but it is not yet a general large-object transport.

For a larger distributed message, I would put another layer above the radio:

The manifest could identify the author, ordering, chunk hashes, expiry, and perhaps an erasure-coding profile. Nodes would forward pieces opportunistically; the recipient could verify the reconstructed object without trusting any individual relay.

The useful idea from blockchains is not mining or global consensus. It is cryptographic linkage: hashes make substitution visible and a signed root binds the pieces to one object and author. Content addressing can also deduplicate pieces. A Merkle DAG or hash-linked log is a better fit here than a conventional blockchain.

The IETF Bundle Protocol provides the mature precedent: a delay-tolerant, store-carry-forward overlay for intermittent links with fragmentation and reassembly. Meshtastic could be one constrained transport underneath that architecture.

As a sovereignty property, the appeal is graceful degradation: communication can fall back from the global internet, to local IP, to low-bandwidth radio, while message identity and integrity remain stable.

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.

Some dependencies are much harder to replace than others. Phones are an obvious example: Apple and Google provide capable ecosystems, while alternatives still involve meaningful trade-offs. Not every category needs a perfect sovereign replacement; I mainly need to know which dependencies are acceptable and which ones require a credible exit.

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, credentials held only where they are needed, and communications that can degrade gracefully when ordinary infrastructure disappears.

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.