DEV Community

Uhltak Therestismysecret
Uhltak Therestismysecret

Posted on

Self-Hosting vs. Cloud: Was wirklich günstiger ist und wie Sie starten

#selfhosting #cloudalternative #kostenvergleich #infrastruktur

Self‑Hosting vs. Cloud – Der realistische Kosten‑Check und ein sofortiger Fahrplan

"Ich spare Geld, indem ich meine eigene Cloud baue – und das ohne monatliche Rechnungen?" – Dieser Satz klingt nach Marketing‑Versprechen. In der Praxis steht er jedoch zwischen Traum und Alptraum. Ich habe die letzten zwei Jahre damit verbracht, meine private Infrastruktur zu bauen, zu betreiben und ständig zu skalieren. Nun zeige ich Ihnen, warum Self‑Hosting nicht per Definition günstiger ist, wo echte Einsparungen lauern und wie Sie ohne Blindgänger starten können.

1. Warum Self‑Hosting verlockend ist – und was dahinter steckt

Erklärung

Self‑Hosting bedeutet, dass Sie Dienste – von Datei‑Sharing bis CI/CD – auf eigener Hardware oder in einem gemieteten Rechenzentrum betreiben, anstatt sie von Amazon, Google oder Microsoft zu beziehen. Der Reiz liegt auf der Hand:

  • Kontrolle über Daten, Updates und Netzwerk‑Topologie.
  • Keine versteckten Kosten – Sie zahlen einmal für das Gerät, nicht im Abonnement.
  • Lernkurve – Sie werden zum Administrator, DevOps‑Engineer und Sicherheits‑Chef zugleich.

Beispiel 1 – Ein kleiner Nextcloud‑Server 

# 1. Hardware: 2 TB HDD + 8 GB RAM (ein günstiger Intel NUC)
# 2. OS‑Installation (Debian 12)
sudo apt update && sudo apt install -y curl gnupg2
# 3. Docker‑Engine (offizielle Anleitung)
curl -fsSL https://get.docker.com | sh
sudo usermod -aG docker $USER
# 4. Nextcloud‑Container starten
docker run -d \
  --name nextcloud \
  -p 8080:80 \
  -v nextcloud_data:/var/www/html \
  -e SQLITE_DATABASE=nextcloud \
  nextcloud:latest
Enter fullscreen mode Exit fullscreen mode

Der ganze Stack kostet unter 150 € für das Gerät. Im ersten Jahr laufen die Energiekosten (ca. 30 €) und die Internet‑Gebühr (50 €), also rund 230 € komplett ohne Cloud‑Rechnung.

Persönliche Einschätzung

Für einen Einzelnutzer oder ein kleines Team liefert dieser Ansatz sofortige Einsparungen gegenüber einer vergleichbaren Nextcloud‑Instanz bei Microsoft 365 (≈ 120 € / Jahr). Der Haken: Sie tragen die komplette Verantwortung für Updates, Backups und Sicherheit – das ist kein „Set‑and‑Forget".

2. Der harte Kostenvergleich – Self‑Hosting vs. Public‑Cloud

Erklärung

Viele vergleichen nur die monatlichen Rechnung. Dabei übersehen sie drei wesentliche Kostenblöcke:

  1. Kapitalaufwand (CAPEX) – Anschaffung von Server, SSDs, Netzteil.
  2. Betriebskosten (OPEX) – Strom, Netzwerk, Wartung, Ersatzteile.
  3. Hidden Costs – Zeitaufwand für Administration, Ausfallsicherheit, Compliance.

Beispiel 2 – Rechenzentren‑Miete vs. eigene Hardware

Position Public‑Cloud (AWS t3.medium, 2 vCPU, 4 GB RAM) Self‑Hosting (1 x Intel Xeon E‑2224G, 32 GB RAM)
Monatliche Rechnung 27 € (On‑Demand) 0 € (Eigene Strom‑ und Netzwerk‑Kosten)
Anschaffung – 800 € (Server + 2 TB NVMe)
Strom (365 kWh) 50 € (geschätzt) 70 € (typisch 200 W × 24 h × 365 d)
Bandbreite 0 € (first‑GB‑free, danach ~0,09 €/GB) 30 € (Fiber‑Anschluss)
Gesamtkosten 1 Jahr 324 € 900 €

Persönliche Einschätzung

Auf Erstinvestitionsbasis wirkt Self‑Hosting deutlich teurer. Für kurz‑ bis mittelfristige Projekte (< 2 Jahre) lohnt sich die Cloud eher. Langfristig (≥ 3 Jahre) kann bereits ab der 3.‑bis‑4. Jahr‑Marke die Amortisation greifen – vorausgesetzt, Sie betreiben das System mit hoher Auslastung (> 50 %).

3. Praktische Umsetzung – Aufbau eines Home‑Lab mit Proxmox

Erklärung

Proxmox VE (Virtual Environment) ist my‑go‑to‑Tool, wenn es um das Management von KVM‑VMs und LXC‑Containern auf einem einzigen Host geht. Es kombiniert ein web‑basiertes UI, native Backup‑Lösungen und ein aktives Community‑Repository.

Beispiel 3 – Installation von Proxmox auf einer gebrauchten Dell PowerEdge R640 (2 x Intel Xeon 6248R, 128 GB RAM) 

# 1. ISO von proxmox.com herunterladen
wget https://downloads.proxmox.com/iso/proxmox-ve_8.2-2.iso
# 2. ISO per iDRAC auf Server laden und Booten (iDRAC → Virtual Media → Attach ISO)
# 3. Installationsschritte folgen – nur root‑Passwort festlegen
# 4. Netzwerk‑Brücke einrichten (eth0 -> vmbr0)
cat > /etc/network/interfaces <<'EOF'
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet manual

auto vmbr0
iface vmbr0 inet static
    address 192.168.1.10/24
    gateway 192.168.1.1
    bridge_ports eth0
    bridge_stp off
    bridge_fd 0
EOF
systemctl restart networking
# 5. Web‑UI öffnen: https://192.168.1.10:8006
Enter fullscreen mode Exit fullscreen mode

Danach können Sie innerhalb von Minuten eine LXC‑Nextcloud‑Instanz oder eine KVM‑GitLab‑VM starten.

Persönliche Einschätzung

Der Clou: Proxmox ermöglicht Ihnen, mehrere Services auf einer einzigen physischen Maschine zu isolieren – ohne Docker‑Komplexität. Der Preisfaktor sinkt, sobald Sie nicht mehr nur ein Gerät, sondern ein Cluster aus 2‑3 Nodes betreiben. Der Verwaltungs‑Overhead bleibt jedoch gering, weil alles über das UI gesteuert wird.

4. Service‑Beispiele – Was lässt sich sinnvoll selbst hosten?

Erklärung

Ein Self‑Hosting‑Portfolio sollte aus mindestens drei Kategorien bestehen: Datei‑/Collaboration‑Tools, CI/CD‑Pipeline und objektbasierter Speicher.

Beispiel 4‑a – Nextcloud + OnlyOffice (File‑Sharing + Office‑Suite) 

# Docker‑Compose für Nextcloud + OnlyOffice
cat > docker-compose.yml <<'EOF'
version: '3'
services:
  db:
    image: mariadb:10.11
    restart: always
    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: always
    ports:
      - "8080:80"
    links:
      - db
    volumes:
      - nextcloud:/var/www/html
    environment:
      MYSQL_PASSWORD: secretUser
      MYSQL_DATABASE: nextcloud
      MYSQL_USER: nextcloud
      MYSQL_HOST: db
    depends_on:
      - db

  onlyoffice:
    image: onlyoffice/documentserver:latest
    restart: always
    ports:
      - "8443:443"
    environment:
      - JWT_SECRET=supersecret
    volumes:
      - onlyoffice_data:/var/www/onlyoffice/Data

volumes:
  db_data:
  nextcloud:
  onlyoffice_data:
EOF
docker compose up -d
Enter fullscreen mode Exit fullscreen mode

Sie erhalten eine vollständige Office‑Suite ohne monatliche Lizenz.

Beispiel 4‑b – GitLab CI/CD (Selbstgehostete Pipelines) 

# GitLab‑Omnibus‑Installation auf einer KVM‑VM (Ubuntu 22.04)
sudo apt update && sudo apt install -y curl ca-certificates
curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ee/script.deb.sh | sudo bash
sudo EXTERNAL_URL="http://gitlab.local" apt-get install -y gitlab-ee
# Nach Installation: sudo gitlab-ctl reconfigure
Enter fullscreen mode Exit fullscreen mode

Damit können Sie unbegrenzt private Repositories hosten – ideal für Unternehmen, die sensible Code‑Bases nicht in der Public‑Cloud ausliefern wollen.

Beispiel 4‑c – MinIO (Objektspeicher kompatibel zu S3) 

docker run -d \
  --name minio \
  -p 9000:9000 -p 9001:9001 \
  -e MINIO_ROOT_USER=admin \
  -e MINIO_ROOT_PASSWORD=SuperSecret123 \
  -v /mnt/minio-data:/data \
  minio/minio server /data --console-address ":9001"
Enter fullscreen mode Exit fullscreen mode

Ein kleiner Raspberry Pi 4 mit 4 TB USB‑SSD wird zum private S3‑Endpoint – perfekt für Backups und Media‑Archive.

Persönliche Einschätzung

Die drei Beispiele decken die gängigsten Unternehmens‑Use‑Cases ab. Der Mehrwert liegt nicht nur im Preis, sondern in der Unabhängigkeit von Vendor‑APIs. Der Nachteil: Jede Komponente muss manuell gesichert und aktualisiert werden – ein Aufwand, den Sie in Ihrem Personal‑Budget einplanen müssen.

5. Sicherheit & Wartung – Warum der Preis nicht nur in Euro gemessen wird

Erklärung

Ein Self‑Hosting‑Setup ist nur dann sinnvoll, wenn es sicher und verlässlich ist. Drei Kernbereiche verlangen Ihre Aufmerksamkeit:

  1. Netzwerk‑Hardening – Firewall‑Regeln, Fail2Ban und SSH‑Hardening.
  2. Backup‑Strategie – 3‑2‑1 (drei Kopien, auf zwei Medientypen, ein Exemplar off‑site).
  3. Patch‑Management – Automatisierte Updates (unattended‑upgrades) und Monitoring (Prometheus + Grafana).

Beispiel 5‑a – iptables‑Regeln für einen Proxmox‑Host 

# Nur SSH von meinem Büro‑IP, sonst alles blocken
iptables -A INPUT -p tcp -s 203.0.113.25 --dport 22 -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -j DROP
# Proxmox‑Web‑UI nur intern (192.168.1.0/24)
iptables -A INPUT -p tcp -s 192.168.1.0/24 --dport 8006 -j ACCEPT
iptables -A INPUT -p tcp --dport 8006 -j DROP
# Alle anderen Verbindungen zulassen (VM‑Traffic wird über Bridge gemanaged)
iptables -A INPUT -j ACCEPT
Enter fullscreen mode Exit fullscreen mode

Beispiel 5‑b – automatisierte Snapshots mit zfs (falls ZFS auf Proxmox) 

# Wöchentlicher Snapshot aller Datasets
zfs snapshot -r rpool/data@$(date +%Y-%m-%d)
# Aufbewahrung: 4 Wochen
zfs destroy -r rpool/data@$(date -d "-4 weeks" +%Y-%m-%d) || true
Enter fullscreen mode Exit fullscreen mode

Beispiel 5‑c – unattended‑upgrades für Debian‑Basis‑Server 

apt install -y unattended-upgrades
dpkg-reconfigure -plow unattended-upgrades
# Konfiguration prüfen
cat /etc/apt/apt.conf.d/50unattended-upgrades
Enter fullscreen mode Exit fullscreen mode

Persönliche Einschätzung

Sicherheit kostet Zeit. Die obigen Scripts dauern insgesamt weniger als 30 Minuten, aber sie erfordern regelmäßige Audits. Wer das nicht einplant, riskiert schnell einen Datenverlust, der die anfänglichen Kosteneinsparungen sofort zunichtemacht.

Häufige Fehler – Warum Self‑Hosting oft scheitert

  1. Überschätzung der Nutzerzahl – Ein einzelner Server gerät schnell an seine Grenzen, wenn die Last unerwartet steigt (z. B. Viral‑Uploads).
  2. Kein Redundanz‑Plan – Ohne HA‑Cluster oder externe Backups kann ein einzelner Hardware‑Defekt das ganze Business lahmlegen.
  3. Komplexe Lizenz‑Modelle übersehen – Einige Open‑Source‑Tools (z. B. Red Hat‑Versionen) erfordern kostenpflichtige Subscriptions, wenn man Support will.
  4. Fehlende Monitoring‑Kultur – Ohne Grafana‑Dashboards oder Alert‑Systeme wird ein Ausfall erst bemerkt, wenn Kunden bereits klagen.
  5. Sicherheits‑Blindheit – Ein offenes Port‑Forwarding ohne Authentifizierung führt schnell zu Kompromittierungen.

Fazit & Dein nächster Schritt

Self‑Hosting ist kein Allheilmittel, aber es kann günstiger sein – vorausgesetzt, Sie planen Kapital, Betrieb und Wartung realistisch. Meine Drei‑Stufen‑Roadmap für den sofortigen Einstieg:

  1. Pilot‑Phase (1‑Monat) – Besorgen Sie sich ein günstiges Mini‑PC (z. B. Intel NUC), installieren Sie Proxmox und setzen Sie einen Nextcloud‑Container auf. Messen Sie den Strom‑ und Arbeitsaufwand.
  2. Skalierungs‑Phase (3‑Monate) – Ergänzen Sie einen zweiten Node, aktivieren Sie ZFS‑Snapshots und implementieren Sie ein zentrales Monitoring (Prometheus + Grafana). Testen Sie Failover‑Szenarien.
  3. Produktions‑Phase (6‑Monate) – Migrieren Sie kritische Workloads (GitLab, MinIO) und etablieren Sie ein 3‑2‑1‑Backup‑Konzept mit einem Off‑Site‑Standort (z. B. ein günstiger VPS für Snapshots).

Handeln Sie jetzt: Laden Sie die aktuelle Proxmox‑ISO herunter, setzen Sie das Docker‑Compose‑File für Nextcloud auf und starten Sie das erste Monitoring‑Dashboard. Danach entscheiden Sie, ob Sie den nächsten Schritt – ein zweites Node oder einen Cloud‑Spiegel – gehen wollen.

Selbst‑hosting zahlt sich aus, wenn Sie es **kontrolliert* und systematisch angehen. Auf die eigene Infrastruktur zu vertrauen, bedeutet, den eigenen Preis zu bestimmen – nicht den Provider.*

Top comments (0)