Skip to content
Stribog

§00/The Thesis

Sovereignty is an engineering discipline, not a slogan.

The infrastructure decisions you make in the next eighteen months will constrain your options for the next decade. This page explains what we mean by sovereignty, why the macro shift makes it urgent, and how we practice it.

§01/Why Sovereignty, Why Now

The concentration risk is structural, not cyclical.

Three hyperscalers now carry the compute, storage, networking, AI inference, and identity layers for the majority of the global economy. That is not a market — it is a single point of failure with a billing dashboard on top.

AWS, Azure, and GCP collectively account for more than 65 percent of global cloud infrastructure revenue. When a single availability zone event at one provider cascades into outages across thousands of independent companies — including their competitors' monitoring tools and incident-management platforms — the dependency graph is no longer a vendor relationship. It is a systemic risk that your board's risk committee should treat the same way a bank treats counterparty concentration.

Egress economics compound this. A workload that ingests 10 TB/day from a managed database, a hosted vector store, and a cloud-native object layer can generate egress bills that exceed the compute cost. The metered exit tax is not a pricing quirk — it is an architectural lock-in mechanism. Infrastructure you cannot afford to leave is infrastructure someone else controls.

Generative AI has created a new and poorly understood data-liability surface. When a team routes customer data, internal documents, or regulated PII through a hyperscaler's managed inference endpoint — even with data-processing agreements in place — that data touches infrastructure the team cannot audit, in regions they may not control, logged by systems they cannot inspect. For regulated industries (HIPAA, GDPR, financial services), this is not a theoretical concern. It is an active compliance gap that regulators are beginning to close.

The practical alternative is not to avoid inference — it is to run inference inside a perimeter you own. Modern open-weight models (Llama, Mistral, Phi) deployed on dedicated GPU nodes within a customer's private cluster eliminate the data-residency exposure entirely. The capability trade-off is real but shrinking; the compliance trade-off is not.

SOC 2 Type II, HIPAA, GDPR, DORA, and EU data-residency requirements all share a common demand: evidence. Not attestations, not vendor SLAs — evidence. Logs with cryptographic integrity. Audit trails with provenance. Network policies you can produce at a moment's notice. Access reviews that are automated, not quarterly spreadsheets.

The regulatory pressure is asymmetric: it is becoming harder to satisfy a serious audit when your infrastructure is opaque managed services you cannot inspect. Self-hosted, well-documented, GitOps-driven infrastructure can produce that evidence systematically. Managed services often cannot — or make it prohibitively expensive to try.

Beneath the headline cloud-growth numbers, a quiet counter-movement has been running for several years. Teams that moved aggressively to hyperscalers in 2015–2020 are selectively repatriating workloads — not all of them, not because cloud was wrong, but because they have learned which workloads have predictable, high-volume resource consumption that pencils out better on owned hardware. Kubernetes and Talos OS have made self-operated clusters operationally competitive with managed services for teams that are willing to invest in the discipline.

This is not nostalgia for the data-center era. It is a mature re-evaluation of the rent-vs-own calculation — one that accounts for egress, lock-in, audit friction, and the value of optionality. That re-evaluation is what we help teams perform, rigorously.

§02/The Five Pillars

Not principles. Practices.

Each pillar answers a specific failure mode we have seen recur across infrastructure engagements. They are not aspirational values — they are engineering disciplines with concrete practices and measurable failure modes.

§01OWN-THE-PERIMETER

Sovereignty

Practicing sovereignty means mapping every layer of your stack to an owner — not a vendor, an owner. The distinction matters: a vendor gives you a product; an owner has operational knowledge, runbooks, and the ability to recover the system independently.

Concretely: your Kubernetes control plane has a documented recovery procedure your team has practiced. Your database backup is in object storage your team controls, tested for restore latency quarterly. Your secrets management system is audited and the audit log is yours. Your network perimeter is defined in code, reviewed in pull requests, and enforced by admission controllers — not by a managed policy service you cannot inspect.

Sovereignty does not mean isolated. It means intentional: every external dependency is a documented risk acceptance, not an invisible assumption.

Problem addressed

The problem it answers: critical infrastructure owned by someone else, with metered exit and opaque internals.

Failure mode

The failure mode of ignoring it: a critical incident reveals that the runbook references a vendor console your team has never navigated under pressure, the backup is untested, and the recovery timeline is measured in days rather than hours.

Field note

The cloud repatriation engineering playbook
§02OSS-AS-DISCIPLINE

Open source as method

Open source as method means three things. First, inspection: the tools you depend on are readable. You can trace the behavior of Kubernetes, Cilium, Argo CD, or Prometheus from source — and when something goes wrong at 2 AM, that matters. Second, contribution: teams that contribute to the projects they depend on develop a fluency with the internals that no documentation reproduces. Third, independence: an open-source foundation means no single vendor can deprecate your stack unilaterally.

In practice, this shapes tool selection at every layer. We prefer Talos OS over managed node pools because the control plane is auditable. We prefer Argo CD over cloud-native GitOps products because the reconciliation loop is inspectable and portable. We prefer Prometheus and Grafana over vendor observability SaaS because the data stays in-cluster and the dashboards move with the infrastructure.

OSS-as-discipline also means being honest about where open source is not the right call. Some managed services deliver genuine value that is difficult to replicate — and we will say so.

Problem addressed

The problem it answers: treating open source as a cost-reduction checkbox rather than a discipline that produces durable, inspectable, community-backed infrastructure.

Failure mode

The failure mode of ignoring it: a vendor deprecates a service or changes pricing terms, and the team has no migration path because every layer was built on proprietary abstractions that do not have OSS equivalents.

Field note

OSS supply-chain security: SBOM, Sigstore, SLSA
§03EVIDENCE-BY-DEFAULT

Audit-grade rigor

Audit-grade rigor means the infrastructure produces evidence as a side effect of normal operation — not as a separate compliance task. Admission controllers enforce policy at deploy time and log every decision. Network flows are captured by eBPF-based CNI and queryable. RBAC is reviewed automatically on every pull request. Secrets rotation is scheduled and verified, not manual.

The operational architecture we build stores audit logs with cryptographic integrity verification — a SHA-256 chain on the log archive so any tampering is detectable. Cluster-level CIS benchmarks run on every node bootstrap via Talos machine config. Policy-as-code (OPA Gatekeeper or Kyverno) means the security posture is reviewable by auditors who understand code, not just GUI screenshots.

For regulated clients, we build the evidence collection into the delivery — ADRs, network diagrams, data-flow maps, and RBAC matrices are deliverables, not afterthoughts. An auditor can open the repository and understand the system without needing to schedule a Q&A.

Problem addressed

The problem it answers: compliance treated as a periodic review rather than a continuous property of the system, producing audit fatigue, gaps, and retroactive remediation costs.

Failure mode

The failure mode of ignoring it: a SOC 2 audit or regulatory inquiry requires evidence that does not exist, triggering emergency remediation work at high cost — or worse, a material finding that delays a fundraise, acquisition, or go-live.

Field note

NIS2, DORA, and the EU AI Act for self-hosted Kubernetes
§04EXIT-RAMPS-DESIGNED-IN

Optionality

Exit ramps are designed in, not retrofitted. At every layer, we ask: what is the migration cost if this vendor doubles its price, deprecates this API, or is acquired? If the answer is 'prohibitive,' that is a risk to document and either accept explicitly or engineer around.

In practice, optionality looks like: stateless application layers with persistent state in standard formats (PostgreSQL, S3-compatible object storage). Ingress behind a load balancer abstraction the team controls, not a cloud-native load balancer with proprietary routing semantics. Helm charts or Kustomize overlays that work against any Kubernetes distribution, not against a managed service API. Observability data in open formats (OTLP, Prometheus) so the backend is replaceable.

Optionality is also temporal: a system built in 2025 should remain operable by a team that inherits it in 2030 with only the documentation and the code. We write for the team that inherits the system, not just the team that built it.

Problem addressed

The problem it answers: infrastructure decisions made in haste that close off future choices — proprietary APIs, single-vendor storage formats, undocumented integrations that are expensive to replace.

Failure mode

The failure mode of ignoring it: a business decision to change cloud providers, change vendors, or sell the company reveals that the infrastructure is architecturally coupled in ways nobody documented, and the migration cost is two years of platform engineering.

Field note

Multi-cluster GitOps with Argo CD and Flux
§05BUILT-FOR-DECADES

The long game

The long game is not about predicting the future — it is about building systems proportioned to their actual lifecycle. A Kubernetes cluster for a Series-B company should not have the operational complexity of a hyperscaler's control plane. A backup strategy should not require a dedicated team to operate. Infrastructure grows with the organization, not ahead of it.

Proportion means: choose boring technology for stable layers (PostgreSQL over distributed NewSQL for transactional workloads that do not need horizontal scale), choose modern and durable for emerging layers (Talos over legacy node management for clusters that will live for years), and document the reasoning so the next engineer understands the decision, not just the outcome.

It also means building handoff into the engagement by default. The team that operates the system after we leave should understand it better than they did before we arrived — not because we wrote a wiki, but because we built observable, well-documented, self-explanatory infrastructure and trained the team to own it.

Problem addressed

The problem it answers: over-engineering that collapses under its own operational weight, or under-engineering that requires a full rebuild within five years.

Failure mode

The failure mode of ignoring it: an infrastructure platform optimized for the current quarter accumulates operational debt at a rate that exceeds the team's ability to service it. By year three, the cost of maintaining the system exceeds the cost of rebuilding it.

Field note

Platform engineering golden paths

§03/How We Practice

The people who have run these systems.

Not slideware consultants. Not framework vendors. Engineers who have operated Kubernetes clusters in production, responded to 2 AM incidents, and handed systems off to teams that still operate them years later.

Who we are

Stribog is a senior infrastructure and platform engineering practice. The principals have built and operated Kubernetes and Talos clusters at scale, designed sovereign AI infrastructure for regulated environments, migrated workloads off hyperscalers, and built the audit-evidence pipelines that made those migrations defensible in front of auditors. We have operated on bare metal and on cloud, in financial services and in healthcare SaaS, for early-stage teams and for organizations with formal security and compliance programs.

How we work

We work alongside your team, not instead of it. The engagement model is designed so that ownership transfers to your engineers by default — not because we hand over a deliverable and walk away, but because we build with your team, document the trade-offs explicitly, and leave ADRs and runbooks as first-class deliverables rather than notes in a shared folder. We name the decisions we made, the alternatives we considered, and the reasoning. If the next team disagrees, they have the context to make a different call.

What we refuse to do

We do not build lock-in. We do not architect systems that require our continued involvement to operate. We do not recommend managed services we profit from. We do not produce slide decks in lieu of working infrastructure. We do not commit to timelines that trade quality for speed on systems that will carry production traffic for years. If the right answer is that you do not need us — that the problem can be solved with an open-source tool your team already has — we will say so.

Kubernetes / TalosGitOps / Argo CDBare metal & private cloudSovereign AI / local inferenceSOC 2 / HIPAA / GDPRAudit-evidence engineeringPlatform engineering

§04/The Long Game

Decade-scale thinking. Practiced in proportion.

The systems we build are not designed to impress during a demo. They are designed to be operable by a team that did not build them, in an organization that has changed, against threats that were not anticipated.

That is not a modest ambition. It requires discipline — the discipline to resist over-engineering when a simpler solution is durable, and to invest in complexity only when the lifecycle cost justifies it. It requires honesty about trade-offs, documentation that outlasts the people who wrote it, and infrastructure that is readable, not just functional.

Engineering sovereignty is not a destination. It is a practice — a continuous discipline of owning the systems you depend on, knowing the options you have, and making the decisions that compound in your favor over time.

That is what we are here to help you build.

10+Years operating production infrastructure

Built on Kubernetes, Talos, Argo CD, Cilium, and the open-source ecosystem — not vendor promise notes.

§05/Put the thesis to work

Score your sovereignty readiness across the five pillarsRead →Model a cloud-repatriation TCORead →See the capabilitiesRead →

§06/FAQ

Questions, answered plainly.

The questions we hear most from CTOs, engineering directors, and founders considering a sovereignty engagement.

What is engineering sovereignty?

Engineering sovereignty is the practice of a team owning the systems it depends on — infrastructure, tooling, and AI — so that no single vendor's pricing, deprecation, outage, or acquisition can dictate the business. It rests on five pillars: sovereignty, open source as method, audit-grade rigor, optionality, and the long game.

What does Stribog do?

Stribog designs and operationalizes production infrastructure that clients own and operate after the engagement: Kubernetes on Talos and bare metal, GitOps, open-source tooling that replaces SaaS lock-in, sovereign AI that keeps inference inside your perimeter, and audit-grade compliance engineering. The practice has operated since 2013.

What is cloud repatriation, and is it worth it?

Cloud repatriation is moving workloads off hyperscaler-managed services onto infrastructure you control — private cloud, co-located bare metal, or a deliberate hybrid. It is worth it when concentration risk, egress economics, or data-residency and audit requirements outweigh managed convenience, typically at the scale-up stage. Stribog models the trade-off per workload rather than treating it as an ideology.

Is self-hosting actually cheaper than the cloud?

Often, at steady-state scale — but not always, and rarely on day one. The gain is predictable, largely fixed economics plus the removal of concentration risk and egress fees; the cost is operational responsibility. Stribog builds multi-year TCO models so the decision is defensible to finance and the board, and says so plainly when a managed service is the right call.

Can we adopt AI and LLMs without sending data to third-party APIs?

Yes. Stribog deploys local inference on owned GPUs with private retrieval (RAG) and policy-as-code governance, so prompts, embeddings, and outputs never leave your perimeter. That is what allows legal and security to sign off in regulated environments.

What is KubeVigil?

KubeVigil is Stribog's open-source (Apache-2.0) Kubernetes Security Posture Management (KSPM) command-line tool. It scans live clusters or YAML manifests for security misconfigurations, maps each finding to remediation, and integrates with CI pipelines and AI assistants through an MCP server. It is free to use, fork, and extend.

How does Stribog engage, and will we depend on you afterward?

Three phases: a 90-minute executive briefing, a two-to-four-week sovereignty assessment that produces a board-ready report, then phased roadmap and execution delivered alongside your team. Ownership transfers at every milestone, and runbooks, architecture decision records, and exit-ramp documentation are deliverables. The goal is your team's autonomy, not a retainer.

Does Stribog work with regulated industries such as SOC 2, HIPAA, or GDPR?

Yes. Stribog treats compliance as an engineering problem: controls are mapped to concrete system behavior, and evidence is produced as a byproduct of normal operations — GitOps history, policy-as-code, immutable audit logs — so audits do not require an emergency evidence scramble.

Executive Briefing

Thirty minutes to clarify your infrastructure risk

Walk us through your vendor footprint and regulatory constraints. We will tell you honestly where sovereignty creates leverage — and where it does not. No pitch deck. No obligation.