--- title: "Self-Hosting: Kosten, Betrieb und Checkliste" canonical: "https://pascalebeier.de/self-hosting" pubDate: "2026-09-05T11:45:00.000Z" updatedDate: "2026-09-05T11:45:00.000Z" author: Pascale Beier description: "Self-Hosting oder SaaS? Ein praktischer Leitfaden zu Kosten, Datenschutz, Updates und Backups – mit Betriebscheckliste und einem konkreten HitKeep-Beispiel." tags: [self hosting, self-hosted, software selbst hosten] categories: [Softwareentwicklung] --- **Self-Hosting bedeutet, dass du den Betrieb einer Anwendung selbst verantwortest.** Die Software kann auf einem Rechner zu Hause, einem eigenen Server oder einem gemieteten Cloud-Server laufen. Entscheidend ist, wer Installation, Konfiguration, Updates und Wiederherstellung übernimmt. Du musst dafür kein eigenes Rechenzentrum besitzen. Selbst hosten lohnt sich, wenn die gewonnene Kontrolle einen konkreten Nutzen hat und du den Betrieb dauerhaft leisten kannst. Ein günstiger Server und ein funktionierender Installationsbefehl reichen für diese Entscheidung nicht aus. In diesem Leitfaden zeige ich, wie ich die Entscheidung strukturieren würde: Welche Verantwortung bleibt beim Team, welche Kosten entstehen tatsächlich und welcher Nachweis sollte vor dem produktiven Einsatz vorliegen? Als konkretes Beispiel dient auch mein eigenes Analytics-Projekt HitKeep. **Ich bin dessen Entwickler**; die Einordnung ist deshalb keine unabhängige Produktempfehlung. Betriebscheckliste als Textdatei herunterladen – ohne Anmeldung, zum Ausfüllen im Repository oder im Team-Wiki. ## Self-Hosting, Managed Hosting und SaaS im Vergleich Diese Begriffe beschreiben unterschiedliche Verteilungen von Arbeit. Die genaue Grenze ergibt sich immer aus dem gebuchten Angebot und Vertrag. - **Eigene Hardware:** Du betreibst Hardware, Betriebssystem, Anwendung und Daten. Extern bleiben gegebenenfalls Dienste wie Internetzugang und Backups. - **Gemieteter Server:** Der Anbieter betreibt die physische Infrastruktur und je nach Angebot die Virtualisierung. Gast-Betriebssystem, Anwendung, Konfiguration und Daten bleiben deine Aufgabe. - **Managed Hosting:** Der Anbieter übernimmt ausdrücklich vereinbarte Aufgaben, etwa Systempflege oder Datenbankbetrieb. Anwendungseinstellungen und nicht abgedeckte Betriebsaufgaben bleiben bei dir. - **SaaS:** Der Anbieter betreibt das Produkt. Du verantwortest weiterhin dessen Nutzung, Benutzerrechte, fachliche Konfiguration und Datenorganisation. **Self-Hosting und Cloud schließen sich nicht aus.** Eine selbst betriebene Anwendung auf einem Cloud-Server bleibt Self-Hosting. Umgekehrt garantiert ein eigener Server noch keine Unabhängigkeit: DNS, E-Mail-Zustellung, Softwarelizenzen, Updates oder externe APIs können weiterhin von anderen Anbietern abhängen. Auch „Open Source“ und „self-hosted“ sind verschiedene Eigenschaften. Der Quellcode und seine Lizenz bestimmen, was du ändern und weitergeben darfst. Das Betriebsmodell bestimmt, wer die laufende Verantwortung trägt. Prüfe beides getrennt.
Verantwortung im Vergleich: eigene Hardware vollständig selbst betreiben; beim Mietserver die physische Infrastruktur abgeben; bei SaaS den Produktbetrieb abgeben. Nutzung, Rechte und Datenorganisation bleiben eigene Aufgaben.
Die Betriebsgrenze verschiebt sich, die Verantwortung verschwindet nicht. Bei Managed Hosting entscheidet der vereinbarte Leistungsumfang. Grafik anklicken zum Vergrößern.
## Wann ist selbst hosten sinnvoll? Ein guter Grund lässt sich konkret benennen: Du brauchst einen bestimmten Datenstandort, einen Betrieb ohne öffentliche Internetverbindung, eine besondere Integration oder einen Exportpfad, den ein SaaS-Angebot nicht liefert. Auch ein Lernprojekt kann ein guter Grund sein, solange der Ausfall nicht gleichzeitig wichtige Geschäftsabläufe blockiert. Für einen produktiven Dienst würde ich diese fünf Fragen beantworten: 1. **Was gewinnen wir?** Eine überprüfbare Anforderung, nicht nur das Gefühl von Kontrolle. 2. **Wer übernimmt den Betrieb?** Eine verantwortliche Person und eine Vertretung mit den nötigen Zugängen. 3. **Welcher Ausfall ist tragbar?** Wie lange darf der Dienst fehlen, und wie viele neue Daten dürfen verloren gehen? 4. **Können wir wiederherstellen?** Ein tatsächlich durchgeführter Restore mit dokumentiertem Ergebnis. 5. **Wie kommen wir wieder heraus?** Nutzbarer Export, verständliches Datenformat und ein realistischer Wechselweg. Wenn niemand Updates oder Wiederherstellung übernehmen kann, ist ein passendes Managed-Angebot oft die bessere Wahl. Das gilt besonders für zentrale Identitätssysteme, Passwortverwaltung, geschäftskritische Kommunikation oder Dienste, die außerhalb der Arbeitszeit verfügbar sein müssen. Die Bedeutung des Dienstes zählt mehr als die Einfachheit seiner Installation. ## Was kostet Self-Hosting wirklich? Vergleiche die Gesamtkosten mit einem funktional passenden Angebot. Neben Server und Speicher gehören Backup-Speicher, Domains, Überwachung, gegebenenfalls Lizenzen und die Arbeitszeit in die Rechnung. Beim Betrieb zu Hause kommen unter anderem Hardware, Strom und die Grenzen des Internetanschlusses hinzu. Eine einfache Monatsrechnung lautet: ```text Laufende Kosten = Infrastruktur + Backups + weitere Dienste + Betriebsstunden × interner Stundensatz + anteilige Einrichtung und Migration ``` **Rechenbeispiel mit frei gewählten Annahmen, keine Preis- oder Einsparungsbehauptung:** 15 Euro Infrastruktur, 5 Euro externe Backups und zwei Betriebsstunden zu je 60 Euro ergeben 140 Euro im Monat. Werden zwölf Stunden Einrichtung über zwölf Monate verteilt, kommen monatlich 60 Euro hinzu: insgesamt 200 Euro. Bei fünf statt zwei Betriebsstunden wären es 380 Euro. Diese Rechnung sagt nicht, dass Self-Hosting teuer sein muss. Sie zeigt, welche Annahme du prüfen musst: Wie viel eigene Arbeit braucht genau dieser Dienst? Ein Produkt, das Funktionen spart oder betriebliche Sonderanforderungen erfüllt, kann den Aufwand wert sein. Ein Serverpreis allein belegt das nicht. Vergleiche außerdem denselben Umfang: Speicher, Benutzer, Aufbewahrung, Support, Exportmöglichkeiten und Verfügbarkeitsbedarf. Ein Hobbyprojekt ohne Vertretung und eine betreute Team-Anwendung sind keine gleichwertigen Angebote. ## Datenschutz: mehr Gestaltungsspielraum, weiterhin Verantwortung Self-Hosting ermöglicht dir, Datenflüsse, Aufbewahrung und Zugriffsrechte gezielt zu gestalten. Es macht eine Anwendung aber nicht automatisch datenschutzkonform oder sicher. Prüfe mindestens, welche personenbezogenen Daten in Anwendung, Protokollen, Backups und Supportfällen entstehen. Beziehe Hosting, E-Mail-Versand, Fehlerberichte, externe Schriften, CDNs und Telemetrie ein. Ein in Deutschland gemieteter Server schließt andere Datenübermittlungen nicht automatisch aus. Bei personenbezogenen Daten bleiben unter anderem Zweck, Rechtsgrundlage, Löschfristen, Betroffenenrechte und angemessene technische und organisatorische Maßnahmen relevant. Soweit Auftragsverarbeitung vorliegt, gehört auch deren vertragliche Regelung dazu. Die [DSGVO im offiziellen EUR-Lex-Text](https://eur-lex.europa.eu/eli/reg/2016/679/oj?locale=de) ist dafür die Primärquelle, insbesondere Artikel 5, 6, 28 und 32. Dieser technische Entscheidungsrahmen ersetzt keine Prüfung deines konkreten Einsatzes. ## Vor dem Produktivbetrieb: sechs Dinge nachweisen ### 1. Zugänge und öffentliche Angriffsfläche Dokumentiere, wer administrative Rechte hat und wie diese entzogen werden. Nutze Mehrfaktor-Authentisierung, wo sie verfügbar ist, und sichere Wiederherstellungszugänge getrennt. Veröffentliche nur die benötigten Dienste. Administrationsoberflächen gehören nicht allein deshalb ungeschützt ins Internet, weil der Container dort startet. ### 2. Updates und Rückweg Lege fest, wo Sicherheitsmeldungen ankommen, wer sie bewertet und wie Updates getestet werden. Halte den installierten Versionsstand nachvollziehbar. Ein älteres Container-Image reicht als Rückweg nicht aus, wenn das Update die Datenbank verändert hat. Prüfe die vom Projekt unterstützten Upgrade- und Downgrade-Wege. ### 3. Persistente Daten und vollständige Backups Notiere alle benötigten Speicherorte: Datenbank, hochgeladene Dateien, Konfiguration, Schlüssel und gegebenenfalls Archive. Nutze für laufende Datenbanken deren unterstützte Sicherungsverfahren. Eine unkoordinierte Dateikopie kann einen inkonsistenten Stand erzeugen. Ein Backup auf demselben Server hilft nicht gegen dessen vollständigen Verlust. Lege mindestens eine geeignete Kopie außerhalb dieses Ausfallbereichs ab. Schütze Backups vor unberechtigtem Lesen und Löschen, und stelle sicher, dass die nötigen Entschlüsselungsschlüssel im Wiederherstellungsfall erreichbar sind. ### 4. Ein echter Wiederherstellungstest Definiere zuerst zwei Größen: **RPO** ist der maximal tolerierte Datenverlust als Zeitspanne, **RTO** die maximal tolerierte Zeit bis zur Wiederherstellung. Das sind Anforderungen, keine automatisch erreichten Eigenschaften eines Backup-Zeitplans. Stelle ein Backup auf einer getrennten Testumgebung wieder her. Prüfe Anmeldung, repräsentative Datensätze, Dateien und wichtige Funktionen. Miss, wie lange der gesamte Ablauf dauert – einschließlich Beschaffung des Ersatzsystems und der Zugänge. Notiere, bis zu welchem Datenstand die Wiederherstellung reicht. ### 5. Überwachung mit erreichbarem Empfänger Beobachte nicht nur, ob ein Prozess läuft. Prüfe eine relevante Funktion, freien Speicher und die Aktualität erfolgreicher Backups. Eine Alarmierung ist erst dann nützlich, wenn jemand sie erhält und weiß, was zu tun ist. Teste auch diesen Weg. ### 6. Export und Abschaltung Exportiere testweise Daten und prüfe, ob du sie außerhalb der Anwendung lesen oder im vorgesehenen Ziel importieren kannst. Dokumentiere, welche Einstellungen und Anhänge fehlen. Lege außerdem fest, wann alte Instanzen, Zugänge und Sicherungskopien nach einem Wechsel entfernt werden dürfen. ## Beispiel HitKeep: ein Prozess ist noch kein Betriebsplan Bei HitKeep ist ein kleiner Betriebsumfang Teil der Produktentscheidung. Die [Installationsdokumentation](https://hitkeep.com/guides/installation/) beschreibt eine Anwendung als Go-Binary mit eingebetteten Komponenten sowie Installationswege für bestehende Umgebungen. Du musst dafür nicht zusätzlich einen separaten Datenbank- und Queue-Server betreiben. Die wichtige Grenze bleibt aber bestehen: **weniger Dienste bedeuten nicht weniger Verantwortung für die Daten.** Die [Backup- und Restore-Dokumentation](https://hitkeep.com/guides/data/backups-and-restore/) beschreibt ausdrücklich die gemeinsam benötigten Datenbestände. Für die dort dokumentierte Version 2.13 gehören die Kontrolldatenbank und die Analytics-Datenbanken aller Mandanten dazu; bei aktivierter Archivierung außerdem die Archive. Nur eine vermeintlich zentrale Datei zu kopieren würde nicht reichen. Das Beispiel illustriert eine allgemeine Regel: Der Backup-Umfang folgt dem tatsächlichen Datenmodell, nicht der Anzahl laufender Prozesse. Lies nach einem Versionswechsel auch die Migrations- und Wiederherstellungshinweise. Die konkrete Anleitung zum jeweils eingesetzten Release ist maßgeblich. Falls du Analytics auswählst, hilft mein [Vergleich von Webanalyse-Tools](/webanalyse-tools-vergleich) bei der Produktentscheidung. Dieser Artikel behandelt die andere Frage: ob du den gewählten Dienst selbst betreiben solltest. Einen konkreten Installationsworkflow mit Composer findest du in [WordPress mit Bedrock auf Uberspace](/wordpress-mit-bedrock-auf-uberspace-installieren). ## Eine kleine Entscheidungsvorlage fürs Team Die [herunterladbare Betriebscheckliste](/downloads/self-hosting-checkliste.txt) bündelt Anforderungen, Kosten, Zuständigkeiten und Restore-Nachweis. Fülle sie für **einen konkreten Dienst** aus. Fehlt etwa die Vertretung oder ein erfolgreicher Restore, gehört das als offene Voraussetzung in die Entscheidung. Starte einen Pilot mit unkritischen Testdaten und einer klaren Grenze: Welche Funktion muss funktionieren, welcher Aufwand ist akzeptabel und welches Ergebnis führt zum Abbruch? Ein produktiver Rollout folgt erst nach den benötigten Nachweisen. So lernst du die tatsächlichen Betriebskosten kennen, bevor wichtige Daten davon abhängen. Wenn ihr bei der Abgrenzung von Anwendung, Infrastruktur und Betriebsverantwortung Unterstützung braucht, findet ihr meinen Ansatz in [Softwarearchitektur in der Praxis](/softwarearchitektur-praxis) und könnt mir über [Kontakt](/kontakt) euren konkreten Entscheidungsfall beschreiben. ## Quellen und Stand Stand: 5. September 2026. Neben den verlinkten HitKeep-Dokumentationen und der DSGVO wurde die [Self-Hosting-Einordnung von Hetzner](https://www.hetzner.com/de/self-hosting/) als Beispiel für den Betrieb auf gemieteter Infrastruktur herangezogen. Sie stammt von einem Hostinganbieter und ist keine unabhängige Wirtschaftlichkeitsstudie. Kostenrechnung, Checkliste und Entscheidungskriterien sind ein transparenter Arbeitsrahmen; sie behaupten keine gemessenen Einsparungen, Ausfallraten oder Testergebnisse.