For a decade, the default answer to "where does our software run" was somebody else's cloud. It was the pragmatic choice, and for a while the only debate was which hyperscaler. In 2026 that debate has quietly changed shape — not because the cloud stopped working, but because the legal and strategic ground underneath it moved. For European operators in particular, "where does our software run, and who can compel access to it" is no longer an infrastructure detail. It is a board-level question with regulatory teeth.

This is written for the people who have to answer that question — and who have started to suspect that the honest answer about their current stack is uncomfortable.

The contradiction hiding in your architecture

Three US-based companies account for roughly 65% of the European cloud market. For most European businesses, that means the customer data, the transaction records, the operational core all sit — legally speaking — within reach of a foreign jurisdiction. Under the US CLOUD Act, American authorities can compel a US-owned provider to hand over data even when the servers physically sit in a European data centre. Data residency, it turns out, is not the same thing as data sovereignty. The bytes can live in Frankfurt and still be reachable from abroad.

For years that contradiction was theoretical enough to ignore. It is becoming harder to ignore, because a second force has arrived to price it.

NIS2 turned security debt into personal liability

The NIS2 Directive reached full effect across the EU in 2026, and it is not the toothless compliance exercise some expected. Germany implemented it into national law effective December 2025 with no transition period; affected entities had to register with the Federal Office for Information Security (BSI) within a tight window, and the obligations are concrete: robust security measures, audits, and incident reporting inside 24 hours.

The consequences are equally concrete. Non-compliance can trigger fines of up to €10 million or 2% of annual turnover, and — this is the part that changes the conversation in boardrooms — members of the management body can be held personally liable for damage caused by culpable conduct. This is not an abstraction. Germany's BSI issued dozens of formal notices in late 2025 and levied an early significant fine of €850,000 against a mid-sized cloud provider for inadequate incident detection and late reporting. And because a single incident involving personal data can trigger NIS2 and GDPR at once, the exposure stacks.

Put the two forces together and a picture emerges that many European enterprises would rather not look at directly: sensitive operations running on infrastructure they don't govern, under a directive that now holds their executives personally responsible for how that infrastructure behaves in a crisis.

Why self-hosted stopped being the "harder" option

The reflexive objection to self-hosting used to be that it was the harder path — more to run, more to maintain, a step backward from managed convenience. That objection is aging badly. The self-hosting ecosystem matured; production-grade, source-available platforms now cover essentially every category that used to force a SaaS decision, and governments are actively steering toward them. The Netherlands' public sector operates a "prefer open" posture; Copenhagen has drawn up exit plans from US cloud dependence. When cities and ministries are building sovereignty into procurement, "self-hosted is niche" is no longer a defensible read of the market.

VBWD platform features page showing the self-hosted full-stack capabilities

Sovereignty as an architecture, not a slogan

"Digital sovereignty" is a phrase that has been said into meaninglessness, so let's ground it. In practice it means a small number of unglamorous properties: the data lives where you decide and under your legal jurisdiction; no foreign statute can compel a third party to hand it over because there is no third party holding it; you can read and audit the code that processes it; and you can produce, at will, the incident evidence a regulator will ask for because the logs are yours.

VBWD is built to make those properties the default rather than the project. It is a full-stack SDK — one self-hosted Python core, a Vue/TypeScript web front end, native iOS and Android SDKs — with a plugin architecture where identity, payments, subscriptions, catalogue, CMS and booking are capabilities you switch on inside your own perimeter. Self-hosted is not a deployment mode bolted on afterward; it is the assumption the whole thing is designed around. The result is that "where does our software run, and who can reach it" has a clean answer: on infrastructure you govern, reachable by you.

The honest caveat

None of this means self-hosting is free of responsibility — it relocates responsibility rather than removing it. You own the perimeter now, which means you own the diligence: patching, backups, the incident plan NIS2 wants to see. For an organisation with the operational maturity to run its own stack, that ownership is precisely the point; it is what sovereignty is. For one without it, the answer is a partner who runs it for you inside your jurisdiction — which is a different sentence than "a US hyperscaler runs it in a way you cannot inspect." The choice is not convenience versus control. It is which risks you'd rather be accountable for.

Where to take this next

If your organisation is having the NIS2 conversation — the registration, the incident plan, the uncomfortable audit of where your data actually sits and who can reach it — the practical next step is to see your own workload running on infrastructure you fully govern. We set up enterprise installations against real requirements, including the compliance and residency ones.

Request an enterprise installation → Bring your sovereignty and compliance constraints, and we'll show you the same operation running inside your perimeter, under your jurisdiction, with logs and code you can actually audit.