Own, Control, Rent: A Better Way to Think About Technology Sovereignty

In I Took Self-Hosting Too Far, I ended with a principle that had emerged from reconsidering how much of my own infrastructure I actually needed to operate:

Own what needs to be durable. Control what needs to be portable. Rent what is genuinely replaceable. None of it is free — spend accordingly.

It started as a conclusion about self-hosting, but I think it describes something broader.

We tend to frame technology sourcing as a choice between building and buying, or between self-hosting and SaaS. Those distinctions are useful, but they miss an important question: what kind of relationship do we actually need with a particular capability?

Not everything needs to be owned. Not everything should be outsourced. And perhaps most importantly, using somebody else’s technology does not necessarily mean surrendering control to them.

The useful distinction is between durability, portability, and replaceability.

Own What Needs to Be Durable

Some things need to survive changes in vendors, products, platforms, and technology generations.

Those are the things worth owning.

Ownership here does not necessarily mean writing every line of software yourself or operating every server involved. It means retaining the assets, rights, knowledge, and organizational capability necessary for something to continue existing on your terms.

Data is perhaps the clearest example.

A company might store its data in somebody else’s database, on somebody else’s cloud infrastructure, using software written by somebody else. None of that changes the fact that the data itself, its meaning, its structure, and the organization’s ability to use it must endure beyond those technologies.

The same can be true of domain models, business rules, intellectual property, architecture knowledge, customer relationships, operating procedures, and strategically important software.

A useful test is:

If the supplier disappeared tomorrow, would we still need this five years from now?

If the answer is yes, ownership deserves serious consideration.

This was part of the reasoning behind keeping my repositories under my own roof in the earlier self-hosting discussion. A repository is not merely a collection of source files. It contains history, issues, releases, and increasingly the workflow around producing the software. I did not want the canonical identity of that repository to depend on whichever SaaS platform happened to host it at the time.

Durability is fundamentally about continuity.

The things that constitute the long-term memory, identity, and intellectual capital of an organization should not accidentally become temporary because the technology carrying them is temporary.

Control What Needs to Be Portable

The second category is more subtle.

There are many things we do not need to own, but we cannot afford to become trapped inside.

We probably do not need to own a database engine, operating system, programming language, cloud platform, container runtime, or observability system. In many cases, trying to do so would be absurd.

What matters is maintaining enough control over how we use them that we can move when circumstances change.

That control can come from many places: open standards, documented interfaces, exportable data, open-source software, infrastructure as code, portable deployment models, contractual rights, or simply retaining sufficient knowledge inside the organization to replace one implementation with another.

The objective should not be complete independence.

Almost every useful technology creates dependencies. Eliminating dependency entirely would mean building virtually everything ourselves, which would leave little time for doing anything that actually differentiates the business.

The more practical objective is credible exit.

We should be able to say:

We choose to use this technology today, but the decision remains ours tomorrow.

That is a very different relationship from lock-in.

A dependency is not inherently a problem. An irreversible dependency can be.

This is also why owning the boundary can sometimes matter more than owning the implementation behind it.

A domain is a good example. If I own the domain through which people reach a service, I can replace the infrastructure behind that domain without asking users to change where they go. In the self-hosting example, that distinction became central: the domain remains mine regardless of whether the files behind it are served from my own machine, Cloudflare, or something else.

The same logic scales up. An enterprise almost certainly should not own a container platform, but it can decide what its applications are allowed to depend on: an explicit platform contract covering how workloads are packaged, configured, exposed, observed, and given an identity. Applications written against that contract can move between clusters, providers, and platform generations, because what they actually depend on is the contract rather than any particular provider’s implementation of it. Nobody owns Kubernetes in that arrangement, and nobody is trapped by it either.

Portability is therefore fundamentally about optionality.

You do not necessarily need to operate something yourself. You need to preserve the ability to change who does.

Rent What Is Genuinely Replaceable

Then there are capabilities where neither ownership nor extensive control provides much strategic value.

Rent them.

Static file hosting was what forced me to confront this distinction.

I had designed an architecture in which the repository, CI pipeline, build process, and web server would all run on infrastructure I operate myself. It was coherent from a sovereignty perspective, but it also meant operating another public service: deployment, availability, TLS, caching, monitoring, updates, and everything else that comes with keeping an endpoint healthy.

Cloudflare could do that part considerably better, and more importantly, it could do so without controlling the parts I actually cared about.

The repository could remain on my Forgejo instance. CI could keep running on my own infrastructure. The site could be built there. Only the finished artifact needed to be handed to Cloudflare for distribution — a deployment step at the end of a pipeline I own, rather than a platform the pipeline has to live inside.

That changed the nature of the dependency.

If Cloudflare disappeared tomorrow, I would not lose the repository. I would not lose the pipeline. I would not lose the ability to build the site. I would need another place to serve a directory of static files and would change the final deployment step accordingly.

That is a dependency I am perfectly comfortable renting.

But the word genuinely matters.

Something is not genuinely replaceable simply because procurement can identify three competing suppliers. You have to look at the dependency that accumulates around the service, which is rarely visible in the contract.

Where is the data? How proprietary are the APIs? How many integrations depend on it? What operational knowledge has accumulated around the product? How difficult would migration actually be? What contractual restrictions exist? How much of the surrounding architecture assumes this particular implementation?

A SaaS application that would take five years to disentangle from is not meaningfully rented.

You may pay for it through a subscription, but architecturally you have acquired a long-term dependency.

Replaceability is therefore fundamentally about commoditization.

If a capability can genuinely be substituted without threatening the business, there is little reason to reproduce a supplier’s economies of scale internally.

This Is Not Build Versus Buy

That leads to a different way of thinking about technology strategy. The traditional question is usually whether we should build something or buy it, and I think that question arrives too early: it reaches for a sourcing mechanism before anyone has established what the capability actually has to do for us over time.

The question that belongs first is:

What relationship do we need with this capability?

Does it need to endure?

Does it need to move?

Can it safely be replaced?

Only once those are answered does build-versus-buy become a sensible question to ask, and the resulting model is simple:

These categories can coexist within the same architecture.

You might own your domain model and business data, control your application architecture by building around portable technologies and interfaces, and rent the compute, storage, networking, and content distribution underneath it.

There is no contradiction in that.

In fact, that combination may provide considerably more sovereignty than simply self-hosting everything.

Sovereignty Is Not the Same as Self-Hosting

This was the mistake behind my earlier reasoning.

I had started treating self-hosting as the objective rather than as one possible mechanism for achieving control.

But operating infrastructure does not automatically create sovereignty.

You can self-host an application while being completely dependent on proprietary formats, obscure technology, a single vendor, or knowledge held by one person.

Conversely, you can consume a managed service while retaining excellent portability if you own the important data, interfaces, identities, and deployment boundaries.

The relevant question is therefore not whether we operate something. It is:

What happens if we need to leave?

That question exposes the real architecture of dependency.

If leaving means changing a configuration value, modifying a deployment step, and pointing DNS somewhere else, the dependency is probably healthy.

If leaving means rewriting the application, migrating years of inaccessible data, changing customer-facing identities, retraining the organization, and redesigning half the surrounding architecture, it probably is not.

This is why I wrote in the original post that the goal is not to own infrastructure, but to own the things that would be painful to lose.

Every Relationship Has a Cost

There is another side to this. None of the three relationships are free: each carries a cost, and choosing a different relationship only changes its shape — it does not make the cost disappear.

Owning costs attention.

Ownership is not a decision made once. Retaining the assets, rights, knowledge, and organizational capability it requires means someone has to keep understanding them, years after the original decision was made. A domain model nobody remembers the reasoning behind, or a repository whose history nobody reads, is not really owned anymore — it has quietly become custody instead. Ownership decays into that without continuous attention, and the attention has to come from somewhere.

Controlling costs the discount you did not take.

Preserving a credible exit usually means choosing the more generic, more standard option over the one built specifically for your situation, and paying for that restraint whether or not you ever leave. Maintaining portable interfaces, avoiding proprietary shortcuts, documenting the migration path, and actually testing that an export works are ongoing costs paid for an option that may never get exercised. That is not a reason to skip them — it is a reason to be honest that “we could leave if we wanted to” is a maintained capability, not a free side effect of using open standards.

Renting costs the discipline to keep checking.

Renting looks cheapest because the invoice is the only visible line item. The real cost shows up later, and only if nobody keeps checking: a genuinely replaceable service quietly accumulates data, integrations, and operational knowledge until it stops being replaceable, and the subscription fee was never the actual price being paid. Renting stays cheap for exactly as long as somebody keeps verifying that “genuinely” is still true — which is itself an ongoing cost, not a one-time judgment.

So maximizing independence everywhere is not good architecture, any more than self-hosting everything was.

For a small organization in particular, every service operated internally is another service somebody must understand, configure, monitor, update, troubleshoot, and eventually migrate or replace. That operational cost was one of the main reasons I reconsidered self-hosting the static sites in the first place.

The goal should therefore not be maximum sovereignty. It should be deliberate sovereignty: spending ownership where ownership matters, spending portability where future choice matters, and accepting dependency where the consequences of that dependency are small.

Preserve Freedom Where Freedom Matters

That, ultimately, is what I think the principle is about.

It is less a rule for technology procurement than a way of deciding where an organization chooses to place dependency.

Own where losing ownership would threaten your future.

Control where losing the ability to move would constrain your future.

Rent where neither matters enough to justify the cost.

Or, in its shorter form:

Own what needs to be durable. Control what needs to be portable. Rent what is genuinely replaceable. None of it is free — spend accordingly.

The important part is that none of these classifications are permanent. Something genuinely replaceable today can gradually become deeply embedded in an organization, accumulating data, integrations, processes, and organizational dependencies until replacing it becomes enormously difficult. The reverse happens too: something strategically important today can be an ordinary commodity five years from now.

So the boundaries need revisiting, and the questions worth revisiting them with are not whether we are pro-cloud or pro-self-hosting, whether we build or buy, or whether we prefer open source or commercial software.

Those are implementation choices.

The durable questions are:

What must endure?

Where must we preserve the freedom to move?

And where are we comfortable depending on somebody else?

Answer those well, and the sourcing decisions become considerably easier.