Digital sovereignty engineering overview, the complete operator guide

A digital sovereignty engineering overview is the architectural map a founder or fractional CTO uses to decide what runs on rented stacks, what runs on owned infrastructure, and which jurisdiction's law applies to each byte of your data. We publish this guide because the operators who ask us for one rarely find a credible answer outside vendor brochures: the top pages on the topic are either listicles, vendor-sponsored explainers, or stale consultancy white papers, and none of them publish a dated engagement, a measured benchmark, or a decision rule a reader can defend in a board meeting. We do. La Boétie is a venture studio, digital agency, and fractional technical consultancy that ships software for founders, and this digital sovereignty engineering overview maps the eight pillars of our Digital Sovereignty family in one read.

Key takeaways:

• On world.hey.com, David Heinemeier Hansson reports that 37signals dropped its annual cloud bill from $3.2 million to $1.3 million in 2024 by moving seven applications from Amazon Web Services to owned Dell hardware, with savings now projected above $10 million over five years.
• The European Commission awarded its Sovereign Cloud procurement framework on 17 April 2026, granting European Union institutions access to up to €180 million of sovereign cloud services over 6 years across 8 measured sovereignty objectives.
• According to DanubeData's 2025 cost comparison, Hetzner's CCX33 dedicated AMD EPYC server (8 cores, 32 GB RAM, 20 TB monthly egress included) runs at €30 per month, roughly 4× to 6× cheaper than equivalent compute on hyperscalers.
• The General Data Protection Regulation fines non-compliant operators up to 4% of global annual turnover or €20 million, whichever is higher, per Article 83 published on gdpr.eu.
• The Hugging Face blog reports that Meta's Llama 3.3 70B runs on a single 80 GB GPU at roughly $0.10 per million input tokens, around 25× cheaper than GPT-4o-class commercial inference for comparable workloads.
• The decision rule we apply in every digital sovereignty engineering overview is the 30-day migration test: if you cannot exit a dependency in 30 days with a script you wrote in advance, the dependency is structural, not optional.

What this digital sovereignty engineering overview covers, and what it deliberately does not

A digital sovereignty engineering overview answers four operator questions in one document: where does each byte of your data physically live, which jurisdiction's law applies to a subpoena against it, which vendor can lock you in by removing or repricing a dependency, and how would you migrate off any single piece of your stack in 30 days if you had to. Anything that does not change one of those four answers belongs in a different document.

The territory in scope across our family of eight hubs maps cleanly onto the operator decisions you face: the political case for owning your stack (The La Boétie thesis), the deployment topology choice (self-hosting versus SaaS), the legal layer for the European Union and adjacent jurisdictions (EU digital sovereignty jurisdiction, data residency and the General Data Protection Regulation), the structural risk in your bill of materials (vendor lock-in patterns, open-source stack choices), the artificial intelligence boundary (self-hosted large language models), and the payment rails that move money under European Union law (sovereign payments and billing).

The territory deliberately out of scope here is the application layer above the stack (your product, your roadmap, your go-to-market) and the people layer below it (recruiting, security culture, on-call rotation). Both deserve their own family. Sovereign architecture without a sovereign team is theatre; product strategy without an opinion on the stack is naive.

Two definitions anchor everything that follows. Digital sovereignty, in the operator sense we use, is the right and the engineering ability to choose, inspect, modify, run, and stop running any piece of technology in your stack without asking a vendor's permission. Sovereignty by construction is the architectural discipline of preserving that right at design time rather than reclaiming it after a costly migration. This digital sovereignty engineering overview is, in effect, a sovereignty-by-construction manual at the family level.

We will name vendors, name regulations, name engagements, and commit to a decision rule. You will leave with the rule, the trade-offs, and a link to the hub-pillar guide for every choice further downstream. Where a section overlaps with one of our other families (growth engineering, applied AI, agency delivery, fractional technical leadership), we will say so. The rest of this digital sovereignty engineering overview is organised the way an operator decides: thesis first (why bother), topology second (where to run), risk third (what to inoculate against), jurisdiction fourth (whose law applies), stack fifth (which open-source components survive a five-year horizon), payments last. The closing sections cover three named engagements where the playbook was load-bearing, the regulatory and technical changes due in 2026, a FAQ for the questions board members usually surface, and our intro call as the next step if the territory matches your situation.

The La Boétie thesis applied to software stacks

In 1548, Étienne de La Boétie published the Discours de la servitude volontaire, an essay arguing that tyranny survives only because the governed cooperate: withdraw cooperation and the power collapses. Four and a half centuries later, the thesis maps cleanly onto software-as-a-service lock-in. A vendor's pricing power, contractual leverage, and ability to deprecate features on you exists because you keep paying and keep building on their primitives. Withdraw the cooperation, architecturally, and the leverage evaporates. That is the studio's house position, the reason we named the firm what we did, and the philosophical anchor of every digital sovereignty engineering overview we publish. The La Boétie thesis pillar goes deeper on the philosophical lineage; here we cover the engineering translation.

The operator translation has three engineering rules. First, every stateful dependency must have a documented exit: a migration script you could run within 30 days, written before you commit to the provider, not after. Second, no proprietary data format crosses an architectural boundary: your invoices live as PostgreSQL rows and Stripe events as raw JSON in object storage, never as Stripe-only billing primitives you cannot serialise out. Third, identity and authentication never delegate to a provider you would not trust to run your business: an Auth0 or Clerk dependency on day one is a lock-in surface on day 800, when the price doubles or the SSO tier suddenly costs $24,000 a year.

David Heinemeier Hansson, co-founder of Basecamp and 37signals, has documented the financial case for the thesis in public. He writes on world.hey.com that his company's cloud bill dropped from $3.2 million per year to $1.3 million in 2024 after repatriating seven applications (including the email service HEY) from Amazon Web Services onto owned Dell hardware. Total savings are now projected above $10 million over five years. The hardware investment was around $700,000 and was fully recouped in 2023 as long-term AWS commitments rolled off. That is the unit economics of voluntary servitude reversed, in one well-documented case.

We do not argue every company should leave the cloud. We argue every company should know what it costs to stay. The thesis is not absolutist about hosting model; it is absolutist about reversibility. A SaaS dependency you could rebuild on owned capacity in a quarter is sovereign. A SaaS dependency that took a custom-coded marketplace integration five engineers six months to wire up is not. The architectural test is the migration plan, not the pricing page, and every digital sovereignty engineering overview we hand to a client states that test in the executive summary.

Self-hosting versus SaaS, our decision rule for production workloads

The self-hosting-versus-SaaS debate produces more heat than light because most arguments compare a fictional 100% self-hosted setup against a fictional 100% SaaS setup. Real engagements are hybrid. The interesting question is which workloads belong on which side of the line and what the trigger is to move them. Our self-hosting versus SaaS pillar walks the framework in detail; the rule below is what we apply by default inside every digital sovereignty engineering overview.

The decision rule we encode in every digital sovereignty engineering overview is binary at the workload level: we self-host a workload when at least two of the following four conditions are true: the workload has predictable steady-state demand (so cloud elasticity earns no premium), the workload moves more than 5 TB of egress per month (so hyperscaler bandwidth pricing dominates the bill), the workload processes personal data subject to the General Data Protection Regulation (so jurisdiction matters), or the workload runs an open-source primitive that is widely operated (so the operational expertise exists in the market and is not a unicorn). Otherwise we use a European Union-headquartered managed service or a hyperscaler with reservations and an exit plan.

The cost gap on commodity compute is wider than most operators realise. DanubeData's 2025 cost comparison puts Hetzner at roughly 4× to 6× cheaper than Amazon Web Services on equivalent CPU and memory. A Hetzner CCX33 with 8 dedicated AMD EPYC vCPUs, 32 GB of RAM, and 20 TB of monthly egress included runs at €30 per month. The same envelope on Amazon Web Services bills closer to €130 to €180 per month plus egress. On data-heavy workloads (media, downloads, AI inference output, exports), the egress alone makes Hetzner the obvious default.

The honest counter-argument every digital sovereignty engineering overview must address head-on is operations. The same DanubeData report flags 10 to 20 hours per month of platform engineering effort at €75 to €150 per hour, or roughly €750 to €3,000 per month per cluster, in undifferentiated database administration, patching, monitoring, and incident response. That is real money, and it is not on the Hetzner invoice. When we model total cost of ownership for clients inside a digital sovereignty engineering overview, we count it explicitly.

1. Predictable workloads. Steady-state databases, application servers, video transcoders, and AI inference workers fit owned capacity well. The cloud premium pays for elasticity you are not using.
2. Bursty workloads. Background jobs, image processing, batch analytics, and one-off migration tasks fit elastic compute (with a documented spend ceiling).
3. Compliance-sensitive workloads. Anything storing personal data under the General Data Protection Regulation goes to European Union-headquartered providers, never to a United States hyperscaler under the CLOUD Act exposure described in the jurisdiction section below.
4. Vendor-unique workloads. Email deliverability (Postmark, SendGrid), payment processing (Stripe, Mollie), and identity providers are economically irrational to self-host for most teams; we use them and document the exit anyway.
5. Stateful primitives. Postgres, Redis, Kafka, ClickHouse, MinIO, and OpenSearch are widely operated; we self-host when scale or compliance demands. Specialist managed offerings (Crunchy Data, Aiven, ScyllaDB Cloud) get used when the team lacks the bandwidth.
6. Stateless services. API gateways, web frontends, and background workers run on Kubernetes or Nomad on Hetzner or OVH dedicated, with a documented disaster recovery plan that targets a different European Union region.
7. AI inference. Self-hosted on dedicated GPU servers for steady production traffic; managed inference (Hugging Face Inference Endpoints, Scaleway AI inference, Together AI) for spiky experimentation.
8. Observability. Self-hosted Grafana stack with Loki, Tempo, and Mimir on owned capacity; the dependency on a vendor's observability platform is one of the most expensive lock-ins to reverse.

Vendor lock-in patterns and the inoculations that work

In the 2022 Statista enterprise cloud survey, 47% of organisations rated no cloud vendor lock-in as essential. The hybrid and multi-cloud topologies that dominate enterprise architectures in 2026 are an explicit response: industry surveys repeatedly cite lock-in avoidance as the leading motivation behind diversifying across two or more providers. Operators understand the risk; what they consistently underestimate is the surface area. Our vendor lock-in patterns pillar maps the typology in full; the four patterns below cover roughly 90% of the engagements we audit and form the lock-in chapter of every digital sovereignty engineering overview we deliver.

Pattern 1, proprietary primitives. A vendor surfaces a managed service (AWS DynamoDB, Google Cloud BigQuery, AWS Lambda) with no operationally feasible self-hosted equivalent. The cost is invisible until you need to leave. Inoculation: write your application against an abstraction layer (an SQL surface for DynamoDB, ANSI SQL for BigQuery, a queue-and-worker pattern for Lambda) so the proprietary primitive is one substitutable adapter, not a structural component.

Pattern 2, identity gravity. An identity provider (Okta, Auth0, Clerk) ends up holding the user table, the session store, the role definitions, the audit log, and the multi-factor authentication policy. Migrating away requires extracting and re-hashing passwords, re-issuing tokens, rebuilding role mappings, and a four-week marketing operation to ask users to reset credentials. Inoculation: keep your user model in your own database, treat the identity provider as a session issuer only, and store password hashes locally even when an external service offers to manage them.

Pattern 3, billing primitives. Stripe, Chargebee, and Recurly hold the canonical subscription state, with your database storing only foreign keys. Tax, dunning, prorations, plan changes, and tax compliance all live in the vendor. The pricing of any one of these primitives can double without notice (Auth0's 2022 organisation tier repricing being the canonical example). Inoculation: store every billing event as a raw JSON record in your own database the moment it arrives by webhook, and rebuild the subscription state machine from that log on demand. The vendor becomes a stateless processor, not a system of record.

Pattern 4, observability moat. Datadog, New Relic, and Splunk's pricing scales with cardinality, log volume, and retention. Quotes of $400,000 to $1.5 million per year are routine for fintechs once user counts cross seven figures. The migration cost is high because dashboards, alerting rules, and runbooks have all baked in the vendor's query language. Inoculation: write alerts in a Prometheus-style query language even when sent to a proprietary backend, and keep the raw telemetry available in object storage so a future migration is a re-ingestion, not a rebuild.

The pattern across the four is the same. Lock-in is rarely a single decision; it is the accumulation of dozens of small adoption choices that each looked rational on the day they were made. The architectural discipline is to write everything against open interfaces and treat vendor-specific features as adapters under your control, not load-bearing structure. A digital sovereignty engineering overview that does not name these four patterns explicitly is not finished.

EU digital sovereignty and jurisdiction in 2026

The European Union's posture on digital sovereignty shifted from regulator to investor in 2026. The European Commission awarded its Sovereign Cloud procurement framework on 17 April 2026, granting European Union institutions access to up to €180 million of sovereign cloud services over six years across eight measured sovereignty objectives (strategic, legal, operational, environmental, supply chain transparency, technological openness, security, and compliance with European Union law). On 7 May 2026, CNBC reported that the Commission is preparing rules to restrict member-state governments' use of United States cloud providers for sensitive workloads. The Tech Sovereignty Package, expected on 27 May 2026, bundles the Cloud and AI Development Act (CADA) and the Chips Act 2.0. The full breakdown lives in our EU digital sovereignty and jurisdiction pillar; the jurisdiction chapter of every digital sovereignty engineering overview we publish references it as the authoritative source.

The technical centrepiece of the European response is the European Union Cloud Services Certification scheme (EUCS), an attempt to codify what sovereign means in procurement language. The Council of the European Union urged the Commission to accelerate adoption in September 2024; as of May 2026, the scheme is technically agreed but politically contested, principally because the strongest sovereignty tier excludes United States-headquartered providers and the weakest does not. Operators selling into European Union public-sector buyers in 2026 need to know which tier their stack qualifies for.

The binding legal collision remains the United States CLOUD Act of 2018. The Act lets United States law enforcement compel a United States company to disclose data stored anywhere in the world, including European data centres. Microsoft's chief legal officer in France confirmed under oath before the French Senate's commission on public procurement that the company cannot guarantee European Union customer data is safe from such requests, even when stored in Microsoft's European regions. Article 48 of the General Data Protection Regulation prohibits transfers under foreign court orders without a mutual legal assistance treaty, which creates a direct conflict any operator running on a United States hyperscaler in the European Union inherits.

The operational answer most teams settle on is to route any workload that processes data of European Union residents through a European Union-headquartered provider where the legal nationality, the corporate jurisdiction, and the data location all sit inside the European Union. That set is small but real: Scaleway (owned by Iliad Group, headquartered in France), OVHcloud (France, the largest European Union hyperscaler by revenue), Hetzner (Germany, dominant on price-performance), IONOS (Germany, public-sector heavy), Exoscale (Switzerland, regulated workloads). Each has gaps relative to Amazon Web Services or Microsoft Azure (thinner managed-service catalogues, fewer regions, less mature serverless), and operators trade those gaps for jurisdiction.

The Register reported on 20 April 2026 that Europe had selected four sovereign cloud providers for the European Union procurement framework, including one offering with a Google-affiliated component (the inclusion of which sparked significant debate in the sovereignty community for precisely the reasons above). Read the announcement carefully when selecting a sovereign provider; not every certification carries the same legal weight, and the operator filter that survives audit is the one a thorough digital sovereignty engineering overview applies before procurement.

Data residency and the General Data Protection Regulation, where your data lives

The General Data Protection Regulation does not, strictly, require European Union resident data to remain physically inside the European Economic Area. It requires that any cross-border transfer go to a jurisdiction that provides essentially equivalent protection (an adequacy decision), or rely on Standard Contractual Clauses (SCCs), Binding Corporate Rules (BCRs), or a derogation. The maximum fine is 4% of global annual turnover or €20 million, whichever is higher (gdpr.eu), and the Court of Justice of the European Union has confirmed that fines are calculated on group revenue rather than entity revenue, which has materially changed the calculus for enterprise groups. Our data residency and GDPR pillar covers the full transfer-mechanism decision tree; the data chapter of any digital sovereignty engineering overview should reference it.

The European Union-United States Data Privacy Framework, in force since 10 July 2023, survived its first legal challenge before the Court of Justice of the European Union in September 2025 but remains under political risk. Operators relying solely on the Framework should keep a Standard Contractual Clause backup mechanism in place and conduct a Transfer Impact Assessment (a documented analysis of whether the destination country's surveillance regime undermines the protection on paper) before any transfer. The Transfer Impact Assessment is the workhorse compliance artifact most operators still skip.

A Data Processing Agreement is not optional in any business-to-business European Union deployment that involves personal data. Even when both parties are European Union-headquartered, the Article 28 obligations on processors are explicit and audited. We push clients to template a Data Processing Agreement with a single sub-processor list and a 30-day notice for changes; the operational alternative (negotiating bespoke agreements with each vendor) does not scale past 20 vendors.

The technical posture that survives a regulator's audit has five components. Data classification (which fields are personal data, which are sensitive personal data, which are anonymised). Storage map (which database, in which region, replicated where). Access map (which engineers, support staff, and third-party processors have access, and through what authentication). Retention rules (which records expire when, with automated enforcement). Subject-access workflow (a tested procedure to export, rectify, or delete a data subject's record within the 30-day Article 12 statutory deadline). Each of these is a maintainable artifact; together they are the operational backbone of a sovereign data architecture.

The regulators publish their enforcement priorities every year. The 2025 priorities of the Commission Nationale de l'Informatique et des Libertés in France targeted artificial intelligence training datasets, the legal basis for tracking pixels, and data transfers to cloud-based collaboration tools. The 2026 priorities, announced in February, add health data, large language model inference logs, and biometric data. Match your engineering roadmap to the regulator's calendar, not the other way around; a digital sovereignty engineering overview that ignores the regulator's published priorities is one audit away from a rewrite.

Open-source stack choices and self-hosted large language models in 2026

The operator's question on open-source is not should we use open-source (everyone does) but which open-source primitives will still be maintained in five years and which are one acquisition away from extinction. Our open-source stack choices pillar details the decision matrix; the short version that a digital sovereignty engineering overview should commit to is that we bias toward foundations with multiple corporate backers (Cloud Native Computing Foundation projects, Apache Software Foundation projects, Linux Foundation projects) and away from single-corporate-sponsor projects without an exit (Redis under the SSPL relicence in March 2024 being the canonical recent cautionary tale).

The production stack we deploy most often is a deliberate set: PostgreSQL for relational data, Redis or Valkey (the fork from Linux Foundation after the Redis relicence) for cache, NATS or Kafka for messaging, MinIO for object storage with an Amazon S3-compatible API, Caddy or Traefik for ingress, and Kubernetes or Nomad for orchestration. Each component has a public roadmap, multiple maintainers, and a non-trivial operator community. None is run by a single corporate sponsor that could relicence it overnight.

The artificial intelligence layer changed faster than any other in 2024 and 2025, and 2026 has stabilised enough to commit to a production posture. Meta's Llama 3.3 70B is the strongest single-GPU open-weight model available: it fits on a single 80 GB GPU (an Nvidia H100 or H200) and runs at roughly $0.10 per million input tokens and $0.40 per million output tokens, approximately 25× cheaper than the GPT-4 tier of commercial inference for comparable quality on most non-frontier tasks, according to the Hugging Face blog. DeepSeek-V3 (671 billion parameters, 37 billion active per token, 128,000 token context) is the strongest open-weight model overall but requires multi-GPU servers that are operationally heavier.

For production deployment, we use Text Generation Inference (TGI), the Rust-and-Python-and-gRPC server Hugging Face uses to power Hugging Chat in production. The deployment unit is one or two GPU servers on Hetzner or OVH dedicated GPU hosts, behind an internal load balancer, with your own authentication, rate limiting, and prompt logging. Total cost for a small production deployment (1,000 to 10,000 monthly active users on a chat workload) lands between €1,500 and €6,000 per month for hardware, plus the engineering time. The full architecture is in our self-hosted large language models pillar.

The operational trap is not GPU rental, it is the rest of the inference platform: evaluation harnesses, prompt versioning, output logging that complies with the General Data Protection Regulation, rate limiting, fallback to a managed provider when load spikes, and the on-call rotation for a stateful service. Teams that approach self-hosted large language model deployment as a model problem instead of a platform problem run into the same operational cost the cloud advocates warn about. Approached as a platform, with the same engineering rigor you would apply to a payment processor, it is a viable production posture in 2026 and a recurring chapter in our digital sovereignty engineering overview output.

Sovereign payments and billing infrastructure, the last mile of the stack

Payments is the layer where sovereignty arguments get tested against the hardest commercial reality: payment processors are an oligopoly, interchange fees are set at the card-scheme level, and the marginal cost of leaving Stripe is the highest of any vendor in your stack. Our sovereign payments and billing pillar maps the full territory; the operator-level position that closes every digital sovereignty engineering overview on this layer is that full payment sovereignty is impractical for most teams, partial sovereignty is essential, and the discipline is choosing which parts to own.

The parts you can own without rebuilding a card network are three: the customer billing state machine (subscriptions, plans, prorations, invoices, dunning) belongs in your database, not Stripe's, because subscription state is core business logic that survives processor changes. The tax and accounting integration (VAT collection, OSS / IOSS reporting in the European Union, accounting export) sits on a tax engine you operate, even when Stripe Tax provides the calculation primitive. The reconciliation pipeline between processor events and your ledger sits on infrastructure you run, because the audit trail and dispute resolution depend on it.

The parts you should not try to own without enterprise-scale volume are also three: the PCI DSS Level 1 environment that touches raw card numbers (Stripe, Adyen, Mollie, or Worldline absorb the certification cost), the relationships with the card schemes themselves (Visa, Mastercard, the Single Euro Payments Area), and the fraud detection layer (training a fraud model takes data volumes most teams cannot produce). The economic point of using a processor is that they amortise these costs across thousands of merchants.

The European Union has built credible alternatives in adjacent payment rails. The Single Euro Payments Area Instant Credit Transfer (SCT Inst), governed by the 2024 European Union Instant Payments Regulation, settles a euro transfer in under 10 seconds and caps the fee a bank can charge for an instant transfer at the level of a standard credit transfer (often free for consumers). For business-to-business transactions, that is a credible alternative to card payments. The European Payments Initiative's Wero wallet, live in several European Union countries since 2024, gives consumer-facing operators a card-scheme-independent rail. We use both where the transaction profile fits, alongside cards.

The sovereign-payments architecture we deploy for typical engagements stores every webhook from every processor in object storage on MinIO inside the European Union, replays them into a Postgres event-sourced ledger of our design, and uses the processor strictly as a stateless authorisation API. Migration off any one processor (we did this for one client from Stripe to Mollie in 2024) becomes a six-week project, not a six-month rebuild, which is the migration-test outcome a credible digital sovereignty engineering overview promises and delivers.

Three engagements where this playbook was load-bearing

The digital sovereignty engineering overview above is not theory. Three engagements in our portfolio illustrate the decisions in production, sector by sector, and demonstrate what an applied digital sovereignty engineering overview produces in numbers.

A finance platform, france-epargne.fr, launched 2023, ongoing. The product distributes life-insurance contracts under French Autorité de Contrôle Prudentiel et de Résolution supervision; data residency had to be French, the legal nationality of every provider had to be European Union, and the audit trail had to satisfy a regulator. We deployed PostgreSQL with logical replication on Scaleway in Paris, application workloads on Hetzner dedicated in Falkenstein and Helsinki, MinIO for documents in two French data centres, and Stripe with a custom event-sourced billing layer to allow Mollie as a backup processor without code changes. The monthly infrastructure footprint is an order of magnitude below what the same architecture would cost on Amazon Web Services Frankfurt with equivalent egress.

An auction platform, llb-auction.com, real-time bidding workload, launched 2024, ongoing. Real-time bidding is a textbook case for the self-hosting calculus: predictable steady-state traffic, heavy WebSocket usage, large media payloads for catalog images and bid receipts. We ran the entire stack on OVHcloud dedicated servers in Roubaix and Strasbourg, PostgreSQL in a hot-standby pair, Redis for the bid book, and a NATS message bus for fan-out. The 2024 infrastructure cost ran several times cheaper than the equivalent Amazon Web Services configuration we modelled side by side before commit.

A multi-tenant insurance comparator, AssureCompare and the Lynkflow back-end, launched 2024, ongoing. The Lynkflow software-as-a-service is the in-house platform we built to operate insurance distribution across multiple white-label front-ends; sovereignty mattered because each front-end carrier required a data-processing agreement with French data residency. The architecture isolates tenants at the PostgreSQL schema level (not the database level, deliberately, to control the operational cost), runs application workloads on Scaleway managed Kubernetes in Paris, and stores documents on MinIO in two French data centres with cross-region replication. New tenant onboarding takes hours rather than weeks because the architecture was designed for multi-tenancy from day one. Over 18 months in production, we have onboarded multiple carriers without changing the architecture.

The consistent decision rule across the three engagements, and the one a useful digital sovereignty engineering overview repeats verbatim, is this: European Union jurisdiction for every persistent dependency, owned capacity where the workload is steady, managed services only when the workload is bursty or genuinely undifferentiated, and a documented exit plan written into the architecture decision record on day one.

What changes in the digital sovereignty engineering overview this year

Three shifts will reshape the digital sovereignty engineering overview during 2026 and you should be planning against them now.

The Tech Sovereignty Package and Cloud and AI Development Act, expected from the European Commission on 27 May 2026, will introduce procurement preferences and likely funding for European Union-headquartered cloud and artificial intelligence infrastructure. Public-sector buyers in 27 member states will have a more explicit sovereignty test in their procurement scoring. Operators selling into the public sector, healthcare, or critical infrastructure should expect their European Union jurisdiction posture to become a hard requirement, not a tiebreaker.

The European Union Artificial Intelligence Act risk-classification deadlines continue through 2026 and 2027. The general-purpose artificial intelligence model obligations entered application on 2 August 2025, and the bulk of the high-risk system obligations apply from 2 August 2026. Any team running a self-hosted large language model in production needs an Article 53 documentation pack on file and a clear classification of which downstream use cases trigger which obligations. The Commission's AI Office continues to publish implementation guidance that materially clarifies the technical documentation requirements; treat it as required reading.

The 2025 Redis relicence and the 2026 Elasticsearch relicence pattern signal that single-corporate-sponsor open-source is structurally unstable, and the open-source chapter of any digital sovereignty engineering overview should account for it. Forks (Valkey from Linux Foundation for Redis, OpenSearch from Amazon Web Services for Elasticsearch) are now the conservative choice; the original projects are the speculative one. Any architecture decision record from 2022 or 2023 that committed to a single-corporate-sponsor project should be reviewed in 2026 with a fork as the default substitution.

We are updating our default digital sovereignty engineering overview stack accordingly: Valkey replaces Redis on new engagements, OpenSearch replaces Elasticsearch, PostgreSQL with pgvector replaces several proprietary vector databases (Pinecone, Weaviate Cloud) where the workload fits, and we have moved our default container orchestrator from managed Kubernetes to a Talos Linux plus Cilium baseline on owned hosts for engagements where the team can absorb the operational discipline.

FAQ : Digital sovereignty engineering overview, operator questions

What does a digital sovereignty engineering overview actually decide?

It decides four operator questions in one document: where each byte of your data physically lives, which jurisdiction's law applies to a subpoena against it, which vendor can lock you in by removing or repricing a dependency, and how you would migrate off any one piece of your stack in 30 days if you had to. Anything that does not change one of those four answers belongs in a different document. The overview is not a recommendation against managed services; it is the framework that tells you which workloads can safely use them and which should sit on owned capacity.

Is full self-hosting the only sovereign option recommended by a digital sovereignty engineering overview in 2026?

No. Sovereignty is about control and reversibility, not asceticism. Many engagements settle on a hybrid topology: managed Postgres at a European Union provider like Scaleway, application workloads on Hetzner dedicated servers, object storage on MinIO behind a single tenant control plane, large language model inference on Hugging Face Text Generation Inference inside the same network. The discipline is portability and a documented exit path, not refusing every managed service.

How does the CLOUD Act change a European Union deployment that already complies with GDPR, in the lens of a digital sovereignty engineering overview?

The 2018 CLOUD Act lets United States law enforcement compel a United States company to disclose data stored anywhere in the world, including European data centres. Microsoft's chief legal officer in France confirmed under oath before the French Senate that the company cannot guarantee European Union data is safe from such requests. That creates a direct conflict with Article 48 of the General Data Protection Regulation, which the European Data Protection Board flags as a transfer event. The practical implication is that compliance on paper is not sovereignty; the legal nationality of the provider matters.

What is the realistic cost gap between Hetzner and Amazon Web Services for a steady production workload?

DanubeData's 2025 cost comparison puts Hetzner at roughly 4× to 6× cheaper than Amazon Web Services for equivalent compute, and the gap widens further on egress: a Hetzner CCX33 dedicated server (8 cores, 32 GB RAM) costs €30 per month with 20 TB of monthly egress included, where the same egress on Amazon Web Services would dwarf the compute bill. Subtract roughly 10 to 20 hours of monthly DevOps time at €75 to €150 per hour for hands-on operations to get a fair total cost of ownership.

Can a small team run a self-hosted large language model in production?

Yes, with realistic scope. Meta's Llama 3.3 70B fits on a single 80 GB GPU and runs at roughly $0.10 per million input tokens, about 25× cheaper than GPT-4 according to the Hugging Face blog. Production deployment uses Text Generation Inference (the inference server Hugging Face uses to power Hugging Chat in production), behind your own authentication and rate limiting. The cost trap is not GPU rental, it is the engineering hours spent on evaluation harnesses, prompt management, and fallback logic.

How La Boétie ships a sovereign stack with you

We operate as a single flexible team of approximately five to six engineers, multilingual and multi-timezone, structured to deliver across three modes. Each mode draws on the same digital sovereignty engineering overview as its decision framework, and each engagement leaves you owning everything that was built.

Sovereign stack audit and roadmap. A two-week engagement that produces a written digital sovereignty engineering overview covering your current dependencies, jurisdiction exposure, lock-in surface, and the prioritised migration plan to close the highest-impact gaps. We have run this for fintech, insurance, auction, and legal-tech clients; the deliverable is the artifact your board reads and your engineers execute against. The audit is fixed-price.

Architecture and build, fractional or full-time. We design and ship sovereign-by-construction backends, payments, and artificial intelligence layers using the stack and the decision rule above. Recent builds include france-epargne.fr (life insurance distribution, French Autorité de Contrôle Prudentiel et de Résolution-supervised), llb-auction.com (real-time auctions, 6,500 registered bidders), assuied-avocat.fr (legal-tech document automation), and the Lynkflow software-as-a-service that powers AssureCompare and four other white-label insurance distributors. You get the source code, the infrastructure, and the runbooks at the end of the engagement, every time.

Fractional chief technology officer and ongoing technical leadership. For founders who need senior architectural judgment without the cost of a full-time chief technology officer, we embed one of our partners as a fractional chief technology officer (typically 6 to 12 hours per week) and pair them with a delivery engineer for execution. The arrangement scales up to full-time as the business needs it and scales back down without firing anyone.

If any of the three modes fits where you are now, the next step is a 30-minute studio intro call. We will read the situation, give a direct read on whether the playbook applies to your stage, and (if it does) outline a concrete first engagement. We do not pitch in the call; we either match or we say so, and the conversation is shaped by the same digital sovereignty engineering overview you have just read.

Conclusion

The operator question that matters in 2026 is not cloud or no cloud, open-source or proprietary, European Union or worldwide. It is do you control the part of the stack that, if a vendor changed terms tomorrow, would put your business at material risk. A complete digital sovereignty engineering overview answers that question for every layer of your bill of materials, names the inoculation, and lays out the migration plan you would actually run. The studio's commitment is to ship architectures where the answer is yes by construction, not yes by hope, and to leave you in full ownership of the result. If that is the level of conviction you want behind your next build, the intro call is the lowest-cost way to test the fit; the rest of this digital sovereignty engineering overview is yours to use whether we ever work together or not.

À lire également :

• The La Boétie thesis pillar
• Self-hosting versus SaaS pillar
• EU digital sovereignty and jurisdiction pillar
• Vendor lock-in patterns pillar
• Open-source stack choices pillar
• Data residency and GDPR pillar
• Self-hosted LLMs pillar
• Sovereign payments and billing pillar

Sources :

• Our cloud-exit savings will now top ten million over five years : David Heinemeier Hansson, world.hey.com, 2024
• Leaving the Cloud, Cloud Computing Is Not For Everyone : Basecamp, 2023
• Commission advances cloud sovereignty through strategic procurement : European Commission, 2026
• EU weighs restricting use of U.S. cloud platforms to process sensitive government data : CNBC, May 2026
• AWS vs Hetzner: Real Cloud Cost Comparison 2025 : DanubeData, 2025
• Hetzner Cloud Pricing : Hetzner Online GmbH, 2025
• What is GDPR, the EU's new data protection law : GDPR.eu, 2024
• How to Choose the Best Open Source LLM for Your Project in 2025 : Hugging Face, 2025
• European Cloud and AI, Scaleway : Scaleway, 2025
• Importance of no cloud vendor lock-in worldwide 2019-2022 : Statista, 2022
• CLOUD Act, Clarifying Lawful Overseas Use of Data Act : Wikipedia, 2024
• Europe picks 4 sovereign cloud providers : The Register, April 2026