Self‑Hosting vs. Cloud – Warum das alte Modell plötzlich günstiger wirft
Hook: Wer kennt das nicht – das monatliche Cloud‑Rechnungspapier liegt wieder im Briefkasten, das Geld für Compute, Storage und Datenverkehr schleicht sich leise zusammen und das ganze „Flexibel. Skalierbar. Wartung inklusive.“ klingt plötzlich nach einem teuren All‑You‑Can‑Eat‑Buffet. Ich habe das Jahr 2024 mit drei eigenen Self‑Hosting‑Projekten abgeschlossen und will Ihnen jetzt zeigen, warum das alte Modell nicht nur ein Hobby mehr ist, sondern unter den richtigen Bedingungen echte Kostenvorteile bringt – und wo die Schattenseiten lauern.
Was ist Self‑Hosting?
Self‑Hosting bedeutet, dass Sie Infrastruktur, Betriebssystem und Anwendungen selbst betreiben – sei es im Keller, im eigenen Büro‑Rechenraum oder auf gemieteten Bare‑Metal‑Servern. Im Kern geht es um die Kontrolle über Hardware, Netzwerk und Daten. Statt Ressourcen von AWS, GCP oder Azure zu leasen, kaufen Sie physische Geräte oder mieten dedizierte Server und verwalten alles selbst.
Beispiel 1 – Raspberry Pi 4 als Mini‑Server
# Raspberry Pi OS installieren und Docker setzen
echo "deb [arch=arm64] https://download.docker.com/linux/debian $(lsb_release -cs) stable" \
| sudo tee /etc/apt/sources.list.d/docker.list
sudo apt-get update && sudo apt-get install -y docker-ce docker-ce-cli containerd.io
# Nextcloud‑Container starten
sudo docker run -d \
-e MYSQL_PASSWORD=secret \
-e MYSQL_DATABASE=nextcloud \
-e MYSQL_USER=nextcloud \
-e MYSQL_HOST=db \
-p 8080:80 \
--name nextcloud \
nextcloud:latest
Einschätzung: Auf einem Pi‑Board liegen die Anfangsinvestitionen bei ~80 €, die Betriebskosten (Strom, 5 V·A) sind vernachlässigbar. Für private Nutzung (bis 5 TB Daten) ist das ein echter Geldsparer gegenüber einem vergleichbaren S3‑Bucket (ca. 30 €/Monat).
Kostenvergleich – Self‑Hosting vs. Public Cloud
1. Hardware‑Investition vs. Pay‑As‑You‑Go
| Szenario | Anschaffungskosten (einmalig) | Monatliche Betriebs‑ & Stromkosten | Gesamtkosten 24 Monate |
|---|---|---|---|
| Raspberry Pi 4 + 2 TB SSD | 120 € (Pi + Gehäuse + SSD) | 5 € (Strom ≈ 12 W) | 150 € |
| Hetzner Dedicated (CX31) | 0 € (Miete) | 39 € (CPU, RAM, Storage) | 936 € |
| AWS EC2 t3.medium + 2 TB EBS | 0 € (Miete) | 73 € (Compute) + 25 € (EBS) | 2.352 € |
Einschätzung: Selbst‑gehostete Bare‑Metal‑Server (z. B. Hetzner) brechen bereits nach 12‑18 Monaten mit den Cloud‑Kosten ein. Der Hauptfaktor: Daten‑Transfer‑Kosten – Public Cloud verlangt Geld für jeden ausgehenden Gigabyte.
2. Personal‑ und Sicherheitsaufwand
| Kostenfaktor | Self‑Hosting | Public Cloud |
|---|---|---|
| Monitoring | Open‑Source‑Tools (Prometheus, Grafana) – Zeitaufwand ≈ 4 h/Monat | Managed‑Services (CloudWatch) – Kosten inkl. Service‑Gebühr |
| Backup | Deduplizierung mittels Proxmox Backup Server – 0 € (Software) | S3‑Versionierung – 0,023 €/GB/Monat |
| Security Patches | Manuell/automatisiert (apt‑cron) – 1 h/Monat | In‑place vom Anbieter (keine direkte Arbeit) |
Einschätzung: Der Aufwand ist messbar, aber planbar. Während Cloud‑Anbieter das Patch‑Management übernehmen, erhalten Sie volle Transparenz und können kritische Updates zeitnah ausrollen – ein klarer Vorteil für Datenschutz‑bewusste Unternehmen.
Praktische Umsetzung – Drei reale Self‑Hosting‑Projekte
2.1 Nextcloud auf einem Home‑Server (Docker‑Compose)
# docker-compose.yml
version: "3.8"
services:
db:
image: mariadb:10.11
restart: unless-stopped
environment:
MYSQL_ROOT_PASSWORD: supersecret
MYSQL_DATABASE: nextcloud
MYSQL_USER: nextcloud
MYSQL_PASSWORD: nextcloud
volumes:
- db-data:/var/lib/mysql
app:
image: nextcloud:28-fpm
restart: unless-stopped
depends_on:
- db
environment:
MYSQL_HOST: db
MYSQL_DATABASE: nextcloud
MYSQL_USER: nextcloud
MYSQL_PASSWORD: nextcloud
ports:
- "8080:80"
volumes:
- nextcloud-data:/var/www/html
volumes:
db-data:
nextcloud-data:
Einschätzung: Mit einer einzigen docker‑compose up -d erhalten Sie ein vollständig funktionierendes Filesharing‑Portal. Der monatliche Preis für das Gerät (inkl. SSD, 2 TB) liegt bei ~5 €, was im Vergleich zu einem vergleichbaren OneDrive‑Business‑Plan (≈ 10 €/Monat) ein deutlicher Vorteil ist.
2.2 GitLab CE auf Hetzner (Bare‑Metal, Ansible)
# ansible/playbook.yml
- hosts: gitlab
become: true
tasks:
- name: Install Docker
apt:
name: docker.io
state: present
- name: Pull GitLab image
docker_image:
name: gitlab/gitlab-ce
tag: latest
- name: Start GitLab container
docker_container:
name: gitlab
image: gitlab/gitlab-ce:latest
env:
GITLAB_OMNIBUS_CONFIG: |
external_url 'http://gitlab.example.com'
ports:
- "80:80"
- "22:22"
volumes:
- /srv/gitlab/config:/etc/gitlab
- /srv/gitlab/logs:/var/log/gitlab
- /srv/gitlab/data:/var/opt/gitlab
restart_policy: always
Einschätzung: Der ganze Stack lässt sich mit einem einzigen Ansible‑Durchlauf automatisieren. Die monatlichen Kosten für den Hetzner‑Server (CX31) betragen 39 €, während ein vergleichbarer GitLab‑Premium‑Plan in AWS leicht über 100 € kostet.
2.3 Kubernetes‑Cluster auf günstigen VPS (k3s + Helm)
# 3‑Node k3s mit Rancher
for i in 1 2 3; do
ssh root@node${i} "curl -sfL https://get.k3s.io | sh -"
done
# Install Helm
curl https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3 | bash
# Deploy Prometheus
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm install prom prometheus-community/kube-prometheus-stack
Einschätzung: Drei günstige VPS (je 5 €/Monat) ergeben ein produktives K8s‑Cluster für 15 €/Monat – inkl. Monitoring. Im Vergleich zu einem verwalteten GKE‑Cluster (ab 70 €/Monat) spart man mehr als 50 % bei vergleichbarer Skalierbarkeit.
Häufige Fehler beim Self‑Hosting
- Unterschätzung der Netzwerk‑Bandbreite – Externe Zugriffe über DSL können bei 100 Mbps schnell zur Flaschenhals werden. Lösung: QoS‑Regeln und ggf. ein dedizierter Business‑Internet‑Anschluss.
-
Kein Backup‑Plan – Oft werden Snapshots im Schlafmodus vergessen. Nutzen Sie dedizierte Backup‑Software (z. B.
restic+rclonezu einem günstigen S3‑Kompatibel‑Anbieter). -
Mangelnde Sicherheitsupdates – Ein veraltetes Kernel kann Angreifer öffnen. Automatisieren Sie
unattended-upgradesund führen Sie wöchentlicheapt-get update && apt-get upgradedurch. - Fehlende Monitoring‑Alarme – Ohne Metriken bleibt ein Ausfall unsichtbar. Installieren Sie Prometheus‑Alertmanager und konfigurieren Sie Slack‑ oder E‑Mail‑Benachrichtigungen.
- Überdimensionierung – Viele starten mit zu viel RAM/CPU, weil Cloud‑Preise irreführend sind. Beginnen Sie klein, messen Sie Auslastung und skalieren Sie dann gezielt.
Fazit & nächster Schritt
Selbst‑hosting kann – bei richtiger Planung – deutlich günstiger sein als jede Public‑Cloud‑Option, weil Sie Hardware‑Kosten, Daten‑Transfer‑Gebühren und Service‑Gebühren kontrollieren. Der größte Mehrwert liegt jedoch in Transparenz und Daten‑Souveränität: Sie entscheiden, wo Ihre Daten landen und wer sie sehen darf.
Mein persönlicher Rat: Starten Sie mit einem kleinen, aber produktiven Use‑Case (z. B. Nextcloud auf einem alten NAS). Dokumentieren Sie Strom‑ und Bandbreiten‑Kosten für einen Monat, vergleichen Sie diese mit Ihrer aktuellen Cloud‑Rechnung und entscheiden Sie dann, ob Sie das Setup ausbauen wollen.
Konkreter nächster Schritt für Sie
- Inventarisieren – Erstellen Sie eine Liste aller Cloud‑Dienste, die Sie derzeit nutzen, inkl. Monatskosten.
- Pilot‑Projekt – Setzen Sie innerhalb von 48 Stunden einen Docker‑Compose‑Stack (Nextcloud) auf einem Raspberry Pi oder einer VM auf.
-
Kosten‑Tracking – Nutzen Sie
telegraf+influxdbfür Strom‑ und Netzwerk‑Metriken und visualisieren Sie das Ergebnis in Grafana. - Entscheidung – Wenn die Pilot‑Kosten 30 % unter Ihren Cloud‑Kosten liegen, planen Sie die Migration der nächsten beiden Services (z. B. GitLab, Prometheus) in Ihr Self‑Hosting‑Umfeld.
Durch konsequente Messung und schrittweisen Roll‑out vermeiden Sie Überraschungen und sichern sich langfristig finanzielle und datenschutztechnische Vorteile.
Hinweis: Selbst‑Hosting ist kein Allheilmittel. Für extreme Lastspitzen, globale CDN‑Bedarfe oder regulatorisch festgeschriebene Zertifizierungen (z. B. ISO 27001‑Audits) bleibt die Public‑Cloud oft die bessere Wahl. Das Ziel ist ein ausgewogenes Hybrid‑Modell, bei dem Sie die Kern‑Workloads selbst betreiben und nur seltene, burst‑intensive Prozesse in die Cloud auslagern.
Top comments (0)