Sovereignty in the digital age

what is sovereignty?

Sovereignty, in the traditional sense, is the right of a person or group to govern themselves. In the digital world, it means the same thing, just applied to your infrastructure, your data, and your identity online.

It is not about isolation. It is not about going off-grid or refusing to connect to the world. It is about choosing how you connect, with whom, and on what terms.

A sovereign digital system is one where you understand what is running, why it is running, and who has access to it. You are not a tenant in someone else's infrastructure. You own the stack.

why does this matter?

In early 2024, a developer named Andres Freund noticed something strange. He was benchmarking SSH login times on his Debian system and the numbers were a few hundred milliseconds slower than they should have been. It was the kind of thing most people would have dismissed. He did not.

What he found, after digging through performance traces, was a deliberately planted backdoor inside xz utils, one of the most widely used compression libraries in Linux. xz is the kind of software that almost every Linux system has installed and almost no one thinks about. It is infrastructure. It is invisible. It is trusted by default.

The person who planted the backdoor had spent nearly two years building credibility in the open source community under a false identity, gradually taking on maintainer responsibilities for the project, and then, when the moment was right, slipped malicious code into the build system in a way that was specifically designed to avoid detection in code review. The backdoor targeted OpenSSH on systemd-based systems, and if it had shipped broadly in stable Linux distributions, it would have given an attacker remote access to an enormous number of servers across the internet.

It was caught, barely, by accident, by one person paying close attention to a performance anomaly.

The xz backdoor was not a failure of one project. It was a demonstration of how much of our infrastructure runs on software we do not understand, maintained by people we have never vetted, pulled in automatically as a dependency we never consciously chose.

This is the supply chain problem in its most visceral form. And it raises a direct question: if you are running software you did not choose, cannot audit, and do not understand, are you really in control of your own system?

how sovereignty changes this

A sovereign system does not eliminate supply chain risk entirely. That would be impossible. But it changes your relationship to it in three critical ways.

You know what you are running. A minimal system with a small, intentional set of dependencies has a much smaller surface area for this kind of attack. If xz is not on your system because you never needed it, you were never vulnerable. The best defense against a compromised dependency is not having that dependency.

You can audit what you have. When your system is small enough to understand completely, anomalies become visible. The reason the xz backdoor almost went undetected is that no one was watching xz closely. It was just assumed to be fine. Sovereign infrastructure demands that nothing is assumed to be fine.

You control your update path. Systems that pull in packages automatically from upstream repositories inherit whatever those repositories contain. A sovereign approach means deliberate, reviewed updates. Changes that are understood before they are applied, not ingested because a cron job said to.

The xz story is not an edge case. It is a preview. As the value of compromising shared infrastructure grows, so does the incentive to do it. And the more software you run that you did not consciously choose, the more exposure you carry.

how do we implement sovereignty?

My thinking on this did not arrive all at once. It was gradual: a slow accumulation of moments where I looked at a system I was depending on and realized I did not fully understand what it was doing, or who else had access to it, or what would happen if it disappeared tomorrow. Two examples from very different corners of the industry helped crystallize it.

the signal in what others were building

Take 3CX, an enterprise phone and communications platform. At a certain point, rather than shipping as a package you install on top of whatever Linux system you already had, they moved toward shipping their own purpose-built environment. The system runs 3CX. That is what it does. The underlying OS exists to serve that one function, and nothing else is assumed, inherited, or left to chance.

Then look at Umbrel, which comes from the complete opposite end of the market. Umbrel is a home lab tool, something you would run on a Raspberry Pi or a spare machine to self-host your own apps. And yet they made the same architectural decision: rather than releasing a package for existing Linux distributions, they built their own ISO. Their own image. A system designed from the ground up to do exactly what they needed and nothing more.

Two very different products, two very different audiences, one shared conclusion.

what this looks like in practice

The shift in thinking is this: instead of starting with a general-purpose system and removing what you do not need, you start with nothing and add only what you have decided should be there.

It is a different relationship with software. You are not a tenant inheriting whatever the landlord left behind. You are making deliberate choices about every component, and you can account for all of them.

Sovereignty is a spectrum, not a switch. You do not have to do it all at once. But every step in that direction, every service you understand, every dependency you consciously chose, every component you could explain to someone else, is a step toward a system you actually control.

The goal is not to answer yes to all of these immediately. The goal is to know which ones you are still answering no to, and to make that a conscious decision rather than an accident.

applications of sovereign infrastructure

Sovereign infrastructure is not a luxury tier reserved for the paranoid or the powerful. It is a practical choice that scales from a two-person startup to a national agency, and the tools and the philosophy are the same at every level. What changes is the stakes.

That became concrete for me at Web Summit in Qatar in February 2026, where I met a startup called Gemsoft. They were building self-hosted server and chat solutions, designed to run entirely within a customer's own infrastructure. On the surface it sounded niche. But the range of customers they described made the point better than any abstract argument could: a startup protecting its intellectual property, a law firm that cannot afford a data breach, a healthcare company navigating data residency requirements, a small business that just wants to own its communications without routing everything through a third-party platform. None of them are governments. None of them have nation-state budgets. But all of them have a legitimate need for infrastructure they actually control.

Governments have quietly had this figured out for a long time. Classified networks, air-gapped systems, private communications infrastructure: sovereignty has been a requirement at that level for decades. What Gemsoft represented was the idea that the same principles are now within reach for everyone else.

introducing verity

All of this philosophy needs a concrete starting point. That is what Verity is.

Verity is a template for a sovereign operating system that runs nothing but an nginx web server. Nothing else. No extra daemons, no unnecessary libraries, no services you did not ask for.

the idea

Most server operating systems ship with an enormous amount of software. Package managers, system services, logging agents, scheduled tasks: most of it running quietly in the background, most of it never examined. Verity inverts this assumption.

Instead of starting with everything and removing what you do not need, Verity starts with nothing and adds only what is required: the OS kernel, the bare minimum system libraries, and nginx.

why this matters

The attack surface argument. Every daemon you do not run is one that cannot be exploited. Every library you do not ship is one that cannot have a hidden vulnerability. By reducing the system to its essential components, Verity dramatically reduces the number of things that can go wrong, and the number of things an attacker can target.

Intentionality. Every component in Verity is there because someone decided it should be. That is a different relationship with software than the passive accumulation that happens with a standard general-purpose OS. You can read the entire build. You can understand it completely. That understanding is itself a form of sovereignty.

Reproducibility. A sovereign system should be verifiable. Anyone should be able to take the Verity template, build it from source, and confirm that what is running matches what was declared. This connects to broader ideas in supply chain integrity: if you cannot reproduce your build, you cannot fully trust it.

what verity is not

Verity is not a finished product. It is a template. A starting point for building sovereign infrastructure with intention. It is an answer to the question: what is the minimum viable system for serving content on the web?

It is also not a silver bullet. Sovereignty still requires discipline: keeping software updated, auditing configurations, understanding your network. Verity gives you a clean foundation. What you build on it is up to you.

the broader point

Verity embodies a principle that scales beyond a single web server: you should be able to understand, in full, the system you depend on.

That is not always possible with complex systems. But it should always be the goal. And starting with something as simple and auditable as Verity, a machine that does one thing and nothing else, is a way to practice that discipline, and to build from a foundation you actually trust.

where to go from here

Sovereignty is not a destination. It is a direction. The goal is not to achieve some perfect state of self-sufficiency, but to move consistently toward systems you understand, control, and can trust.

Start with a single server. Understand everything on it. Strip what you do not need. Document what remains. Then expand from there.

Verity is one way to start.