# Self-Hosting-Grundausstattung: Was Sie brauchen, bevor der erste Dienst läuft

> Eigene Dienste zu betreiben heißt nicht, einzelne Container zu starten. Ein Überblick über die Basisinfrastruktur – von Virtualisierung über Zertifikate und Single Sign-on bis zum Monitoring – und darüber, wann Sie es besser lassen.

- Rubrik: Self-Hosting
- Format: Überblick
- Autor: Redaktion Umbrecher (umbrecher, https://umbrecher.com/ueber)
- Veröffentlicht: 2026-09-30
- Kanonische URL: https://umbrecher.com/artikel/self-hosting-grundausstattung

## Das Wichtigste in Kürze

- Eine Virtualisierungsschicht wie Proxmox VE ist das Fundament des Self-Hostings, weil sie Anwendungen trennt, Snapshots vor Updates erlaubt und Hardwaretausch zur Routine macht.
- Ein zentraler Reverse Proxy wie Caddy, Traefik oder nginx bündelt TLS, Zugriffsregeln und Protokollierung; die Zertifikatserneuerung muss wegen sinkender Laufzeiten automatisiert sein.
- Ein zentraler Identity Provider wie Keycloak oder authentik mit Mehrfaktor-Authentifizierung ersetzt getrennte Benutzerverwaltungen in jedem einzelnen Dienst.
- Monitoring mit Werkzeugen wie Prometheus, Grafana oder Uptime Kuma nützt nur, wenn klar festgelegt ist, wer wann auf Alarme reagiert.
- Self-Hosting ist ohne Personal für Updates und Alarme ein Sicherheitsrisiko; beim E-Mail-Versand fahren viele Unternehmen mit einem europäischen Anbieter besser.

Zur Self-Hosting-Grundausstattung gehört die Infrastruktur, die jeder selbst betriebene Dienst braucht: Virtualisierung, Reverse Proxy mit TLS, zentrale Identität, Monitoring, Backups, Patching und Dokumentation. Der Einstieg ins Self-Hosting beginnt oft mit einem konkreten Wunsch: eine eigene Dateiablage, ein Wiki, ein lokales Sprachmodell. Der Dienst selbst ist meist schnell installiert. Was danach über Erfolg oder Frust entscheidet, ist das Drumherum – die Infrastruktur, die jeder Dienst braucht und die man einmal sauber aufbaut, statt sie für jede Anwendung neu zu improvisieren.

Dieser Überblick beschreibt die Grundausstattung in sieben Bausteinen. Er richtet sich an kleine und mittlere Unternehmen, die einige wenige bis einige Dutzend Dienste selbst betreiben wollen.

## 1. Virtualisierung als Fundament

Kaum ein Dienst sollte direkt auf der Hardware laufen. Eine Virtualisierungsschicht trennt Anwendungen voneinander, erlaubt Snapshots vor Updates und macht Hardwaretausch zur Routine statt zum Projekt.

Für den Mittelstand ist Proxmox VE eine verbreitete Wahl: Open Source unter AGPLv3, virtuelle Maschinen per KVM, Linux-Container per LXC, integrierte Speicheroptionen wie ZFS und Ceph sowie eine Weboberfläche für die Verwaltung. Wer von VMware kommt, findet die Details in unserem Leitfaden [Proxmox statt VMware](/artikel/proxmox-statt-vmware).

Innerhalb der VMs laufen Anwendungen häufig als Container, etwa mit Docker oder Podman. Faustregel: Gruppieren Sie zusammengehörige Dienste in eigene VMs und vermeiden Sie den einen großen „Docker-Host“, auf dem alles läuft und den niemand mehr neu starten möchte.

## 2. Reverse Proxy und TLS

Ein Reverse Proxy ist der zentrale Eingang: Er nimmt Anfragen entgegen, terminiert die TLS-Verschlüsselung und leitet an den passenden internen Dienst weiter. Das hat Vorteile – ein Ort für Zertifikate, Zugriffsregeln und Protokollierung.

Drei Optionen sind verbreitet:

| Werkzeug | Charakter |
|---|---|
| **Caddy** | Holt und erneuert TLS-Zertifikate standardmäßig automatisch; knappe Konfiguration. Gut für den Einstieg. |
| **Traefik** | Liest seine Konfiguration dynamisch aus Docker-Labels oder Kubernetes; integrierter ACME-Client. Gut für containerlastige Umgebungen. |
| **nginx** | Sehr verbreitet, sehr flexibel, viel Dokumentation. Zertifikate werden meist über einen separaten ACME-Client wie Certbot verwaltet. |

Die Zertifikate kommen in aller Regel von Let's Encrypt über das ACME-Protokoll. Ein wichtiger Trend: Zertifikatslaufzeiten werden kürzer. Das CA/Browser Forum, das Gremium aus Zertifizierungsstellen und Browserherstellern, hat 2025 beschlossen, die maximale Laufzeit öffentlicher TLS-Zertifikate schrittweise bis März 2029 auf 47 Tage zu senken. Let's Encrypt plant, sein Standardprofil im Februar 2027 auf 64 und im Februar 2028 auf 45 Tage umzustellen. Manuelle Zertifikatsverwaltung ist damit endgültig keine Option mehr – automatisieren Sie die Erneuerung und überwachen Sie Ablaufdaten.

Für rein interne Dienste lohnt der Blick auf eine eigene interne Zertifizierungsstelle oder auf DNS-basierte Validierung, damit keine internen Systeme aus dem Internet erreichbar sein müssen.

## 3. Identität und Single Sign-on

Spätestens ab dem dritten Dienst wird es unübersichtlich, wenn jeder seine eigene Benutzerverwaltung hat. Ein zentraler Identity Provider (IdP) löst das: Nutzer melden sich einmal an (Single Sign-on, SSO), Dienste vertrauen dem IdP über Standards wie OpenID Connect oder SAML. Beim Ausscheiden eines Mitarbeiters wird ein Konto gesperrt – nicht zwanzig.

- **Keycloak** ist ein etabliertes Open-Source-Projekt, das von Red Hat initiiert wurde. Es ist umfangreich, gut für größere oder komplexere Umgebungen und lässt sich an bestehende LDAP- oder Active-Directory-Verzeichnisse anbinden.
- **authentik** ist eine jüngere Alternative mit moderner Oberfläche, die neben OIDC und SAML auch einen Proxy-Modus bietet, um Anwendungen ohne eigene SSO-Unterstützung abzusichern.

Wichtig in beiden Fällen: Mehrfaktor-Authentifizierung von Anfang an aktivieren und den IdP selbst besonders gut absichern – er ist der Generalschlüssel zu allen angeschlossenen Diensten.

## 4. Monitoring und Logs

Sie sollten von einem Problem erfahren, bevor es Ihre Nutzer tun.

- **Prometheus** sammelt Metriken – CPU, Speicher, Plattenfüllstand, anwendungsspezifische Werte – und wertet Alarmregeln aus.
- **Grafana** visualisiert diese Metriken in Dashboards und kann auch Logs aus Quellen wie Loki darstellen.
- **Uptime Kuma** ist ein schlankes Werkzeug für Verfügbarkeitsprüfungen: Ist die Website erreichbar, läuft das Zertifikat bald ab, antwortet der Mailserver? Für kleine Umgebungen oft der beste erste Schritt.

Zentralisieren Sie zudem Logs. Wenn ein Server kompromittiert oder defekt ist, sind lokale Logs oft nicht mehr verfügbar oder nicht mehr vertrauenswürdig. Und: Ein Alarm, der an ein Postfach geht, das niemand liest, ist kein Alarm. Definieren Sie, wer wann reagiert.

## 5. Backups

Ohne funktionierende Sicherung ist jeder selbst betriebene Dienst ein Risiko. Grundprinzip ist die 3-2-1-Regel – drei Kopien, zwei Medien, eine außer Haus – ergänzt um mindestens eine unveränderliche oder offline gelagerte Kopie und regelmäßige Restore-Tests. Werkzeuge, Muster und Prüfroutinen beschreibt unser Leitfaden [Backups nach der 3-2-1-Regel](/artikel/backups-nach-der-3-2-1-regel).

## 6. Updates und Patching

Die größte Gefahr beim Self-Hosting ist nicht der spektakuläre Angriff, sondern die vergessene Anwendung mit drei Jahre alter Software. Legen Sie fest:

- **Rhythmus:** Ein fester Wartungstermin, zum Beispiel wöchentlich für Sicherheitsupdates des Betriebssystems, monatlich für Anwendungen.
- **Quellen:** Abonnieren Sie Sicherheitsmeldungen der eingesetzten Projekte und Ihrer Linux-Distribution.
- **Automatisierung:** Unbeaufsichtigte Sicherheitsupdates für das Betriebssystem sind meist sinnvoll; Anwendungsupdates sollten Sie bewusst einspielen – mit Snapshot oder Backup davor.
- **Lebenszyklus:** Notieren Sie, wann Betriebssystem- und Anwendungsversionen ihr Support-Ende erreichen, und planen Sie Upgrades rechtzeitig.

Werkzeuge zur Konfigurationsverwaltung wie Ansible helfen, viele Systeme einheitlich zu halten. Sie sind kein Muss für den Anfang, zahlen sich aber ab etwa einem Dutzend Systemen aus.

## 7. Dokumentation

Was nur im Kopf einer Person existiert, ist ein Betriebsrisiko. Dokumentieren Sie mindestens:

- welche Dienste wo laufen und wofür sie da sind,
- Netzwerkplan, IP-Adressen, DNS-Einträge,
- wo Zugangsdaten und Schlüssel liegen (in einem Passwortmanager, nicht in der Doku selbst),
- wie Backup und Wiederherstellung funktionieren,
- wen man bei welchem Problem anruft.

Ein Wiki oder ein Git-Repository mit Markdown-Dateien reicht. Wichtig ist, dass die Dokumentation auch erreichbar ist, wenn die Infrastruktur, auf der sie liegt, ausgefallen ist – eine Offline-Kopie gehört dazu.

## Wann Sie nicht selbst hosten sollten

Self-Hosting ist kein Selbstzweck. In manchen Fällen ist ein Dienstleister die bessere Wahl:

- **Kein Personal für den Betrieb:** Wenn niemand Zeit hat, Updates einzuspielen und Alarme zu beantworten, ist ein selbst betriebener Dienst ein Sicherheitsrisiko.
- **E-Mail-Versand:** Ein eigener Mailserver ist machbar, aber Zustellbarkeit und Spam-Abwehr erfordern dauerhaft Pflege. Viele Unternehmen fahren mit einem europäischen Anbieter besser.
- **Hohe Verfügbarkeitsanforderungen ohne Redundanz:** Wenn ein Dienst rund um die Uhr laufen muss, Sie aber nur einen Server in einem Büroraum haben, wird es teuer, das nachzuholen.
- **Regulatorisch anspruchsvolle Daten** ohne entsprechendes Sicherheitskonzept.

Dazwischen gibt es Mittelwege: Open-Source-Software bei einem europäischen Hoster betreiben lassen, mit vertraglich gesichertem Datenexport. Damit behalten Sie die Wechselfreiheit, ohne jede Schicht selbst verantworten zu müssen. Wie Sie Varianten kostenseitig vergleichen, zeigt unser Beitrag [TCO ehrlich rechnen](/artikel/tco-ehrlich-rechnen), eine erste Schätzung liefert der [Kostenrechner](/werkzeuge/kostenrechner).

## Checkliste für die Grundausstattung

- [ ] Virtualisierungsschicht als Fundament, Dienste sinnvoll gruppiert
- [ ] Ein zentraler Reverse Proxy, Zertifikatserneuerung vollständig automatisiert
- [ ] Zentraler Identity Provider mit MFA, bevor die Zahl der Dienste wächst
- [ ] Monitoring mit klarer Zuständigkeit für Alarme
- [ ] Backups nach 3-2-1 mit unveränderlicher Kopie und Restore-Tests
- [ ] Fester Patch-Rhythmus und Überblick über Support-Enden
- [ ] Dokumentation, die auch im Ausfall erreichbar ist
- [ ] Ehrliche Prüfung, welche Dienste besser extern betrieben werden

## Häufige Fragen

### Welche Infrastruktur braucht man für Self-Hosting im Unternehmen?

Sieben Bausteine bilden die Grundausstattung: eine Virtualisierungsschicht, ein Reverse Proxy mit automatisierten TLS-Zertifikaten, ein zentraler Identity Provider für Single Sign-on, Monitoring mit zentralen Logs, Backups nach der 3-2-1-Regel, ein fester Update-Rhythmus und eine Dokumentation, die auch im Ausfall erreichbar ist. Diese Infrastruktur baut man einmal sauber auf, statt sie für jede Anwendung neu zu improvisieren.

### Welcher Reverse Proxy eignet sich für den Einstieg?

Caddy eignet sich gut für den Einstieg, weil er TLS-Zertifikate standardmäßig automatisch holt und erneuert und knapp konfiguriert wird. Traefik passt zu containerlastigen Umgebungen, da er seine Konfiguration dynamisch aus Docker-Labels oder Kubernetes liest. nginx ist sehr verbreitet und flexibel; Zertifikate werden dort meist über einen separaten ACME-Client wie Certbot verwaltet.

### Warum muss die Erneuerung von TLS-Zertifikaten automatisiert werden?

Weil Zertifikatslaufzeiten deutlich kürzer werden. Das CA/Browser Forum hat 2025 beschlossen, die maximale Laufzeit öffentlicher TLS-Zertifikate schrittweise bis März 2029 auf 47 Tage zu senken. Let's Encrypt plant, sein Standardprofil im Februar 2027 auf 64 und im Februar 2028 auf 45 Tage umzustellen. Manuelle Zertifikatsverwaltung ist damit keine Option mehr; Ablaufdaten sollten zusätzlich überwacht werden.

### Wann sollte ein Unternehmen nicht selbst hosten?

Wenn niemand Zeit hat, Updates einzuspielen und Alarme zu beantworten – dann ist ein selbst betriebener Dienst ein Sicherheitsrisiko. Auch beim E-Mail-Versand, bei hohen Verfügbarkeitsanforderungen ohne Redundanz und bei regulatorisch anspruchsvollen Daten ohne Sicherheitskonzept ist ein Dienstleister oft besser. Ein Mittelweg ist, Open-Source-Software bei einem europäischen Hoster mit vertraglich gesichertem Datenexport betreiben zu lassen.

## Quellen

1. [Proxmox VE – Administrationshandbuch](https://pve.proxmox.com/pve-docs/)
2. [Caddy – Automatic HTTPS](https://caddyserver.com/docs/automatic-https)
3. [Traefik – Let's Encrypt / ACME](https://doc.traefik.io/traefik/https/acme/)
4. [nginx – Dokumentation](https://nginx.org/en/docs/)
5. [Let's Encrypt – Decreasing Certificate Lifetimes to 45 Days (02.12.2025)](https://letsencrypt.org/2025/12/02/from-90-to-45)
6. [CA/Browser Forum – Ballot SC-081v3 (verkürzte Zertifikatslaufzeiten)](https://cabforum.org/2025/04/11/ballot-sc081v3-introduce-schedule-of-reducing-validity-and-data-reuse-periods/)
7. [Keycloak – Projektseite](https://www.keycloak.org/)
8. [authentik – Dokumentation](https://docs.goauthentik.io/)
9. [Prometheus – Overview](https://prometheus.io/docs/introduction/overview/)
10. [Grafana – Dokumentation](https://grafana.com/docs/grafana/latest/)
11. [Uptime Kuma – GitHub](https://github.com/louislam/uptime-kuma)