Open Source & Digital Sovereignty — keep control, even when the provider changes.
Digital sovereignty means you keep control over your data, your licenses, your suppliers and your operating location — regardless of what happens at a single provider. Open source is the foundation for this: no vendor lock-in, no license surprise, no closed source code that makes migration impossible.
Why digital sovereignty is becoming a platform question in the Mittelstand.
Mittelstand companies rarely feel the sovereignty question as an abstract debate, but through concrete incidents: a US hyperscaler changes its terms, a SaaS platform discontinues a function important to you, a vendor is acquired and roadmap promises lapse. Plus regulatory pressure — EU AI Act, NIS-2, new rules on data processing in third countries.
Open source takes away a platform’s ability to hold you hostage: source code is open, data stays portable, operations can be moved by location and contract. Plus: AI-supported retrieval works just as well on open-source stacks as on proprietary ones — often better, because you control what models may index and what they may not.
Five core capabilities of digital sovereignty.
Sovereignty is not binary. These five capabilities show where the dials can be turned today — without having to mean the big cloud exit.
Open licenses & source-code access
Open source is not license-free — it is released under open licenses such as MIT, Apache 2.0 or GPL that permit use, modification and redistribution without asking. You audit the source code yourself, have third parties audit it, and adapt it to your requirements. No vendor can take the software “out of the contract”, because the contract sits in the license itself, not in a bilateral provider agreement.
Location control for data and operations
You decide where your data is processed and where operations run: German data centre provider, European cloud, your own metal. Open-source software runs at any of these locations without a license enforcing “home region” conditions.
Multi-cloud capability
Containers, Kubernetes manifests, Helm charts and Terraform modules make the stack portable between hyperscalers, European providers and bare metal. Anyone who has containerised cleanly can change provider — or bring up emergency workloads in parallel at a second location.
Data sovereignty & encryption
Open source guarantees neither data sovereignty nor encryption automatically — they only emerge when keys, location and encryption pipeline are actively built. The open building blocks are however available and combinable: SOPS and age for secrets in the repository, KMS lifting for database encryption, mTLS between services. With that you manage the keys yourself, not the provider — even if a cloud provider comes under state access pressure, access without your keys stays unusable. Without active configuration no license achieves this; the license only refrains from closing the door for you.
Exit strategy
A documented path for leaving a provider, a platform or a hosting model in the worst case — with duration, effort and data formats. In open-source stacks the exit strategy is part of the stack, not first prepared in the crisis. Anyone who has never sketched the exit is effectively trapped.
Related architectures around open source & sovereignty.
How sovereignty interlocks in practice — from cloud models to concrete open-source stacks.
Multi-cloud
Workloads run on at least two independent providers — primary and secondary. Prerequisite for an outage, a terms-of-service change or a geopolitical incident not stopping the whole operation. Often built with Kubernetes as abstraction layer.
Sovereign cloud
European cloud providers with German or EU jurisdiction: IONOS, OVHcloud, STACKIT, Open Telekom Cloud. For workloads of high sensitivity often the clean answer, because neither CLOUD Act nor FISA 702 applies.
Bare metal & on-premises
Own hardware in your own data centre, often combined with bare-metal Kubernetes. For sectors with particularly high sovereignty requirements (public sector, healthcare, critical infrastructure) or where data volumes are more economical on-premises than in the cloud.
Open-source platform stack
TYPO3, Sylius, Mautic, Nextcloud, Mattermost, OnlyOffice — a stack in which every building block is open and replaceable against alternatives. Plus in-house developments that we also publish openly, instead of letting them sit as a black box.
GDPR-compliant CMS
Sovereignty and GDPR compliance are closely related but not identical. Those who build sovereignty get the GDPR upsides almost as a side effect — German location, in-house DPA, documented deletion path.
Our open-source packages as lived sovereignty.
We publish our own developments openly instead of operating them as a black box. A selection of packages in which sovereignty is implemented directly.
typo3-config
Fluent config API for caching, logging, secrets, TLS/mTLS — sovereignty at the most concrete point: you control which endpoint may be reached, with which certificate.
secret-resolver
Secret handling through external stores — SOPS, Vault, KMS. With that, keys and certificates live exactly where you want them, not in the cloud container.
content-distribution-source / -receiver
Content syndication between TYPO3 instances — multi-site and multi-region setups, without a central proprietary platform sitting between you.
cluster-file-backend
Storage backend that can be swapped against different implementations — S3-compatible, NFS, bare metal — without changing the application. Classical multi-cloud capability.
content-provenance
Ed25519 signatures and audit trail prove what was released when by whom — tamper-evident and independent of the hosting provider. Web content is public anyway; the value lies not in secrecy but in the verifiable provenance trail (which version was published when, with which AI involvement). A mandatory building block for EU AI Act Article 50-compliant watermarking and disclosure paths.
All packages at a glance
The complete list of our published open-source packages — including licenses and repository links.
From the blog
Beiträge zu digitaler Souveränität, Open Source und Compliance
4 GB Gemini Nano in Chrome — how we handle the trust breach by large vendors in our testing
Weiterlesen →
After patch wave comes continuity: what CISA's “CI Fortify” advisory means for German mid-market organisations
Weiterlesen →![[Translate to English:] Zwei papierdünne Rahmen überlappen sich leicht auf Beton, darunter ein kleiner Wasserspiegel; aus der Nahtstelle zieht ein roter Faden ins Wasser; eine Messinglupe und drei Stempel rahmen die Szene im kühlen Nordlicht.](/fileadmin/_processed_/8/e/csm_27c658d989a988383286ef9d323c2ac3369f683ef7673fb1e23102b8bdb73c90_80ee7bed79.avif)
Apache HTTP/2 CVE-2026-23918: when two frames topple the webserver pool — what 2.4.67 actually changes
Weiterlesen →Frequently asked questions on open source and digital sovereignty.
The questions that almost always come up in the Mittelstand on this topic — more nuanced than the marketing answers of the hyperscalers.
Does sovereignty mean we are not allowed to use US clouds?+
No. Sovereignty is a question of options, not of abstinence. You may use US hyperscalers — but in such a way that you can switch in an emergency. Containerise workloads, encrypt data, keep sensitive data separate if needed. By contrast, anyone who pushes everything into proprietary managed services has given up the option to choose.
Is open source automatically sovereign?+
No, but it is the prerequisite. Open-source software running in a proprietary cloud on proprietary managed services is not sovereign. Sovereignty only emerges through the interplay of license, operations, data location and exit strategy.
What does a sovereign stack cost compared to pure cloud?+
Short-term often more personnel effort, because you buy less managed service. Medium-term often lower, because there are no per-seat or per-request license fees and switching costs stay calculable. As data volumes grow, the ratio almost always tips in favour of the sovereign stack.
We use SaaS everywhere today. Where do we start?+
With the data processing in which you see the greatest risk — usually customer master data, personnel files or contractual correspondence. Find a sovereign alternative for it, run them in parallel, then migrate. Not the big-bang cloud exit, but a step-by-step move with measurable value.
Does AI use go together with open source and sovereignty?+
Yes. Inference can run on your own hardware or at sovereign providers (Llama, Mistral and comparable models). For many Mittelstand use cases the open models are enough. Anyone using proprietary APIs wraps them behind an exchangeable abstraction layer — then the provider can be swapped without rebuilding the application.
Where does Moselwal stand on this topic?+
We build our own stack on TYPO3, Sylius, Symfony and Kubernetes — all open source, all operable at European providers or on-premises. We publish our own developments openly where possible. Consulting is along concrete use cases, not along an ideological position.
How sovereign is your current stack really?
First conversation about suppliers, data locations and concrete exit risk — without ideological slant.
Response within two business days.