1. The need for digital sovereignty and the choice for Kubernetes
Tech giants currently have a massive grip on our data and privacy. When using services from large cloud providers, it is often completely unclear where your data is physically stored, under which legal regime it falls, and who exactly has access to it. You hand over control completely.
To take back that control, you can use Nextcloud. This is the open-source alternative that allows you to keep all your documents, files, and communication in your own hands. The major advantage: you can run this entirely on your own hardware, so you know exactly where your data resides.
Why choose Kubernetes in such a scenario instead of a simple Docker script on a single server? Because you quickly realize that a serious set of components (file storage, database, caching, security, monitoring) shouldn't rely on a single point of failure. Kubernetes provides automation at scale: it distributes the load, automatically heals itself if a component fails (self-healing), and makes it possible to manage modular services strictly separated from each other without downtime.
2. Active Nextcloud Modules
In my setup, Nextcloud doesn't run as an isolated application, but is linked to several specialized modules to ensure functionality and security:
- Nextcloud Files (Core): For personal and shared file storage with full control over versioning and synchronization.
- Nextcloud Talk + High Performance Backend (HPB): For secure chat and video conferencing, where the HPB ensures video streams are processed smoothly and separately from the web application.
- Keycloak (IdP): Acts as the central Identity Provider for secure authentication and access management (Single Sign-On).
- ClamAV: Runs in the background as an automated virus scanner for all uploaded files.
- Grafana, Loki & Uptime Kuma: Together form the observability stack to continuously monitor logs, metrics, and uptime.
3. Architecture and Infrastructure
The underlying infrastructure runs on a Proxmox environment, where the Kubernetes cluster (managed via Rancher) is combined with dedicated virtual machines for specific tasks. Incoming internet traffic first passes through a strict firewall, after which MetalLB and Traefik securely route the traffic to the correct components within the cluster.
4. Design choices and motivation
Conscious architectural choices were made when setting up this environment:
The database outside the cluster
Although Kubernetes is flexible, I chose to run the MariaDB database on a dedicated virtual machine instead of inside the cluster. This makes managing stateful data much more reliable. At the hypervisor level (Proxmox), this allows me to easily create and restore snapshots and backups, completely shielded behind the firewall.
Automated management via GitOps
Nothing is manually configured on the production systems. The complete configuration is defined as code in a private Bitbucket repository. ArgoCD reads this repository and automatically synchronizes the actual state of the cluster with the desired state. This guarantees reproducibility and prevents human errors.
Security and network control
By using Cert-Manager for automatic SSL certificates, Traefik as an Ingress controller, and a strict separation of network components, the environment is optimally secured against unauthorized outside access, without compromising performance.