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

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

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

1. 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.
2. Kein Backup‑Plan – Oft werden Snapshots im Schlafmodus vergessen. Nutzen Sie dedizierte Backup‑Software (z. B. restic + rclone zu einem günstigen S3‑Kompatibel‑Anbieter).
3. Mangelnde Sicherheitsupdates – Ein veraltetes Kernel kann Angreifer öffnen. Automatisieren Sie unattended-upgrades und führen Sie wöchentliche apt-get update && apt-get upgrade durch.
4. Fehlende Monitoring‑Alarme – Ohne Metriken bleibt ein Ausfall unsichtbar. Installieren Sie Prometheus‑Alertmanager und konfigurieren Sie Slack‑ oder E‑Mail‑Benachrichtigungen.
5. Ü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

1. Inventarisieren – Erstellen Sie eine Liste aller Cloud‑Dienste, die Sie derzeit nutzen, inkl. Monatskosten.
2. Pilot‑Projekt – Setzen Sie innerhalb von 48 Stunden einen Docker‑Compose‑Stack (Nextcloud) auf einem Raspberry Pi oder einer VM auf.
3. Kosten‑Tracking – Nutzen Sie telegraf + influxdb für Strom‑ und Netzwerk‑Metriken und visualisieren Sie das Ergebnis in Grafana.
4. 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.