Self-Hosting bezeichnet den Betrieb von Software auf eigener oder gemieteter Infrastruktur in eigener Verantwortung, statt sie als fertig betriebenen Cloud-Dienst eines Anbieters zu beziehen.
Der Begriff klingt nach Serverraum im Keller, meint aber in der Praxis meist etwas anderes: einen gemieteten Cloud- oder Root-Server bei einem Hosting-Anbieter, auf dem das Unternehmen die Software selbst installiert, konfiguriert und aktuell hält. Entscheidend ist nicht, wem das Blech gehört, sondern wer die Software kontrolliert: Beim Self-Hosting bestimmt das Unternehmen selbst über Version, Konfiguration, Datenhaltung und den Zeitpunkt jedes Updates. Eine allgemeine Einführung bietet der englischsprachige Wikipedia-Artikel zu Self-Hosting; dieser Eintrag konzentriert sich auf die Praxis im Mittelstand.
Abgrenzung: SaaS, Managed Hosting, On-Premises
Self-Hosting versteht man am schnellsten im Kontrast zu den drei Nachbarmodellen:
| Modell | Wer betreibt die Software? | Wo läuft sie? | Typische Beispiele |
|---|---|---|---|
| SaaS | Der Anbieter | Auf der Infrastruktur des Anbieters | HubSpot, Salesforce, ChatGPT im Browser |
| Managed Hosting | Ein Dienstleister im Auftrag | Auf gemieteter, dedizierter Umgebung | Managed WordPress, gemanagtes n8n |
| Self-Hosting | Das Unternehmen selbst | Auf gemieteten Servern oder eigener Hardware | n8n auf einem Hetzner-Server, Nextcloud |
| On-Premises | Das Unternehmen selbst | Auf eigener Hardware im eigenen Haus | ERP im eigenen Rechenzentrum |
On-Premises ist damit ein Spezialfall des Self-Hostings mit eigener Hardware, historisch der Normalfall, heute die Ausnahme. Die gängige Form im Mittelstand ist der Mittelweg: gemietete Infrastruktur bei einem europäischen Hoster, betrieben in eigener Verantwortung. Man kauft sich die Hardware-Sorgen ab und behält die Software-Kontrolle.
Warum Self-Hosting 2026 ein Comeback erlebt
Bemerkenswert ist zunächst die Richtungsumkehr. Vor der Cloud-Ära war der Eigenbetrieb schlicht der Normalzustand; der Begriff Self-Hosting entstand erst, als SaaS zum Standard wurde und der Eigenbetrieb zur bewussten Entscheidung. Nach fünfzehn Jahren, in denen „in die Cloud" als Synonym für Modernisierung galt, wandert nun ein wachsender Teil der Werkzeuglandschaft wieder zurück auf eigene Server. In der Branche hat sich dafür das Wort Cloud-Repatriierung etabliert; das prominenteste dokumentierte Beispiel ist der Software-Hersteller 37signals (Basecamp), der seinen vollständigen Abschied von AWS samt Kostenrechnung öffentlich protokolliert hat. Hinter dem Trend stehen vier handfeste Gründe.
Kostenkontrolle. SaaS wird überwiegend pro Nutzer und Monat abgerechnet. Die Kosten wachsen mit der Teamgröße, unabhängig davon, wie intensiv das Werkzeug genutzt wird, und Preiserhöhungen kommen per Ankündigungs-Mail. Ein selbst betriebener Server kostet dagegen einen festen, meist zweistelligen Monatsbetrag, egal ob zehn oder zweihundert Menschen mit der Software arbeiten. Für Werkzeuge, die das ganze Unternehmen nutzt, kippt die Rechnung damit oft schon bei kleinen Teamgrößen zugunsten des Eigenbetriebs.
Datenkontrolle und Rechtslage. Die Debatte um den CLOUD Act hat vielen Geschäftsführungen bewusst gemacht, dass Daten bei US-Anbietern rechtlich erreichbar bleiben, egal wo der Server steht. Self-Hosting auf europäischer Infrastruktur ist die strukturelle Antwort darauf und ein zentraler Baustein digitaler Souveränität: Die Daten liegen dort, wo nur das eigene Unternehmen und sein Hoster Zugriff haben. Mit dem produktiven KI-Einsatz verschärft sich die Frage, denn Prompts, Wissensbasen und Agenten-Gedächtnisse sind Prozesswissen, das man ungern in fremden Accounts altern lässt.
Die Reife von Open Source. Für fast jede SaaS-Kategorie existiert inzwischen eine selbst betreibbare Alternative auf professionellem Niveau: n8n für Workflow-Automatisierung, Nextcloud für Dateiablage und Kollaboration, Keycloak für Identitätsmanagement, Grafana für Monitoring, PostgreSQL mit pgvector oder Qdrant als Datenbank- und Vektorschicht. Dahinter stehen keine Hobby-Projekte, sondern Firmen mit Open-Source- oder Fair-Code-Geschäftsmodellen, die von zahlenden Enterprise-Kunden leben und ihre Software entsprechend pflegen.
Der Tooling-Sprung. Vor zehn Jahren bedeutete Self-Hosting, Linux-Pakete, Konfigurationsdateien und Abhängigkeiten von Hand zu pflegen. Container haben diese Hürde abgeräumt. Heute beschreibt eine einzige Datei den kompletten Anwendungs-Stack, und Plattformen wie Coolify machen aus dem gemieteten Server eine Umgebung, die sich bedient wie ein Cloud-Dienst. Der Admin-Aufwand ist nicht verschwunden, aber er ist von „eigene Disziplin" auf „erlernbare Nebenaufgabe" geschrumpft.
Der typische Self-Hosting-Stack im Mittelstand
Docker und Docker Compose als Fundament
Die Grundlage fast aller modernen Self-Hosting-Setups sind Container. Eine Anwendung wird samt aller Abhängigkeiten in ein standardisiertes Image verpackt und läuft damit auf jedem Server gleich. Docker Compose beschreibt in einer einzigen YAML-Datei den kompletten Stack, etwa die Anwendung, ihre Datenbank und einen Reverse Proxy. Das macht Installationen reproduzierbar und Umzüge trivial: Die Compose-Datei plus ein Datenbank-Backup sind die vollständige Beschreibung des Systems. Ein Update besteht im Regelfall darin, eine neue Image-Version einzutragen und den Stack neu zu starten, nach einem Blick in die Release Notes.
Coolify: Self-Hosting mit PaaS-Komfort
Wer nicht auf der Kommandozeile arbeiten will, setzt eine Self-Hosting-Plattform auf den Server. Das bekannteste Beispiel ist Coolify, ein Open-Source-Werkzeug, das sich wie ein selbst betriebenes Gegenstück zu Heroku oder Vercel verhält: Anwendungen, Datenbanken und Dutzende vorkonfigurierte Dienste werden über eine Weboberfläche installiert, HTTPS-Zertifikate kommen automatisch, Deployments laufen auf Wunsch direkt aus dem Git-Repository, Backups lassen sich zeitgesteuert einrichten. Coolify selbst läuft auf jedem Server mit SSH-Zugang. Welche Werkzeuge sich damit im Alltag betreiben lassen, zeigt unser Coolify-Guide mit konkreten Open-Source-Alternativen zum SaaS-Abo.
Beispiel: KI-Automatisierung auf einem Hetzner-Server
Ein typisches Mittelstands-Setup im Jahr 2026 sieht so aus: Auf einem Cloud-Server von Hetzner läuft n8n als Workflow-Engine, daneben PostgreSQL mit pgvector als Wissens- und Vektordatenbank, davor ein Reverse Proxy mit TLS und Zugriffsschutz. Ausgerollt und aktualisiert wird das Ganze über Coolify oder eine Compose-Datei im Git-Repository, sodass der komplette Stack versioniert und binnen einer Stunde auf einem frischen Server reproduzierbar ist. Die KI-Workflows rufen ein Large Language Model per API auf, mal GPT, mal Mistral, je nach Aufgabe und Datenlage. Der Punkt dieses Aufbaus: Workflows, Prompts und Wissensbasis liegen vollständig im eigenen Zugriff, während die Modelle austauschbare Zulieferer bleiben. Fällt ein Anbieter aus oder ändert die Konditionen, wechselt man den API-Endpunkt, nicht die Architektur.
Die Sicherheits-Grundausstattung
Unabhängig vom Werkzeug gehört zu jedem ernsthaften Self-Hosting-Setup ein Mindestmaß an Härtung, das sich in einem Nachmittag einrichten lässt und über Jahre trägt:
- Ein Reverse Proxy mit automatischem TLS vor allen Anwendungen; kein Dienst spricht direkt ins Internet.
- Admin-Oberflächen nicht öffentlich erreichbar machen, sondern hinter VPN oder IP-Freigaben legen.
- Automatische Sicherheitsupdates fürs Betriebssystem, Anwendungs-Updates nach Release Notes.
- Getestete Backups nach dem 3-2-1-Prinzip: drei Kopien, zwei Medien, eine davon außer Haus.
- Basis-Monitoring mit Alarmierung für Erreichbarkeit, Speicherplatz und fehlgeschlagene Logins.
Die ehrlichen Trade-offs
Self-Hosting verlagert Verantwortung, und das muss man wollen. Die Lizenz kostet nichts, der Betrieb schon: Sicherheitsupdates müssen zeitnah eingespielt werden, denn eine öffentlich erreichbare Anwendung mit bekannter Schwachstelle wird gefunden, das ist keine Frage des Ob. Backups existieren erst dann wirklich, wenn eine Wiederherstellung geprobt wurde. Monitoring und Alarmierung braucht es, damit ein voller Datenträger am Wochenende nicht erst am Montag auffällt. Und es braucht eine Antwort auf die Personalfrage: Wer kümmert sich, wenn die zuständige Person im Urlaub ist?
Dazu kommt die Verfügbarkeit. Ein SaaS-Anbieter garantiert sie vertraglich mit einem SLA, beim Self-Hosting gibt es nur das Versprechen, das man sich selbst gibt. Für interne Werkzeuge, die eine Stunde Ausfall verkraften, ist das unkritisch. Für Systeme, an denen unmittelbar Umsatz hängt, ist es eine bewusste Risikoentscheidung, die man mit Redundanz und Prozessen unterlegen sollte, nicht mit Optimismus. Wer diese Betriebsaufgaben realistisch mit zwei bis vier Stunden pro Monat für ein gepflegtes Standard-Setup ansetzt, rechnet ehrlicher als mit null.
Wann SaaS die bessere Wahl bleibt
Self-Hosting ist ein Werkzeug, kein Weltbild. SaaS bleibt die bessere Wahl, wenn hohe Verfügbarkeit ohne eigenes Betriebsteam gefordert ist, wenn Zertifizierungen und Compliance-Nachweise fertig mitgeliefert werden müssen oder wenn der Wert des Dienstes gerade im Netzwerk liegt, wie bei E-Mail- und Kollaborationsplattformen. Auch selten genutzte Spezialsoftware rechtfertigt den Betriebsaufwand meist nicht. Die sinnvolle Prüffrage ist nicht „SaaS oder Self-Hosting?", sondern: Wie zentral ist das Werkzeug für unsere Prozesse, wie sensibel sind die Daten darin, und wie leicht kämen wir wieder heraus? Ein SaaS-Abo mit sauberem Exportpfad ist unproblematisch; kritisch wird es, wenn Kernprozesse ohne Ausstiegsoption in einem fremden Ökosystem liegen und der Vendor-Lock-in mit jedem Jahr wächst. Viele Unternehmen fahren deshalb zweigleisig: Standard-Kollaboration aus der Cloud, prozesskritische Automatisierung und Wissensbestände auf eigener Infrastruktur.
Häufige Fragen zum Self-Hosting
Ist Self-Hosting automatisch DSGVO-konformer als SaaS?
Nein, aber es vereinfacht die Lage strukturell. Es entfällt der US-Drittlandtransfer für die selbst betriebene Anwendung, und mit dem europäischen Hoster genügt ein Auftragsverarbeitungsvertrag für die Infrastruktur. Die Pflicht zu technischen und organisatorischen Maßnahmen wandert dafür vollständig ins eigene Haus: Verschlüsselung, Zugriffskonzepte, Löschfristen und Patch-Stand verantwortet niemand anderes mehr.
Was kostet Self-Hosting wirklich?
Die Serverkosten sind der kleinste Posten, für typische Mittelstands-Setups ein zweistelliger Monatsbetrag. Ehrlich wird die Rechnung erst mit der Arbeitszeit für Updates, Backups und Monitoring. Dafür entfallen die nutzerbasierten Abogebühren, die bei wachsendem Team linear mitwachsen. Das Rechenmuster dazu: Ein SaaS-Werkzeug für 20 Euro pro Nutzer und Monat kostet ein Team von 25 Personen 500 Euro monatlich, also 6.000 Euro im Jahr; der Server, auf dem eine selbst betriebene Alternative läuft, kostet einen Bruchteil davon, und der Abstand wächst mit jeder Neueinstellung. Als Faustregel lohnt der Vergleich immer dann, wenn ein Werkzeug von vielen Personen genutzt wird oder sensible Daten verarbeitet.
Braucht man für Self-Hosting Kubernetes?
In den allermeisten Fällen nicht. Kubernetes lohnt sich für Plattform-Teams mit vielen Services und hohen Verfügbarkeitsanforderungen. Ein Mittelstands-Setup mit einer Handvoll Anwendungen ist mit Docker Compose oder einer Plattform wie Coolify besser bedient: weniger bewegliche Teile, weniger Spezialwissen, gleiche Kontrolle.
Welche Anwendungen eignen sich für den Einstieg?
Interne Werkzeuge ohne harte Verfügbarkeitsanforderungen: eine Workflow-Automatisierung wie n8n, ein Monitoring, eine Wissensbasis, ein Analytics-Werkzeug. Damit sammelt das Team Betriebserfahrung an Systemen, deren Ausfall kein Kunde bemerkt. Das umsatzkritische Shopsystem oder das ERP migriert man erst, wenn Backups, Updates und Alarmierung Routine geworden sind, oder bewusst gar nicht.