Warum Self-Hosting?

Die Entscheidung für Self-Hosting ist keine ideologische, sondern eine pragmatische. Meine Gründe:

  • Kosten: Ein kleiner Dedicated Server kostet 30-50€/Monat. Vergleichbare AWS-Leistung das 3-5-Fache.
  • Datenkontrolle: Kein Vendor, kein Daten-Sharing, volle DSGVO-Kontrolle
  • Lerneffekt: Wer Infrastruktur selbst betreibt, versteht sie auch – das macht einen besseren Entwickler
  • Keine Überraschungsrechnungen: Cloud-Kosten können bei Traffic-Spitzen explodieren

Das bedeutet nicht, dass Self-Hosting für jeden richtig ist. Es bedeutet, dass es für mein Setup die beste Wahl ist.

Der Stack: k3s + Rancher

k3s als Kubernetes-Distribution

k3s von Rancher Labs ist eine schlanke Kubernetes-Distribution mit weniger als 70 MB. Im Gegensatz zu vollständigem Kubernetes läuft k3s auf einem einzelnen Server (1 vCPU, 2 GB RAM reichen für den Start).

Was k3s bietet:

  • Vollständige Kubernetes API: kubectl, Helm-Charts, Custom Resources – alles funktioniert
  • Eingebauter Ingress Controller: Traefik ist vorinstalliert und konfiguriert
  • SQLite oder etcd: Für Einzelserver-Setups reicht SQLite, für HA-Cluster etcd
  • Automatische TLS via cert-manager: Let's Encrypt in wenigen Minuten konfiguriert
# k3s Installation in einer Zeile
curl -sfL https://get.k3s.io | sh -

Rancher als Management-Layer

Rancher ist ein Open-Source Kubernetes-Management-Tool mit einer vollständigen Web-UI. Ich nutze es für:

  • Cluster-Übersicht und Health-Monitoring
  • Workload-Management (Deployments, StatefulSets, DaemonSets)
  • Helm-Chart-Deployments über den Rancher-Katalog
  • User- und RBAC-Management

Was ich betreibe

Auf meinem k3s-Cluster laufen derzeit:

Service Tool
Headless CMS Strapi
Medien-Speicher MinIO (S3-kompatibel)
Datenbank PostgreSQL
Monitoring Grafana + Prometheus + Loki
Reverse Proxy Traefik
Container Registry Harbor
CI/CD GitLab
Secrets Sealed Secrets
Backups Velero + MinIO

Stolperfallen beim Self-Hosting

1. Persistenter Speicher

Kubernetes-Pods sind ephemer – Daten müssen in Persistent Volumes gespeichert werden. Auf einem Einzelserver empfehle ich Longhorn als distributed storage system oder einfach local-path für unkritische Workloads.

2. Backups

Ohne automatische Backups ist kein Self-Hosting-Setup produktionsreif. Mein Setup:

  • Datenbankdumps via CronJob in MinIO
  • Longhorn-Snapshots für Volume-Backups
  • Velero für Kubernetes-Ressourcen-Backups

3. TLS/Certificates

Mit cert-manager und Let's Encrypt ist automatisches TLS kein Problem mehr:

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: me@example.com
    privateKeySecretRef:
      name: letsencrypt-prod
    solvers:
    - http01:
        ingress:
          class: traefik

4. Monitoring & Alerting

Was man nicht überwacht, wird man nicht rechtzeitig reparieren. Der kube-prometheus-stack Helm-Chart installiert Prometheus, Grafana und AlertManager in einer Zeile und bietet sofort nutzbare Dashboards für CPU, Memory, Network und Pod-Health.

Fazit: Lohnt sich Self-Hosting?

Für Entwickler, die Infrastruktur verstehen wollen und die Kontrolle über ihre Daten schätzen: Ja, definitiv. Der Aufwand für den initialen Setup (2-3 Tage) zahlt sich schnell aus. Monatliche Kosten sind planbar, Daten bleiben unter eigener Kontrolle, und man lernt nebenbei enormes Infrastruktur-Wissen.

Für Teams ohne Ops-Expertise oder Projekte mit unvorhersehbarem Traffic-Wachstum: Managed Cloud ist oft die bessere Wahl. Self-Hosting verlangt Eigenverantwortung – und das ist keine schlechte Sache.