Insights · Managed Services
Sovereign Infrastructure: Why We Run Our Own Cloud
Running your own infrastructure end to end is a credible enterprise posture, not a hobby. Here is the case for sovereignty-first IT and the trade-offs we accept to get it.
Most companies rent their foundation. Someone else owns the hypervisor, the control plane, the registry, and — increasingly — the pricing power. That works right up until it doesn’t: a vendor reprices, an account gets locked, a “managed” dependency turns into an outage you cannot debug because you cannot see inside it.
Davenport took the opposite bet. We run our own virtualization, our own Kubernetes, our own container registry, and our own network edge. Nothing critical leaves the building except a short, deliberate list of sanctioned externals. We call this posture sovereignty-first, and we think it is a credible enterprise strategy rather than a nostalgia trip to on-prem.
What sovereignty actually means
Sovereignty is not “no cloud.” It is deliberate dependency. For every layer of the stack we ask a single question: if this provider disappeared tomorrow, or doubled its price, or decided our workload violated a policy we never agreed to — what happens to us? Where the answer is “we’re fine, we own it,” we own it. Where a managed service genuinely buys us something we cannot reproduce, we use it consciously and we keep the exit cheap.
In practice that gives us three rules:
- Local by default. Compute, storage, and orchestration run on hardware we control. The default answer to “where does this run?” is “here.”
- A short, audited egress list. A small number of external endpoints are sanctioned and written down. Adding to that list is a governed decision, not a default that accretes silently.
- Own the registry, own the supply chain. Every custom image we run is built by us, scanned by us, and pulled from a registry we operate — on pinned, immutable tags. The thing running in production is the thing we built.
The substrate
Underneath everything is a virtualization platform running on clustered enterprise hardware, with redundant storage pooled across nodes. On top of that we run Kubernetes for the workloads that want it and lighter dedicated clusters for workloads that should not share a blast radius with anything else. The point of the two-tier shape is isolation by design: a research workload that experiments aggressively does not get to take down a production voice platform, because they do not live on the same cluster.
A sovereign container registry sits at the center of the supply chain. Images are scanned for vulnerabilities on push, access is role-scoped, and clusters pull over internally-trusted TLS. There is no path where an unreviewed image from the public internet lands in production by accident.
The trade-offs we accept
Sovereignty is not free, and pretending otherwise is how on-prem projects fail.
- We own the pager. When storage degrades or a node misbehaves, there is no support contract to escalate to — there is us. We accept that because the same property is what lets us actually fix things instead of waiting on someone who cannot see our system.
- We move deliberately on the edge. Exposing anything to the public internet is a governed decision with an approval gate in front of it. That is slower than clicking “make public,” and that is the point.
- We do our own capacity planning. No elastic autoscaler hides a sizing mistake. We plan headroom, and we measure it.
Why it’s worth it
What we get in return is a system we can read all the way down. Every layer is inspectable, every dependency is chosen, and no vendor decision can quietly become our outage or our bill. For a company whose entire model is running multiple independent ventures on one shared foundation, that auditability is not a luxury — it is the product.
Sovereign infrastructure is a posture, not a purchase. It is the discipline of knowing exactly what you depend on, and being able to prove it.
sovereigntyinfrastructurekubernetesstrategy