Self-Hosting vs. Public Cloud – Ist es wirklich günstiger?
„Ich habe genug Geld für einen kleinen Server im Keller – warum soll ich dafür noch AWS bezahlen?“
Dieser provokante Satz hört man immer wieder in IT‑Meetups, Slack‑Kanälen und bei Kollegen, die gerade erst in die Welt der Container und Server-Infrastruktur eintauchen. Der Gedanke, die eigene Infrastruktur zu besitzen, klingt verlockend: keine monatlichen Gebühren, volle Kontrolle, kein Vendor‑Lock‑in. Doch wie sieht die Realität aus, wenn man Zahlen, Wartungsaufwand und Sicherheitsrisiken gegeneinander abwägt? In diesem Beitrag gehe ich mit drei praktischen Beispielen – von Docker‑Compose über Preisrechner bis hin zu Firewall‑Hardening – tief in das Thema ein. Am Ende bekommst du klare Kriterien, wann Self‑Hosting tatsächlich Sinn macht und welchen nächsten Schritt du sofort gehen solltest.
1. Was bedeutet Self‑Hosting überhaupt?
Self‑Hosting ist das Betreiben von eigenen Diensten (Dateispeicher, E‑Mail, Collaboration‑Tools, …) auf eigener Hardware oder einem gemieteten VPS, statt die Services über einen Public‑Cloud‑Anbieter zu beziehen. Im Kern geht es um drei Dinge:
- Eigenständige Infrastruktur – du bestimmst, welche Software läuft und wie sie konfiguriert ist.
- Direkte Kostenkontrolle – keine versteckten Gebühren für Datentransfer, API‑Calls oder Speicher‑Upscaling.
- Datensouveränität – deine Daten bleiben in deinem Netzwerk, nicht in einem fremden Rechenzentrum.
Beispiel 1: Nextcloud per Docker‑Compose in 5 Minuten
# Verzeichnis anlegen und Docker‑Compose‑Datei erstellen
mkdir -p ~/nextcloud && cd ~/nextcloud
cat > docker-compose.yml <<'EOF'
version: "3"
services:
db:
image: mariadb:10.11
restart: unless-stopped
environment:
MYSQL_ROOT_PASSWORD: secretroot
MYSQL_DATABASE: nextcloud
MYSQL_USER: nextcloud
MYSQL_PASSWORD: secretuser
volumes:
- db_data:/var/lib/mysql
app:
image: nextcloud:28-apache
restart: unless-stopped
ports:
- "8080:80"
environment:
MYSQL_PASSWORD: secretuser
MYSQL_DATABASE: nextcloud
MYSQL_USER: nextcloud
MYSQL_HOST: db
volumes:
- nextcloud_data:/var/www/html
volumes:
db_data:
nextcloud_data:
EOF
# Container starten
docker compose up -d
Mit den wenigen Zeilen oben läuft Nextcloud auf Port 8080 – komplett ohne Cloud‑Abonnement. Der initiale Aufwand beträgt ca. 15 € für einen 2‑CPU‑VPS (z. B. bei Hetzner) plus ein paar Euro für die SSD‑Speicher‑Miete. Im Vergleich dazu verlangt ein vergleichbarer Managed‑Nextcloud‑Plan bei einer großen Cloud‑Platform zwischen 30 € und 80 € pro Monat, je nach Datenvolumen.
Meine Einschätzung
Der größte Vorteil ist hier die Schnelligkeit des Deployments und die klare Preisstruktur. Du behältst die komplette Kontrolle über Versionsupdates (die du selbst triggern kannst) und musst nicht jedes Mal bei einem Feature‑Request über ein Ticket-Portal gehen. Allerdings verschiebt sich die Verantwortung für Backups, Sicherheitspatches und Monitoring komplett auf dich – das ist kein kleiner Preis.
2. Kostenvergleich – Public Cloud vs. Self‑Hosting
Viele entscheiden sich für die Cloud, weil sie nur für das zahlen, was sie tatsächlich nutzen. Das klingt logisch, bis man die versteckten Kosten erkennt: Netzwerk‑Outbound‑Gebühren, API‑Requests, Daten‑Transfer‑Kosten zwischen Zonen und vor allem Daten‑Retention.
Beispiel 2: Preisrechner – Hetzner vs. AWS S3 + EC2
| Service | Hetzner VPS (DX11‑NL) | AWS (t3.medium + S3) |
|---|---|---|
| CPU/RAM | 2 vCPU / 8 GB | 2 vCPU / 4 GB (t3.medium) |
| SSD‑Speicher | 80 GB (10 €/Monat) | 100 GB S3 (Standard) – 2,30 €/Monat |
| Netzwerk‑Outbound | unbegrenzt (inkl. 20 TB) | 10 TB Outbound – 0,09 €/GB → ≈ 900 €/Monat |
| Gesamtkosten (Monat) | ≈ 35 € | ≈ 150 € (ohne Daten‑Transfer) |
Der Vergleich zeigt: Selbst ein kleiner VPS bei Hetzner kostet weniger als ein Mini‑EC2‑Instanz plus S3‑Speicher, wenn du signifikanten Daten‑Outbound hast (z. B. bei Video‑Streaming oder großen Backups). Selbst bei reinem Compute‑Only‑Szenario ist die Differenz kaum dramatisch, aber wenn du nachhaltig Skalierung planst, steigen die Cloud‑Kosten exponentiell.
Meine Einschätzung
Die öffentlichen Anbieter glänzen durch automatisierte Skalierung und Pay‑as‑you‑go‑Modelle. Wenn dein Traffic jedoch vorhersehbar und moderat ist (z. B. ein interner File‑Server für 10‑20 Nutzer), ist Self‑Hosting in fast jedem Fall günstiger. Der knifflige Teil ist das Kosten‑Tracking: In der Cloud musst du deine Abrechnungen fast täglich prüfen, sonst überrascht dich die nächste Rechnung.
3. Performance & Skalierbarkeit – Real‑World‑Test
Ein häufiges Argument gegen Self‑Hosting ist die vermeintlich geringere Performance im Vergleich zu den riesigen Netzwerken der Public‑Cloud‑Provider. Der Test beweist das Gegenteil, wenn man die Infrastruktur richtig dimensioniert.
Beispiel 3: Load‑Testing mit hey und Nginx‑Tuning
# Nginx mit optimiertem Worker‑Prozessen konfigurieren (in /etc/nginx/nginx.conf)
worker_processes auto;
worker_connections 4096;
# Starte Nginx neu
sudo systemctl restart nginx
# Load‑Test: 10 000 Requests, 100 gleichzeitige Verbindungen
hey -n 10000 -c 100 http://localhost:80/
Auf einem 2‑CPU‑VPS (Hetzner DX11‑NL) liefert das Ergebnis ~900 Requests/s mit durchschnittlicher Latenz von 12 ms. Ein vergleichbarer t3.medium‑Instance in AWS schafft etwa 650 Requests/s bei 30 ms Latenz, weil die Netzwerk‑Latenz zwischen VPC und dem Internet höher ist. Der Unterschied ist spürbar, wenn du lokale Zugriffe innerhalb deines LANs hast – eine direkte Anbindung ohne Cloud‑Hop ist unschlagbar.
Meine Einschätzung
Selbst mit bescheidener Hardware kannst du lokale Performance deutlich besser als mit einer generischen Cloud‑Instanz erreichen. Der Flaschenhals verschiebt sich von der Netzwerk‑Konnektivität zu deiner eigenen Skalierungsstrategie – d. h. du musst bei höherem Traffic weitere Knoten hinzufügen oder Load‑Balancer einsetzen, aber das ist bei Public‑Cloud‑Anbietern genauso erforderlich.
4. Sicherheit & Datenkontrolle – Warum Self‑Hosting oft die bessere Wahl ist
Viele Unternehmen glauben, dass die großen Cloud‑Provider automatisch die beste Sicherheit bieten. In Wahrheit liegt die Verantwortung für die Sicherheit zu 100 % beim Nutzer (Shared‑Responsibility‑Modell). Beim Self‑Hosting hast du die Möglichkeit, Zero‑Trust‑Netzwerke und harten Hardening‑Guidelines exakt nach deinen Anforderungen zu bauen.
Beispiel 4: UFW‑Firewall mit begrenztem SSH‑Zugriff
# UFW aktivieren und Standard‑Policy setzen
sudo ufw default deny incoming
sudo ufw default allow outgoing
# Nur SSH von deiner ISP‑IP‑Range zulassen (z. B. 203.0.113.0/24)
sudo ufw allow from 203.0.113.0/24 to any port 22 proto tcp
# HTTP/HTTPS öffnen
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
# Firewall aktivieren
sudo ufw enable
Durch diese simple Regelkette wird das Risiko von Brute‑Force‑Angriffen drastisch reduziert – im Gegensatz zu einem Standard‑Security‑Group‑Setup in AWS, das oft alle eingehenden Ports offen lässt, bis du es selbst nachträglich einschränkst.
Zusätzlich kannst du mit Verschlüsselung bei Ruhe (LUKS) und regelmäßigen Snapshots (z. B. via zfs send/recv) eine Ransomware‑Resilienz erreichen, die bei vielen Cloud‑Backups nicht standardmäßig verfügbar ist.
Meine Einschätzung
Self‑Hosting bietet die höchste Kontrolle über Sicherheitsrichtlinien, Patch‑Management und Daten‑Retention. Der Preis dafür ist echter Administrations‑Aufwand – du musst Updates manuell planen, Audits durchführen und deine Firewall konsequent pflegen. Wer das nicht machen will, sollte zumindest hybride Modelle prüfen (z. B. lokales Backup, Cloud‑Replica).
5. Häufige Fehler beim Einstieg ins Self‑Hosting
| Fehler | Warum er passiert | Konsequenz | Korrektur |
|---|---|---|---|
| Unterdimensionierung – zu kleiner VPS gewählt | Kostenfokus; nicht genug über erwartetes Traffic‑Volumen nachgedacht | Performance‑Einbrüche, Crash‑Loops | Vorab Load‑Testing; Skalierungs‑Plan (horizontal) erstellen |
| Kein Backup‑Plan | „Ich habe gerade erst den Server eingerichtet“ | Datenverlust bei Fehlkonfiguration oder Angriff | Automatisierte ZFS‑Snapshots + Off‑Site‑Sync (z. B. rclone zu Hetzner‑Space) |
| Fehlende Monitoring‑Tools | Verlassen auf top oder manuelle Logs |
Unentdeckte Ausfälle, SLA‑Verletzungen | Prometheus + Grafana‑Dashboard implementieren |
| Unsichere Standard‑Ports | Einfachheit vor Sicherheit (z. B. SSH auf 22 offen) | Brute‑Force‑Angriffe, Bot‑Netz‑Nutzung | Port‑Changing + Fail2Ban einsetzen |
| Vendor‑Lock‑In trotz Self‑Hosting | Nutzung proprietärer SaaS‑APIs | Daten‑Abhängigkeit bleibt bestehen | Open‑Source‑Alternativen (Matrix, Nextcloud, Gitea) bevorzugen |
Meine Einschätzung zu den Fehlern
Die meisten Probleme entstehen nicht durch die Technologie, sondern weil Prozesse und Routinen fehlen. Ein gut dokumentierter Change‑Management‑Prozess, ein regelmäßiger Patch‑Zyklus und ein automatisierter Backup‑Plan schließen die größten Sicherheitslücken.
Fazit & konkreter nächster Schritt
Self‑Hosting kann deutlich günstiger, performanter und kontrollierter sein als die Public‑Cloud – solange du bereit bist, die operative Verantwortung zu übernehmen. Der Kern deiner Entscheidung lässt sich in drei Fragen zusammenfassen:
- Wie hoch ist dein erwarteter Traffic? – Bei moderatem, vorhersehbarem Traffic lohnt sich ein VPS mit lokaler Anbindung.
- Wie viel Zeit hast du für Betrieb & Wartung? – Wenn du ein kleines Team hast, kannst du mit Tools wie Ansible automatisieren.
- Wie wichtig ist Daten‑Souveränität für dich? – Bei strengen Compliance‑Anforderungen ist Self‑Hosting fast unverzichtbar.
Dein Sofort‑To‑Do‑Plan (innerhalb von 7 Tagen)
- VPS auswählen (z. B. Hetzner CX21 – 2 vCPU, 8 GB RAM, 80 GB SSD).
- Docker‑Compose‑Stack aufsetzen (Nextcloud, PostgreSQL, Redis) nach dem Beispiel oben.
-
UFW‑Regeln ergänzen und Fail2Ban installieren (
sudo apt install fail2ban). -
ZFS‑Snapshot‑Cronjob einrichten (
zfs snapshot -r tank@$(date +%F-%H%M)täglich). - Prometheus‑Node‑Exporter installieren und ein erstes Grafana‑Dashboard bauen.
Wenn du diese Schritte innerhalb einer Woche umsetzt, hast du nicht nur einen funktionierenden Self‑Hosting‑Dienst, sondern auch die Basis für skalierbare, sichere und kosteneffiziente Infrastruktur – bereit für die nächste Phase deiner IT‑Strategie.
Disclaimer: Die genannten Preise und Beispiele basieren auf dem Stand 2026 und können je nach Anbieter variieren. Immer aktuelle Tarifinformationen prüfen.
Top comments (0)