Self-Hosting: Wann sich ein eigener Server lohnt

Die Frage „Lohnt sich Self-Hosting?” wird fast immer als Kostenfrage gestellt und als Kontrollfrage beantwortet. Beides trifft nicht den Punkt, an dem selbst betriebene Systeme in der Praxis scheitern.

Der Punkt liegt hinter der Installation. Eine Anwendung ist an einem Nachmittag eingerichtet. Danach beginnt ein Betrieb, der weiterläuft, wenn der Nachmittag längst vergessen ist: Sicherheitsupdates, Sicherungen, deren Wiederherstellung tatsächlich geprüft wurde, Überwachung, Zertifikate, Kapazität und eine Person, die erreichbar ist, wenn um 7:40 Uhr nichts mehr geht.

Dieser Beitrag beschreibt genau diese Betriebsseite. Die Frage nach Lizenz- gegen Betriebskosten behandelt der Beitrag Open Source oder proprietär: Was Sie wirklich zahlen, die Frage nach Abhängigkeiten und Ausstiegswegen der Beitrag Open Source und digitale Souveränität.

Sie installieren keine Software, Sie übernehmen einen Dienst

Bei einer SaaS-Anwendung kaufen Sie nicht nur Funktionen. Sie kaufen mit, dass jemand anderes nachts patcht, Backups fährt, Kapazität nachlegt und im Störungsfall aufsteht. Diese Leistungen sind im monatlichen Preis unsichtbar enthalten – und sie verschwinden nicht, wenn Sie den Anbieter durch einen eigenen Server ersetzen. Sie wechseln nur den Adressaten.

Die folgenden vier Pflichten sind dabei keine Kür, sondern der Mindestumfang. Sie stammen nicht aus Erfahrungswerten, sondern aus den Bausteinen, die das BSI im IT-Grundschutz-Kompendium (Edition 2023) für den Betrieb formuliert.

Updates sind ein Prozess, kein gelegentlicher Klick

Der Baustein OPS.1.1.3 „Patch- und Änderungsmanagement” formuliert als Basis-Anforderung: „Grundsätzlich SOLLTEN Patches zeitnah nach Veröffentlichung eingespielt werden.” Dazu gehört ausdrücklich auch die Gegenrichtung: „Wenn ein Patch nicht eingespielt wird, MÜSSEN die Entscheidung und die Gründe dafür dokumentiert werden.”

Das ist mehr, als es klingt. Es bedeutet, dass jemand regelmäßig prüft, was veröffentlicht wurde, ob es die eigene Version betrifft, ob es in einem Wartungsfenster eingespielt werden kann und was passiert, wenn es schiefgeht – denn Rückfall-Lösungen verlangt derselbe Baustein ebenfalls.

Besonders eindeutig ist die Regel für ausgelaufene Software. Sind Produkte im Einsatz, die vom Hersteller nicht mehr unterstützt werden, muss geprüft werden, ob sie dennoch sicher betrieben werden können. Wenn nicht, „DÜRFEN diese Hardware- oder Software-Produkte NICHT mehr verwendet werden”. Wer einen eigenen Server betreibt, trifft diese Entscheidung selbst – und trägt sie auch.

Ein Backup ohne getesteten Restore ist eine Annahme

Der Baustein CON.3 „Datensicherungskonzept” führt „Fehlende Wiederherstellungstests” als eigene Gefährdung: „Werden Daten regelmäßig gesichert, gewährleistet dies nicht automatisch, dass diese auch problemlos wiederhergestellt werden können.”

Die zugehörige Basis-Anforderung CON.3.A15 ist knapp und unmissverständlich: „Es MUSS regelmäßig getestet werden, ob die Datensicherungen wie gewünscht funktionieren, vor allem, ob gesicherte Daten einwandfrei und in angemessener Zeit zurückgespielt werden können.”

Zwei weitere Punkte aus demselben Baustein werden im Mittelstand regelmäßig übersehen:

Sicherungsmedien müssen räumlich getrennt von den gesicherten Systemen aufbewahrt werden, möglichst in einem anderen Brandabschnitt. Ein Backup, das als Snapshot auf demselben Hypervisor liegt, erfüllt das nicht.
Sicherungen müssen vor unbefugtem Zugriff und vor Überschreiben geschützt sein. Das BSI nennt den Grund ausdrücklich: Viele Ransomware-Varianten „suchen nach Netzlaufwerken mit Schreibzugriff, auf denen alle Daten ebenfalls verschlüsselt werden”.

Wenn Sie aus diesem Abschnitt eine einzige Frage mitnehmen: Wann haben Sie zuletzt eine Wiederherstellung durchgeführt – nicht geplant, sondern durchgeführt – und wie lange hat sie gedauert?

Überwachung und Kapazität entscheiden, ob Sie den Fehler vor dem Kunden sehen

Monitoring ist kein Dashboard, das gut aussieht. Es ist die Frage, ob jemand merkt, dass der Dienst seit drei Tagen keine Sicherung mehr schreibt. Das BSI beschreibt genau diesen Fall: Reicht die Kapazität der Sicherungsmedien nicht mehr aus, werden neuere Daten unter Umständen nicht mehr gesichert oder ältere überschrieben – „Werden die Zuständigen darüber nicht informiert, weil z. B. das Monitoring unzureichend ist, können Daten eventuell ganz verlorengehen.”

Zur Kapazitätsplanung gehört auch die unspektakuläre Seite: Plattenplatz, Datenbankgröße, Sicherungsdauer. Eine Sicherung, die länger dauert als das Intervall, in dem sie startet, ist keine Sicherung mehr.

Zertifikate laufen ab, und zwar schneller als früher

Ein TLS-Zertifikat ist der Teil des Betriebs, den Ihre Kunden als Erstes sehen, wenn er fehlt. Let’s Encrypt gibt die Standardlaufzeit mit 90 Tagen an und empfiehlt, alle 60 Tage zu erneuern; optional lassen sich kurzlebige Zertifikate mit sechs Tagen Laufzeit beziehen, die alle drei Tage erneuert werden.

Bei diesen Intervallen ist manuelle Erneuerung keine Option, sondern ein terminiertes Ausfallereignis. Erneuerung muss automatisiert sein, und die Automatisierung muss überwacht werden – ein stiller Fehlschlag im Erneuerungsjob fällt sonst genau am Ablauftag auf.

Ein gemieteter Server und ein eigener Serverraum sind zwei verschiedene Entscheidungen

„Eigener Server” meint im Gespräch fast immer eine virtuelle Maschine bei einem deutschen Anbieter. Das ist eine völlig legitime Wahl – aber es ist nicht dasselbe wie ein Gerät im eigenen Technikraum. Die Grenze verläuft dort, wo die Verantwortung für die Schicht darunter endet.

Betriebsform	Bei Ihnen bleibt	Beim Anbieter bleibt
SaaS	Benutzer, Rechte, Inhalte, Export	Betriebssystem, Anwendung, Updates, Verfügbarkeit, Sicherung
Managed Hosting / verwaltete Datenbank	Anwendung, Konfiguration, Inhalte, teils Updates	Hardware, Virtualisierung, Betriebssystem, Basisdienste
Root-Server oder VPS	Betriebssystem, Anwendung, Updates, Sicherung, Monitoring, Zertifikate	Hardware, Strom, Netz, Rechenzentrum
Eigene Hardware im Haus	alles davon, zusätzlich Hardware, Ersatzteile, Netz	nichts

Die letzte Zeile wird am häufigsten unterschätzt. Eigene Hardware im Haus bedeutet zusätzlich: unterbrechungsfreie Stromversorgung, Kühlung, physische Zugangskontrolle, ein zweiter Internetanschluss, wenn der Dienst auch von außen erreichbar sein soll, und ein Ersatzteilkonzept für den Tag, an dem ein Netzteil ausfällt. Für die meisten kleinen und mittleren Unternehmen ist ein gemieteter Server bei einem Anbieter mit Rechenzentrumsbetrieb die klar bessere Wahl – nicht aus Prinzip, sondern weil Strom, Kühlung und Brandschutz nicht zu ihrem Geschäft gehören.

Umgekehrt gibt es gute Gründe für Hardware im Haus: sehr große Datenmengen, die nicht laufend durch die Leitung sollen, Maschinen- oder Produktionsanbindung mit harten Latenzanforderungen, oder ein Dienst, der ausdrücklich auch ohne Internetverbindung funktionieren muss.

Der Serverstandort beantwortet weniger, als er verspricht

„Server in Deutschland” ist ein belastbares Kriterium und zugleich das am häufigsten missbrauchte Verkaufsargument in diesem Themenfeld.

Belastbar ist es, weil der Ort der Speicherung tatsächlich vertraglich geregelt gehört. Das BSI listet ihn im Baustein CON.3 für die Online-Datensicherung ausdrücklich auf – allerdings als einen von sechs Punkten, neben Vertragsgestaltung, Vereinbarungen zur Dienstgüte, geeigneten Authentisierungsmethoden, Verschlüsselung im Speicher und Verschlüsselung auf dem Transportweg. Der Standort steht dort nicht an erster Stelle und nicht allein.

Missbraucht wird das Argument, wenn der Standort als Antwort auf Fragen verkauft wird, die er gar nicht berührt:

Wer hat administrativen Zugriff auf das System, und von wo aus?
Welche Unterauftragnehmer sind beteiligt?
Wie ist der Zugriff protokolliert, und wer sieht diese Protokolle?
Was passiert mit den Daten bei Vertragsende?
Sind die Sicherungen verschlüsselt, und wo liegt der Schlüssel?

Ein Server in Frankfurt, auf den ein nicht überwachter Fernwartungszugang führt, ist nicht sicherer als ein gut geführter Dienst anderswo. Für die Auswahl von Cloud-Anbietern hat das BSI mit dem Kriterienkatalog C5 einen prüfbaren Rahmen für genau solche Fragen veröffentlicht; die Fassung C5:2026 wurde im Frühjahr 2026 vorgestellt.

Eine Einordnung, die wir bewusst nicht vornehmen: Ob Ihre konkrete Konstellation datenschutzrechtlich trägt, ist eine Rechtsfrage. Wir setzen technische Maßnahmen um und dokumentieren sie; die rechtliche Bewertung gehört zu Ihrer Datenschutz- und Rechtsberatung.

Der ehrliche Fehlerfall: ein ungepflegter eigener Dienst ist schlechter als das SaaS, das er ersetzt hat

Das ist der Satz, den Anbieter selbst gehosteter Lösungen ungern schreiben, der aber der wichtigste in diesem Beitrag ist.

Ein aus dem Internet erreichbares Wiki, Ticketsystem oder Dateiablagesystem, das seit über einem Jahr keine Aktualisierung gesehen hat, ist kein Gewinn an Souveränität. Es ist eine bekannte, öffentlich dokumentierte Schwachstelle mit Ihren Unternehmensdaten dahinter. Beim SaaS-Anbieter wäre dieselbe Lücke vermutlich innerhalb von Tagen geschlossen worden, ohne dass Sie davon erfahren hätten.

Das BSI beschreibt den Mechanismus dahinter nüchtern als Fehleinschätzung der Relevanz: Werden Änderungen falsch priorisiert, werden „zuerst unwichtige Patches installiert. Wichtige Patches hingegen werden dann zu spät installiert. Sicherheitslücken bleiben so länger bestehen.”

In der Praxis ist es selten böser Wille. Meist hat jemand die Instanz aufgesetzt, weil es schnell gehen musste, und seitdem andere Aufgaben bekommen. Der Dienst funktioniert ja. Genau deshalb fällt niemandem auf, dass er nicht mehr gepflegt wird.

Wenn Sie sich für Self-Hosting entscheiden, entscheiden Sie sich für einen wiederkehrenden Aufwand – oder Sie entscheiden sich, ohne es zu merken, gegen die Sicherheit, wegen der Sie ursprünglich gewechselt sind.

Was passiert, wenn diese eine Person zwei Wochen nicht da ist?

Die Frage nach dem Bus-Faktor klingt theoretisch, bis sie akut wird. Sie ist die härteste Prüfung für jedes selbst betriebene System, und sie lässt sich mit sechs Fragen beantworten:

Wer hat administrativen Zugang – namentlich, nicht „die IT”?
Wo liegen die Zugangsdaten, und wer kommt im Notfall an sie heran, ohne die betroffene Person zu erreichen?
Existiert eine schriftliche Wiederherstellungsanleitung, und hat sie schon einmal jemand befolgt, der sie nicht geschrieben hat?
Liegt diese Anleitung auch außerhalb des Systems, das sie wiederherstellen soll?
Wer entscheidet über ein außerplanmäßiges Wartungsfenster?
Was ist die vereinbarte Reaktionszeit – und mit wem ist sie vereinbart?

Das BSI verlangt für alle Organisationsbereiche festgelegte Zuständige für das Patch- und Änderungsmanagement, und ausdrücklich, dass diese Zuständigkeiten sich „auch im Berechtigungskonzept widerspiegeln” müssen. Für die Dokumentation gilt derselbe Gedanke: Liegen die Informationen zur Wiederherstellung nur digital vor, besteht laut BSI die Gefahr, dass sie „bei Großschäden (wie Ransomware) ebenfalls verloren” gehen.

Eine einzelne Person, die alles weiß und nichts aufgeschrieben hat, ist übrigens auch bei Open-Source-Software eine Abhängigkeit – nur eine, die keinen Vertrag hat und kündigen kann.

Wann Self-Hosting die richtige Entscheidung ist

Ein selbst betriebener Dienst trägt, wenn mehrere dieser Punkte zutreffen:

Der Anwendungsfall verlangt Anpassungen oder Integrationen, die das passende SaaS-Produkt nicht vorsieht.
Die Datenmenge oder Nutzerzahl macht Nutzungsgebühren über mehrere Jahre unwirtschaftlich.
Der Dienst muss auch dann funktionieren, wenn die Internetverbindung ausfällt.
Es gibt eine benannte, verfügbare Person oder einen Vertrag für den Betrieb – nicht die Absicht, sich darum zu kümmern.
Wartungsfenster lassen sich organisatorisch tatsächlich legen.
Ein Ausfall von einigen Stunden ist verkraftbar, oder Redundanz ist eingeplant und bezahlt.

Wann Sie es lassen sollten – und uns dafür nicht brauchen

Ebenso klar die Gegenrichtung. Bleiben Sie bei SaaS, wenn:

der Prozess Standard ist und Sie keine Anpassung benötigen;
niemand im Haus Betriebsverantwortung übernehmen kann und ein Betreuungsvertrag nicht im Budget ist;
der Dienst geschäftskritisch ist und Sie eine Verfügbarkeit erwarten, die Sie mit einer einzelnen virtuellen Maschine nicht erreichen;
die Anwendung ohnehin nur wenige Personen nutzen und die laufenden Gebühren überschaubar sind;
Ihr eigentliches Problem Datenqualität oder ein unklarer Prozess ist – ein Umzug auf eigene Infrastruktur löst davon nichts.

Und ein Fall, der ehrlicherweise dazugehört: Wenn Sie eine erfahrene Administratorin oder einen erfahrenen Administrator im Haus haben, die oder der Updates, Sicherungen und Monitoring bereits geregelt betreibt, dann brauchen Sie für den laufenden Betrieb keinen Dienstleister. Sinnvoll bleiben wir dann höchstens für die Einrichtung, für eine Zweitmeinung zum Konzept oder als Vertretung im Urlaubsfall.

Was wir übernehmen und was das kostet

TakFlow richtet selbst gehostete Anwendungen ein und betreibt sie – von der Serverbereitstellung über Reverse Proxy, Zertifikate, Containerisierung und Datenbank bis zu Sicherung, Monitoring, Updateprozess und technischer Dokumentation. Der Umfang dieser Arbeit steht auf der Seite Open Source, Self-Hosting und Betrieb.

Die laufende Betreuung beginnt bei 99 € im Monat. Darin enthalten sind Hosting, Monitoring, Updates und Sicherungen für eine betreute Anwendung mit vereinbarter Reaktionszeit. Was den Betrag nach oben bewegt, ist bewusst benannt: Anzahl und Art der betreuten Systeme, vereinbarte Reaktionszeiten und Erreichbarkeit, Umfang und Aufbewahrungsdauer der Sicherungen sowie das enthaltene Kontingent für Änderungen.

Wir schreiben den Umfang vor Beginn fest – enthaltene Systeme, Kontaktwege, Reaktionszeiten und Wartungsfenster – und nicht im ersten Störungsfall.

Ein Hinweis zur Regulierung, falls er Sie betrifft: Fällt Ihr Unternehmen unter NIS-2, sind Risikomanagement, Notfallmanagement und Lieferkettensicherheit keine freiwilligen Betriebsthemen mehr. Das BSIG in der seit dem 6. Dezember 2025 geltenden Fassung verpflichtet betroffene Einrichtungen zu Risikomanagementmaßnahmen in zehn Bereichen, und die Verantwortung für Umsetzung und Überwachung liegt laut BSI bei der Geschäftsleitung. Ob Sie betroffen sind, hängt zuerst von Ihrer Branchenzugehörigkeit ab – Details dazu im Beitrag NIS-2 pragmatisch einordnen.

Handlungsaufruf

Sie überlegen, einen Dienst selbst zu betreiben – oder haben bereits einen, um den sich niemand richtig kümmert?
Wir sehen uns Zugänge, Versionsstand, Sicherungen und Dokumentation an und sagen offen, ob Self-Hosting in Ihrem Fall trägt oder ob eine SaaS-Lösung die günstigere Antwort ist.

Betrieb und Hosting besprechen

Weiterführend: Open Source, Self-Hosting und Betrieb · Betreuung und Support · Open Source oder proprietär: Was Sie wirklich zahlen · Open Source und digitale Souveränität

Self-Hosting: Wann sich ein eigener Server lohnt – und wann er zur Dauerbaustelle wird