Self-Hosting ist eine Personalfrage: Was Startups übernehmen

Self-Hosting ist für Startups eine Personalfrage, weil es laufende Arbeit ins eigene Unternehmen verlagert: Updates, Zugriffssteuerung, Backups, Wiederherstellungstests, Monitoring, Störungsbearbeitung und ein späterer Ausstieg. Definieren Sie jede Aufgabe, die verantwortliche Person, die nötige Vertretung und den Nachweis. Erst dann entscheiden Sie, was Sie automatisieren, intern aufbauen, neu zuordnen, extern vergeben, durch eine Einstellung abdecken oder als Managed Service beziehen.

Der Server ist nur der sichtbare Teil dieser Entscheidung. Die eigentliche Verpflichtung beginnt nach der Installation und bleibt bestehen, solange der Dienst für Ihr Unternehmen wichtig ist.

Was hat Cloud in a Bottle eigentlich veröffentlicht?

Cloud in a Bottle ist eine frühe Open-Source-Plattform für eine persönliche Cloud. Containerisierte Webanwendungen sollen sich damit leichter auf einem Server installieren und betreiben lassen, den Sie selbst kontrollieren. Die Veröffentlichung eignet sich als Fallbeispiel: Das Projekt verspricht eine einfachere Bedienung, während seine Dokumentation zeigt, welche Arbeit bei der betreibenden Person verbleibt.

Der Beitrag zur Veröffentlichung vom 5. September beschreibt einen Ubuntu-Host mit Web-Dashboard, Rootless-Containern, einer zentralen Anmeldung für die betreibende Person und zugriffsgesteuerten Verbindungen zwischen Anwendungen. Nach Angaben des Projekts lässt sich die Software selbst hosten, erfasst keine Telemetriedaten und wurde mehr als sechs Monate lang intern getestet. Das sind Aussagen des Projektteams, keine unabhängige Sicherheitsprüfung oder Zuverlässigkeitsstudie.

Für eine Personalentscheidung ist das Handbuch von Cloud in a Bottle aussagekräftiger als der Text zur Veröffentlichung. Es richtet sich ausdrücklich an einen „Owner“, der eine Instanz installiert, Anwendungen betreibt, Daten schützt und Fehler untersucht. Diese Bezeichnung ist entscheidend. Einfachere Software kann den Aufwand für eine Aufgabe senken, doch die Zuständigkeit bleibt.

Für die Bereitstellung in einer öffentlichen Cloud verlangt die Einrichtungsanleitung eine eigene Domain samt Zugriff auf die DNS-Einstellungen, eine statische öffentliche IPv4-Adresse, einen frisch installierten Rechner mit Ubuntu 24.04, privilegierten Zugriff für die Einrichtung, erreichbare Web- und DNS-Ports sowie ein kompatibles Dateisystem. Die DNS-Zone der Domain wird an diesen Rechner delegiert. Anschließend legt das Installationsprogramm einen unprivilegierten Benutzer an, richtet Rootless Podman ein und installiert einen systemd-Dienst.

Dasselbe Muster zeigt die Backup-Anleitung. Jede Instanz enthält eine auf restic basierende Backup-Anwendung. Laut Dokumentation wird jedoch nichts gesichert, bevor Sie die Anwendung eingerichtet haben. Sie wählen das Ziel, verwahren das nicht wiederherstellbare Passwort für das Repository getrennt, legen den Zeitplan fest und führen ein Backup aus, um die Verbindung zu prüfen.

Der Zustand des Routers, einschließlich Datenbank, TLS-Zertifikaten und Identitätsschlüsseln, liegt außerhalb des Anwendungs-Backups. Lokal gespeicherte Archivdaten haben keine Kopie außerhalb des Rechners, sofern Sie selbst keine anlegen.

Die Sicherheitsdokumentation ist ebenso offen. Anwendungen laufen standardmäßig isoliert in Rootless-Containern, können aber zusätzliche Berechtigungen anfordern. Die Aufnahme in den Katalog ist keine Sicherheitsgarantie. Spätere Änderungen im Ursprungsprojekt werden nicht automatisch erneut geprüft. Die betreibende Person entscheidet, ob sie einer Anwendung die angeforderten Zugriffe anvertraut.

Cloud in a Bottle kann den Aufwand für die Installation senken. Die eigene Dokumentation rechtfertigt jedoch weder die Bezeichnung „wartungsfrei“ noch Aussagen über automatische Notfallwiederherstellung, Hochverfügbarkeit oder einen sicheren Betrieb beliebiger nicht vertrauenswürdiger Software. Das ist kein Vorwurf an das Projekt. Es ist die Verantwortungsgrenze, die Sie vor dem Einsatz eines selbst gehosteten Systems verstehen müssen.

Warum ist Self-Hosting eine Personalfrage?

Self-Hosting verändert, wer Betriebsaufgaben erledigt und deren Ergebnis prüft. Es beseitigt nicht jeden Anbieter und verschafft Ihrem bestehenden Team weder automatisch die nötigen Fähigkeiten noch die erforderliche Verfügbarkeit.

Das AWS-Modell der geteilten Verantwortung macht diese Grenze für Cloud-Infrastruktur sichtbar. In dem beschriebenen Modell betreibt AWS die physischen Anlagen sowie die Host- und Virtualisierungsebenen. Die Kundenseite bleibt für das Gastbetriebssystem, Updates, Anwendungssoftware und die Konfiguration der Firewall verantwortlich. AWS weist zudem darauf hin, dass sich die Grenze mit dem gewählten Dienst verändert.

Stellen Sie deshalb bei jeder Option dieselben Fragen: Welche Aufgaben sind enthalten, welche verbleiben bei Ihnen und wer prüft die Übergabe? Die Bezeichnung „Managed“ genügt nicht. Laut README des Cloud-in-a-Bottle-Repositorys stellt Imbue einen Rechner bereit, richtet den SSH-Schlüssel der Kundenseite ein und übergibt anschließend den Rechner. Daraus folgen keine laufenden Pflichten für Patches, Monitoring, Wiederherstellungstests, Störungsbearbeitung oder einen Bereitschaftsdienst rund um die Uhr. Welche Aufgaben tatsächlich übertragen werden, ergibt sich erst aus den aktuellen Leistungsbedingungen.

Die Personalfrage ergibt sich aus der Aufgabenliste. Fehlen für die verbleibende Arbeit eine fachkundige verantwortliche Person, eine Vertretung oder freie Kapazität, besteht eine personelle Lücke. Dafür gibt es mehrere Lösungen. Eine Einstellung ist nur eine davon und nicht die erste Annahme.

Welche Arbeit beginnt nach der Installation?

Gliedern Sie Self-Hosting in beobachtbare und prüfbare Aufgaben, statt pauschal „DevOps“ verantwortlich zu machen. Die folgenden sieben Bereiche bieten einen praktischen Ausgangspunkt, bevor ein geschäftlich relevanter Dienst in Betrieb geht.

1. Wartung von Host und Plattform

Jemand muss unterstützte Versionen verfolgen, die Dringlichkeit von Updates bewerten, Änderungen einspielen, den Zustand des Dienstes prüfen und ein fehlgeschlagenes Update beheben. Eine Schaltfläche kann ein Update ausführen. Sie kann weder Ihr Wartungsfenster festlegen noch die geschäftlichen Folgen verantworten.

NIST SP 800-40 Rev. 4 definiert Patch-Management als Ermitteln, Priorisieren, Beschaffen, Installieren und Prüfen von Patches und Upgrades. Die Prüfung gehört zur Aufgabe. Sie ist keine freiwillige Nacharbeit, nachdem die Schaltfläche Erfolg gemeldet hat.

2. Vertrauen in Anwendungen und Berechtigungen

Jemand entscheidet, welcher Code ausgeführt wird und worauf er zugreifen darf. Dokumentieren Sie Quelle, angeforderte Berechtigungen, Weg für Updates und Prüfentscheidung. Isolation verringert die Angriffsfläche, macht unbekannten Code aber nicht vertrauenswürdig.

3. Identitäten und privilegierte Zugriffe

Erfassen Sie jeden Kontrollpunkt: Registrar, DNS, Cloud-Konto, SSH, Eigentümerkonto der Anwendung, Backup-Speicher, Wiederherstellungsgeheimnis und Support des Anbieters. Legen Sie fest, wie Zugriffe vergeben, geprüft und entzogen werden. Der Leitfaden zur Fehleranalyse von Cloud in a Bottle weist darauf hin, dass das Zurücksetzen des Eigentümerpassworts bestehende Sitzungen und API-Tokens nicht ungültig macht. Der Widerruf ist eine eigene Aufgabe.

4. Backups und Wiederherstellung

Ein installiertes Backup-Werkzeug ergibt noch kein wiederherstellbares System. Sie brauchen ein unabhängiges Ziel, geschützte Zugangsdaten, einen Zeitplan, Aufbewahrungsregeln, eine Sicherung der ausgeschlossenen Zustände und einen Wiederherstellungstest. Die Übersicht zum NIST CSF 2.0 empfiehlt regelmäßige Backups, mindestens einen häufig aktualisierten Offline-Datenbestand zum Schutz vor Ransomware sowie Tests, die eine erfolgreiche Wiederherstellung belegen.

5. Erkennung und Kapazität

Legen Sie fest, was Sie erkennen müssen, bevor ein Kunde eine Störung meldet. Protokolle helfen bei der Untersuchung. Monitoring bestimmt, welche Zustände wichtig sind, prüft sie und leitet ein verwertbares Signal an eine handlungsfähige Person weiter. Berücksichtigen Sie je nach Dienst Speicherplatz, Arbeitsspeicher, Zertifikate, Erreichbarkeit des Netzwerks, Backup-Ergebnisse und Symptome der Anwendung.

6. Störungsbearbeitung und Wiederherstellung

Benennen Sie, wer eine Störung ausrufen darf, wer auf das System zugreifen kann, wann eskaliert wird und wer die Wiederherstellung bestätigt. Übernehmen Sie den Prozess eines großen Unternehmens nicht ungeprüft. Richten Sie die Reaktion am geschäftlichen Schaden und an Ihrem tatsächlichen Leistungsversprechen aus.

Für Warteschlangen, Wiederholungsversuche und Failover lesen Sie unseren Beitrag über die Ausfallsicherheit von KI-gestützten Recruiting-Abläufen. Fragen Sie an dieser Stelle, wer die Wiederherstellung durchführen und das Ergebnis belegen kann.

7. Ausstieg und Wissenstransfer

Planen Sie, wie eine andere Person oder ein anderer Anbieter Zugangsdaten, Konfiguration, Daten und Betriebswissen erhält. Prüfen Sie, ob sich der Dienst ohne die ursprünglich verantwortliche Person und ohne den ausgefallenen Host übertragen lässt. Kontrolle ohne tragfähige Ausstiegsstrategie kann Sie dennoch binden.

Der erforderliche Umfang richtet sich nach den Folgen. Ein privates Experiment und das einzige System mit Kundendaten brauchen nicht dieselbe Absicherung. Leiten Sie Ziele für Wiederherstellung, Datenverlust und Patches aus den Folgen für Ihr Unternehmen ab. Übernehmen Sie keine pauschalen Zahlen von einem Anbieter oder aus dem Betriebshandbuch eines anderen Unternehmens.

Erstellen Sie vor der Auswahl eine Verantwortungsmatrix für den Betrieb

Mit einer einzigen Matrix übersetzen Sie Architektursprache in benannte Aufgaben, Vertretung und Nachweise. Füllen Sie sie aus, bevor Sie eine Plattform wählen. Aktualisieren Sie sie nach einem echten Pilotbetrieb, der den zuvor übersehenen Aufwand sichtbar macht.

Legen Sie für jede Aufgabe eine eigene Zeile an, nicht nur eine Zeile für „Betrieb“. „Alex betreut den Server“ verschleiert zu viel. Prüfbar wird die Aussage erst so: „Alex spielt Plattform-Updates ein; Sam kann den Zugriff wiederherstellen; Änderungsprotokoll und Zustandsprüfung belegen den Abschluss.“

Die Spalte „Nachweis“ hält die Übung ehrlich. „Backups aktiviert“ beschreibt eine Konfiguration. Eine datierte Wiederherstellung in eine saubere Umgebung ist ein Nachweis. „Protokolle vorhanden“ beschreibt eine Funktion. Ein Testalarm, der die aktuell zuständige Person erreicht, ist ein Nachweis.

Die Spalte „Aufwand“ schützt Ihre Produktkapazität. Geplante Wartung ist nur ein Teil der Kosten. Berücksichtigen Sie Unterbrechungen, Recherche, Abstimmung mit Anbietern, Dokumentation, Übungen und den Aufwand, der durch auf eine Person konzentriertes Wissen entsteht. Machen Sie aus der Matrix keinen scheingenauen Gesamtkostenrechner. Anbieterpreis, Infrastruktur, Arbeitszeit, Migration, Compliance, Ausfallzeit und Opportunitätskosten brauchen weiterhin ausdrücklich dokumentierte Annahmen.

Brauchen Sie für Self-Hosting eine DevOps- oder SRE-Fachkraft?

Nein. Definieren Sie die Arbeit, bevor Sie daraus eine Stelle machen. Eine Aufgabe kann bei einer vorhandenen Fachkraft, einer Rotation, einem externen Dienstleister, einem Managed-Service-Anbieter, einer neuen Fachkraft oder einer Kombination daraus liegen.

Das NICE Framework trennt eine „Work Role“ von einer Stelle. Eine Work Role fasst Aufgaben zusammen, für die eine Person oder ein Team verantwortlich ist. Sie ist nicht gleichbedeutend mit einem Beruf. NICE empfiehlt, beim Aufbau eines Teams mit der notwendigen Arbeit zu beginnen. Danach lassen sich anhand der Aufgaben, Kenntnisse und Fähigkeiten Lücken erkennen sowie Einstellungen und Personalentwicklung verbessern.

NIST SP 1308 vom März 2026 verbindet Cyberrisiken mit Personalplanung. Je nach Risikotoleranz, Zielen, Budget und bestehender Belegschaft kann ein Unternehmen einstellen, intern qualifizieren, Zuständigkeiten neu ordnen oder die Risikobehandlung verändern. Das Dokument fragt außerdem, welche Funktionen automatisiert werden sollten, wo menschliches Urteilsvermögen nötig ist, wer die erforderlichen Fähigkeiten hat und wie die Leistungsfähigkeit von Anbietern bewertet wird.

Diese Reihenfolge verhindert zwei häufige Fehler. Der erste: Eine motivierte Entwicklerkraft soll dauerhafte Betriebsarbeit übernehmen, ohne dass dafür Produktkapazität frei wird. Der zweite: Sie schreiben eine unscharfe „DevOps“-Stelle aus, die Plattform-Engineering, Sicherheit, Support, Compliance, Büro-IT und jede andere herrenlose technische Aufgabe bündelt.

Zeigt Ihre Matrix eine zusammenhängende, dauerhafte Plattformrolle, hilft unser Leitfaden zur Einstellung eines Platform Engineers bei der Gestaltung des Auswahlverfahrens. Zeigt sie dagegen nur wenige regelmäßige Aufgaben und seltene Spezialarbeiten, ist eine Vollzeitstelle womöglich die falsche Antwort.

Schließen Sie jede Verantwortungslücke gezielt

Wählen Sie die kleinste Lösung, die fachkundige Verantwortung, belastbare Vertretung und überprüfbare Ergebnisse sicherstellt. Verschiedene Zeilen derselben Matrix können zu unterschiedlichen Antworten führen.

Automatisieren Sie wiederkehrende Ausführungsschritte

Automatisieren Sie Backups, Update-Prüfungen, Zertifikatserneuerung, Monitoring-Abfragen oder Routine-Deployments, wenn das Werkzeug zuverlässig ist. Eine Person bleibt für Konfiguration, Ausnahmen und Prüfung verantwortlich. Automatisierung verändert die Aufgabe: Statt jeden Schritt auszuführen, pflegen Sie den Kontrollmechanismus und behandeln Fehler.

Qualifizieren Sie eine vorhandene verantwortliche Person

Bauen Sie interne Fähigkeiten auf, wenn die Arbeit begrenzt ist, zur bestehenden Rolle passt und geschützte Lernzeit zur Verfügung steht. Sorgen Sie für eine zweite Person, Dokumentation und eine sichere Übungsumgebung. Weiterbildung ohne freie Kapazität fügt einer bereits vollen Stelle nur weitere Verantwortung hinzu.

Ordnen Sie Verantwortung und Vertretung neu

Manchmal ist das Wissen vorhanden, aber die Zuständigkeit bleibt unausgesprochen. Benennen Sie die hauptverantwortliche Person, die Vertretung, den Eskalationsweg, die Entscheidungsbefugnis und den Prüfturnus. Eine Rotation kann Wissen verteilen, funktioniert aber nur, wenn alle Beteiligten Zugang und Übung haben.

Beauftragen Sie ein klar definiertes Ergebnis

Setzen Sie Fachleute für Migration, Absicherung, regelmäßige Prüfung, Wiederherstellungstests oder Support mit einer klaren Reaktionszusage ein. Halten Sie Aufgabe und Nachweis im Vertrag fest. „Unterstützung bei Infrastrukturfragen nach Bedarf“ ist keine Verantwortungsgrenze.

Stellen Sie für dauerhafte Arbeit ein

Stellen Sie ein, wenn die Verantwortung dauerhaft und wesentlich ist und genügend zusammenhängende Aufgaben für eine klare Rolle umfasst. Zeigen Sie Kandidatinnen und Kandidaten die tatsächlichen Auswirkungen des Dienstes, den Wartungsaufwand, die Erwartungen bei Störungen, die Befugnisse und das Budget für Verbesserungen. Stellen Sie niemanden nur deshalb ein, um einen untragbaren Bereitschaftsdienst zu übernehmen.

Wenn die Matrix eine Einstellung stützt, prüfen Sie Finanzierung und Zeitpunkt im umfassenderen Einstellungsplan für Ihr Startup.

Nutzen Sie einen Managed Service

Wählen Sie einen Managed Service, wenn der Einkauf klar definierter Leistungen sinnvoller ist als der interne Aufbau. Prüfen Sie, welche Patches, Monitoring-Aufgaben, Backups, Wiederherstellungen und Supportleistungen der Anbieter übernimmt. Dokumentieren Sie außerdem, was bei Ihnen verbleibt, etwa Anwendungskonfiguration, Zugriffsverwaltung, Datenklassifizierung, Entscheidungen bei Störungen und die Ausstiegsplanung.

Prüfen Sie die Entscheidung vor der Festlegung

Führen Sie einen zeitlich begrenzten Pilotbetrieb durch, der Menschen und Wiederherstellung prüft, nicht nur die Installation. Eine erfolgreiche Demo belegt nur, dass der vorgesehene Ablauf funktioniert. Sie beweist nicht, dass Ihr Team den Dienst dauerhaft verantworten kann.

Nutzen Sie drei Tests:

1. Vertretungstest: Nehmen Sie die hauptverantwortliche Person aus der Übung. Findet die Vertretung die Dokumentation, erhält sie Zugriff auf die Konten, versteht sie den Alarm und kann sie die freigegebene Maßnahme ergreifen?
2. Wiederherstellungstest: Beginnen Sie in einer sauberen Umgebung. Kann das Team die vereinbarten Daten und die Konfiguration wiederherstellen, ohne auf den ausgefallenen Host oder das Gedächtnis einer einzelnen Person angewiesen zu sein?
3. Kapazitätstest: Messen Sie im Pilotbetrieb geplante Arbeit und Unterbrechungen. Kann das Team beides bewältigen, ohne wichtigere Aufgaben fallen zu lassen oder eine riskante Überlastung zu verursachen?

Googles SRE-Leitfaden für Bereitschaftsdienste betont klare Eskalationswege, definierte Abläufe für Störungen, verwertbare Alarme, Nachbesprechungen und die Begrenzung der betrieblichen Belastung. Diese Erkenntnisse stammen aus dem Umfeld von Google. Übernehmen Sie die dortigen Teamgrößen daher nicht als Grenzwert für ein Startup. Entscheidend ist: Dauerhafte Verantwortung braucht echte Vertretung und eine tragbare Zahl an Unterbrechungen.

Legen Sie die Auslöser für eine erneute Prüfung vor dem Start fest. Prüfen Sie die Zuständigkeiten erneut, wenn die Nutzung steigt, der Dienst geschäftskritisch wird, sich die Häufigkeit der Störungen ändert, eine Schlüsselperson ausscheidet, sich ein Vertrag ändert oder der letzte Wiederherstellungsnachweis zu alt wird. Eine vernünftige Entscheidung im Pilotbetrieb kann durch Veränderungen im Unternehmen unverantwortbar werden.

Die Matrix beweist nicht, dass Self-Hosting günstiger, sicherer, privater oder zuverlässiger ist als ein Managed Service. Diese Ergebnisse hängen von den verglichenen Diensten, der Architektur, den Fähigkeiten, den Verträgen und dem tatsächlichen Betrieb ab. Wenn Ihre Begründung eine pauschale Überlegenheit voraussetzt, ist sie noch nicht tragfähig.

Wo hilft Kit, wenn Sie eine dauerhafte Personallücke feststellen?

Kit hilft Ihnen bei einem strukturierten Einstellungsprozess, nachdem Sie entschieden haben, dass eine Verantwortungslücke eine neue Fachkraft erfordert. Kit trifft weder die Entscheidung für Self-Hosting noch betreibt es das System für Sie.

Die Verantwortungsmatrix erstellen Sie außerhalb von Kit. Kit erfasst keine Infrastruktur, erstellt keine Personalprognosen für deren Betrieb, modelliert keine Self-Hosting-Kosten, wählt keine Plattform, überwacht keine Hosts, spielt keine Patches ein, konfiguriert keine Backups, prüft keine Wiederherstellungen und verwaltet keine Bereitschaftsplanung für den Infrastrukturbetrieb. Kit bietet Kunden auch kein Self-Hosting an. Ebenso wenig entscheidet es, ob die Arbeit bei einer angestellten Person, einem Auftragnehmer oder einem Anbieter liegen sollte.

Wenn die Nachweise eine Einstellung stützen, machen Sie aus der Aufgabenliste eine klar umrissene Rolle. Mit den Prozessvorlagen und linear angeordneten Phasen von Kit können Sie die in der Matrix benannten Ergebnisse und das erforderliche Urteilsvermögen prüfen. Dafür stehen GitHub-gestützte Code-Aufgaben, integrierte oder über Calendly geplante Interviews und unabhängige, nach Kriterien gewichtete Bewertungen zur Verfügung. Kit führt den Code einer Aufgabe nicht aus, bewertet ihn nicht automatisch, unterstützt keine Terminplanung mit Cal.com und gewichtet die Stimmen einzelner Prüfer nicht unterschiedlich. Begrenzen Sie den Umfang der Aufgabe und verlangen Sie keine unbezahlte Arbeit am Produktivsystem.

Die Reihenfolge ist entscheidend: erst die Arbeit, dann die Verantwortung, danach die Art der Abdeckung und zuletzt das Auswahlverfahren. So wird aus einer Serverentscheidung nicht unbemerkt die Dauerbelastung einer einzelnen Fachkraft. Zugleich wächst eine vorübergehende Aufgabe nicht zur falschen Vollzeitstelle heran.