Was ist Self-Hosting?
Self-Hosting bedeutet, eine Software auf einem selbst verwalteten Server zu betreiben, statt sie als fertigen Onlinedienst beim Hersteller zu nutzen.
Ohne Fachbegriffe, für Betriebe ohne eigene IT.
Auf dieser Seite3 Abschnitte
Einfach erklärt
Self-Hosting heißt: Eine Software läuft auf einem Server, den Sie selbst kontrollieren, statt beim Hersteller als fertiger Onlinedienst. Der Server kann im eigenen Haus stehen oder in einem Rechenzentrum gemietet sein. Entscheidend ist, wer ihn verwaltet und wo die Daten liegen. Das ist wie der Unterschied zwischen eigener Küche und Lieferdienst: Sie bestimmen Zutaten und Ablauf, müssen aber auch einkaufen und abwaschen.
Typische Beispiele sind Dokumentenablage, Ticketsystem oder Wiki auf einem eigenen Server, etwa mit Paperless-ngx, Zammad oder Docmost.
Was Sie gewinnen
- Datenstandort: Sie wissen, in welchem Land und Rechenzentrum Ihre Daten liegen.
- Unabhängigkeit: Ändert ein Anbieter Preise oder Bedingungen, bleiben Software und Daten bei Ihnen. Mehr dazu im Beitrag Digitale Souveränität.
- Mitsprache: Sie entscheiden, wann ein Update kommt und welche Funktionen aktiv sind.
Was Sie übernehmen
Was ein Anbieter sonst im Hintergrund erledigt, liegt beim Self-Hosting bei Ihnen oder Ihrem IT-Dienstleister: Updates, Backups, Monitoring und die Reaktion auf neue Sicherheitslücken. Ohne feste Zuständigkeit veraltet ein selbst betriebener Server unbemerkt.
Tipp: Halten Sie vor dem Start schriftlich fest, wer Updates einspielt, wer Backups prüft und wer bei einem Ausfall erreichbar ist. Wie abhängig Ihr Betrieb heute von einzelnen Anbietern ist, zeigt der Souveränitäts-Check.
Betriebsmodelle
Self-Hosting bezeichnet den Betrieb einer Anwendung auf Infrastruktur, deren Betriebssystem und Konfiguration der Nutzer oder sein Dienstleister kontrolliert. Das reicht vom Server im eigenen Serverraum über Colocation bis zum gemieteten dedizierten oder virtuellen Server. Nach der Einteilung des NIST (SP 800-145) ist ein gemieteter Server IaaS, die Anwendung darauf betreibt der Kunde selbst. Das Gegenstück ist SaaS, bei dem der Anbieter die Anwendung betreibt.
Verbreitet ist der Betrieb in Containern hinter einem Reverse Proxy:
/opt/dms/
├── compose.yaml # Anwendung, Datenbank, Cache mit festen Versionen
├── .env # Zugangsdaten, nicht im Image
├── data/ # Nutzdaten, im Backup enthalten
└── backup.sh # Datenbank-Dump vor der Sicherung
Wer wofür zuständig ist
| Aufgabe | SaaS | Self-Hosting |
|---|---|---|
| Hardware, Rechenzentrum | Anbieter | Hoster oder eigener Serverraum |
| Betriebssystem und Anwendung aktualisieren | Anbieter | Betreiber |
| Backup und Wiederherstellung | Anbieter, Umfang laut Vertrag | Betreiber |
| Datenstandort | wie vom Anbieter angegeben | frei wählbar |
| Versionswechsel | bestimmt der Anbieter | bestimmt der Betreiber |
Hoster bieten für gemietete Server üblicherweise einen Vertrag zur Auftragsverarbeitung nach Art. 28 DSGVO an. Ob er nötig ist und was er regeln muss, klärt Ihr Datenschutzbeauftragter.
Typische Fehler
- Installieren und vergessen. Ohne Update-Routine läuft die Anwendung nach einigen Monaten mit bekannten Lücken.
- Datenbank nur als Dateien gesichert. Bei laufendem Betrieb kopierte Datenbankdateien können eine inkonsistente Sicherung ergeben. Ein Dump (
pg_dump) vor dem Backup vermeidet das. - Verwaltungsoberflächen öffentlich. Datenbankwerkzeuge oder Container-Verwaltung sind ohne Not aus dem Internet erreichbar.
- Zertifikat von Hand eingerichtet. Läuft es ab, warnen Browser vor der Seite und Apps verweigern die Verbindung. Automatische Verlängerung (etwa mit Let's Encrypt) und eine Überwachung des Ablaufdatums vermeiden das.
- Kein Betriebshandbuch. Nur eine Person kennt Zugänge, Aufbau und Wiederherstellung.
Prüfen
docker compose ps
docker compose images
ss -tlnp
docker compose images zeigt die laufenden Versionen, die sich mit den aktuellen Releases der Hersteller vergleichen lassen. ss -tlnp zeigt, auf welchen Adressen Dienste lauschen.