Digital sovereignty: control over infrastructure, data, and dependencies
🇩🇪 Auf Deutsch lesen~4 min read
devopsdigital-sovereigntyself-hostingopen-sourceprivacygaia-xsovereign-cloud-stackgdprvendor-lock-in
Save products you love by clicking the heart icon.
A practical guide to deploying SCS Cloud in a Box (CIAB) — a single-node OpenStack+Kubernetes cloud infrastructure built on European open-source standards for digital sovereignty.
Every company that currently uses cloud services from US hyperscalers (Microsoft 365, Google Workspace, AWS, OpenAI) carries a calculated risk: data leaves the European legal area, monthly subscription costs increase by 15–25% annually, and switching providers becomes virtually impossible due to proprietary formats, missing export interfaces, and deep integrations.
The math is simple: A company that cannot operate its own critical infrastructure does not own its digital identity. This becomes apparent at the latest when the provider doubles prices (Microsoft 365 has become over 30% more expensive between 2020 and 2025), GDPR-compliant data storage cannot be guaranteed, or a US law such as the CLOUD Act enables direct access to corporate data.
Digital sovereignty does not mean never using cloud services again. It means maintaining control over your own infrastructure, data, and technology decisions — and having the choice at any time to switch providers or host it yourself.
The decision between self-operation and the cloud is not a matter of faith, but a cost-benefit analysis. The following table shows the most important dimensions:
| Dimension | Self-Hosted (own infrastructure) | Cloud (Hyperscaler) |
|---|---|---|
| Costs | High one-time investment (hardware), low ongoing costs | Pay-as-you-go, but cost increases of 15–25% p.a. |
| Control | Complete — data, versions, configuration | Limited — provider defines upgrades, features, limits |
| Data Protection | Data never leaves your own network — GDPR compliant | Dependent on legal jurisdiction and provider's T&Cs |
| Maintenance Effort | High — own team for operation, security, updates | Low — handled by the provider |
| Scalability | Horizontally scalable, but limited by own hardware | Practically unlimited, but on provider terms |
| Reliability | Own responsibility — redundancy must be built yourself | SLA-guaranteed, but no own intervention possible during outages |
Rule of thumb: For critical business processes with sensitive data, self-hosting almost always pays off. For experimental or highly fluctuating workloads, the cloud may be more economical. The art lies in the hybrid approach: operate core services yourself, outsource peak loads to the cloud — but always with an exit strategy.
For every category, there are now mature open-source alternatives that are production-ready. Here are the most important building blocks, all documented with detailed production guides on tobias-weiss.org:
Email is often the first step — and the most complex. While Dovecot and Postfix have been standards for decades, the market has evolved:
Detailed comparison in the article: Stalwart vs Dovecot 2.4 CE
The self-hosted AI platform is the most important puzzle piece for sovereignty in the AI era (more on this below).
The following stack shows how few services are needed to set up a production-ready, sovereign infrastructure — including Nextcloud, database, reverse proxy, and AI gateway:
version: "3.8"
networks:
sovereign-net:
driver: bridge
services:
# Reverse Proxy with SSL and WAF
nginx:
image: nginx:1.27-alpine
networks:
- sovereign-net
ports:
- "443:443"
- "80:80"
volumes:
- ./nginx/conf.d:/etc/nginx/conf.d
- ./ssl:/etc/letsencrypt
- ./crowdsec:/etc/crowdsec
restart: unless-stopped
# Nextcloud (central collaboration platform)
nextcloud:
image: nextcloud:30-apache
networks:
- sovereign-net
volumes:
- nextcloud-data:/var/www/html
environment:
- POSTGRES_HOST=postgres
- POSTGRES_DB=nextcloud
- POSTGRES_USER=nextcloud
- POSTGRES_PASSWORD=${POSTGRES_PASSWORD}
- NEXTCLOUD_ADMIN_USER=admin
- NEXTCLOUD_ADMIN_PASSWORD=${ADMIN_PASSWORD}
- OVERWRITEPROTOCOL=https
depends_on:
- postgres
- redis
restart: unless-stopped
# MinIO (S3 backend for Nextcloud and other services)
minio:
image: minio/minio:latest
networks:
- sovereign-net
command: server /data --console-address ":9001"
volumes:
- minio-data:/data
environment:
- MINIO_ROOT_USER=${MINIO_ROOT_USER}
- MINIO_ROOT_PASSWORD=${MINIO_ROOT_PASSWORD}
restart: unless-stopped
# LiteLLM + Ollama (local AI inference)
litellm:
image: ghcr.io/berriai/litellm:main
networks:
- sovereign-net
volumes:
- ./litellm_config.yaml:/app/config.yaml
environment:
- LITELLM_MASTER_KEY=${LITELLM_KEY}
restart: unless-stopped
ollama:
image: ollama/ollama:latest
networks:
- sovereign-net
volumes:
- ollama-models:/root/.ollama
deploy:
resources:
reservations:
devices:
- driver: nvidia
count: 1
capabilities: [gpu]
postgres:
image: postgres:16-alpine
networks:
- sovereign-net
volumes:
- postgres-data:/var/lib/postgresql/data
environment:
- POSTGRES_PASSWORD=${POSTGRES_PASSWORD}
restart: unless-stopped
redis:
image: redis:7-alpine
networks:
- sovereign-net
volumes:
- redis-data:/data
restart: unless-stopped
volumes:
nextcloud-data:
minio-data:
postgres-data:
redis-data:
ollama-models:
This stack demonstrates: With six central services (NGINX, Nextcloud, MinIO, LiteLLM/Ollama, PostgreSQL, Redis),