Warum wir auf Self-Hosted Open Source setzen

Die Frage nach der Kontrolle

Wer als europäisches Unternehmen Software entwickelt und betreibt, kommt an einer Frage nicht mehr vorbei: Wo liegen unsere Daten, und wer hat Zugriff darauf? Seit die DSGVO 2018 in Kraft getreten ist, hat sich das Bewusstsein für Datensouveränität spürbar verändert. Aber bei uns war es nicht allein die Regulierung, die den Ausschlag gab. Es war die Erkenntnis, dass wir als Consultancy, die Kunden bei Architekturentscheidungen berät, selbst eine klare Haltung zu unserer eigenen Infrastruktur brauchen.

Wir haben uns vor einiger Zeit entschieden, unsere interne Infrastruktur auf Self-Hosted Open-Source-Lösungen aufzubauen. Nicht aus ideologischen Gründen, sondern aus pragmatischen. In diesem Beitrag erklären wir, warum wir diesen Weg gewählt haben, was unser Stack umfasst und wo die ehrlichen Trade-offs liegen.

Warum Self-Hosted?

Drei Faktoren haben unsere Entscheidung bestimmt.

Datensouveränität. Unsere Kundendaten, internen Dokumente, Quellcode und Kommunikation liegen auf Servern, die wir kontrollieren. Keine US-amerikanischen Hyperscaler, kein Cloud Act, keine Frage, ob ein Drittanbieter unsere Daten für eigene Zwecke auswertet. Wenn ein Kunde fragt, wo seine Projektdaten liegen, können wir eine klare Antwort geben.

Unabhängigkeit von Anbietern. Vendor Lock-in ist ein schleichendes Problem. Man beginnt mit einem kostenlosen Tier, integriert immer tiefer, und irgendwann ist der Wechsel prohibitiv aufwändig. Oder der Anbieter ändert seine Preisstruktur, seine Nutzungsbedingungen oder wird aufgekauft. Wer seine Infrastruktur selbst betreibt, behält die Entscheidungsfreiheit. Wenn eine Software nicht mehr passt, migriert man -- auf eigenen Zeitplan und eigenen Bedingungen.

Kostenkontrolle. SaaS-Preise skalieren pro Nutzer und pro Monat. Für ein kleines Team mag das überschaubar sein. Aber die Kosten addieren sich schnell, wenn man Git-Hosting, Dateispeicher, Identity Management, CMS, Projektmanagement und Monitoring separat bei verschiedenen Anbietern bucht. Unsere Server laufen mit planbaren Fixkosten. Die Hardware ist einmal angeschafft, die Software kostenlos.

Unser Stack

Über die vergangenen Jahre haben wir einen Stack zusammengestellt, der unsere täglichen Anforderungen abdeckt. Alle Dienste laufen als Container auf unserem eigenen Kubernetes-Cluster.

Gitea ersetzt GitHub oder GitLab als Git-Hosting-Plattform. Gitea ist in Go geschrieben, extrem ressourcenschonend und bietet alles, was wir brauchen: Repositories, Pull Requests, Issues, eine brauchbare Web-Oberfläche und eine gut dokumentierte API. Der Ressourcenverbrauch ist im Vergleich zu einer selbst gehosteten GitLab-Instanz minimal -- und für ein Team unserer Größe ist das ein relevanter Faktor.

Keycloak übernimmt das Identity und Access Management. Single Sign-On für alle internen Dienste, Nutzerverwaltung, Rollenvergabe, Anbindung über OpenID Connect und SAML. Was man sonst an Auth0 oder Okta auslagern würde, läuft bei uns auf eigener Infrastruktur. Die initiale Konfiguration von Keycloak ist aufwändiger als bei einem gehosteten IAM-Dienst, aber dafür haben wir die volle Kontrolle über Realms, Flows und Policies.

Nextcloud dient als Dateiablage und Kollaborationsplattform. Dokumente, Kalender, Kontakte -- alles an einem Ort, ohne dass Dateien auf Drittanbieter-Servern landen. Die Nextcloud-Apps erweitern die Plattform um Funktionalitäten wie Kanban-Boards und gemeinsame Texteditierung. Nicht alles davon erreicht die Qualität der Google- oder Microsoft-Pendants, aber es erfüllt seinen Zweck und die Daten bleiben bei uns.

Directus setzen wir als Headless CMS ein. Blog-Beiträge, Website-Inhalte und strukturierte Daten werden über eine saubere REST- und GraphQL-API bereitgestellt. Directus sitzt direkt auf der Datenbank und generiert die API automatisch aus dem Schema. Für Entwickler ist das ein deutlich angenehmeres Arbeiten als mit klassischen CMS-Systemen.

Dazu kommen Prometheus und Grafana für Monitoring und Alerting, ein eigener Mail-Server und diverse kleinere Dienste, die sich über die Zeit angesammelt haben.

Die Plattform darunter

Unser gesamter Stack läuft auf Kubernetes, das wir auf eigenen physischen Servern betreiben. Als Host-Betriebssystem nutzen wir NixOS, das uns durch seine deklarative Konfiguration eine reproduzierbare und nachvollziehbare Infrastruktur ermöglicht. Die eigentlichen Anwendungen laufen ausschließlich als Container innerhalb von Kubernetes.

Kubernetes auf eigener Hardware zu betreiben ist kein triviales Unterfangen. Aber als Unternehmen, das Kunden bei genau solchen Themen berät, ist es gleichzeitig eine Investition in unsere eigene Kompetenz. Wir erleben die Probleme, die unsere Kunden haben, am eigenen Leib -- und können deshalb besser beraten.

Die ehrlichen Trade-offs

Self-Hosting hat seinen Preis, und es wäre unehrlich, das zu verschweigen.

Operativer Aufwand. Updates, Backups, Monitoring, Troubleshooting -- das alles liegt in unserer Verantwortung. Wenn Keycloak nach einem Update nicht mehr startet, gibt es keinen Support-Ticket-Button. Man liest die Release Notes, prüft die Changelogs und debuggt selbst. Das kostet Zeit, die man bei einem SaaS-Produkt nicht investieren müsste.

Verfügbarkeit ist unsere Aufgabe. Wenn ein Dienst ausfällt, sind wir die Einzigen, die das beheben können. Es gibt kein SLA eines Anbieters, hinter dem man sich verstecken kann. Unsere Kubernetes-Infrastruktur federt einiges ab -- Pods werden automatisch neu gestartet, Nodes können ausfallen, ohne dass der gesamte Stack betroffen ist. Aber die letzte Verantwortung liegt bei uns.

Kubernetes-Expertise ist Voraussetzung. Self-Hosting auf dem Niveau, das wir betreiben, setzt fundiertes Wissen über Container-Orchestrierung voraus. Ohne Kubernetes-Erfahrung würde der Betrieb dieser Dienste deutlich aufwändiger und fehleranfälliger sein. Für uns als Kubernetes-Consultancy ist das kein Problem -- für andere Unternehmen kann es ein ernsthaftes Hindernis sein.

Nicht alles lohnt sich. Wir hosten nicht alles selbst. Für E-Mail-Zustellung an externe Empfänger nutzen wir einen spezialisierten Anbieter, weil die Reputation-Management-Komplexität den Eigenaufwand nicht rechtfertigt. Auch bei Diensten, die wir nur sporadisch nutzen und die keinen sensiblen Daten berühren, greifen wir pragmatisch auf SaaS zurück. Self-Hosting ist eine bewusste Entscheidung pro Dienst, kein Dogma.

Für wen ist Self-Hosting sinnvoll?

Self-Hosting auf Kubernetes ist kein Ansatz für jeden. Wer kein Team mit Infrastruktur-Erfahrung hat, wird mehr Zeit mit dem Betrieb als mit dem eigentlichen Geschäft verbringen. Die Einstiegshürde ist real.

Sinnvoll ist es für Unternehmen, die Kubernetes-Kompetenz ohnehin im Haus haben, die Wert auf Datensouveränität legen und die bereit sind, den operativen Mehraufwand als Investition in Unabhängigkeit und Kompetenz zu betrachten. Für uns trifft das zu.

Die Werkzeuge sind da. Open-Source-Projekte wie Gitea, Keycloak, Nextcloud und Directus haben in den vergangenen Jahren eine Reife erreicht, die Self-Hosting vom Bastelprojekt zur ernsthaften Alternative gemacht hat. Kubernetes hat die Deployment- und Betriebskomplexität drastisch reduziert. Was vor fünf Jahren noch unverhältnismäßig aufwändig gewesen wäre, ist heute mit vertretbarem Aufwand realisierbar.

Fazit

Unsere Entscheidung für Self-Hosted Open Source war keine ideologische, sondern eine strategische. Datensouveränität, Vendor-Unabhängigkeit und Kostenkontrolle sind handfeste Vorteile, die den Mehraufwand im Betrieb rechtfertigen. Nicht für jedes Unternehmen, aber für uns.

Wer die Kompetenz hat und den Aufwand nicht scheut, gewinnt etwas, das kein SaaS-Anbieter verkaufen kann: vollständige Kontrolle über die eigene Infrastruktur. In einer Zeit, in der Datenhoheit zunehmend zum Wettbewerbsfaktor wird, ist das kein geringer Vorteil.