Warum sollte man Self-Hosting betreiben?

 (romanzipp.com)
17 Punkte von GN⁺ 2025-10-11 | 1 Kommentare | Auf WhatsApp teilen
  • Durch Self-Hosting persönlicher Dienste kann man sich der Überwachung durch Big Tech und Regierungen entziehen und Privatsphäre sowie Datensouveränität sichern
  • Sensible persönliche Daten wie Kalender, Kontakte und Standortinformationen geben weit mehr preis, als man denkt, und sollten direkt verwaltet werden, statt von Unternehmen wie Google oder Apple abhängig zu sein
  • In einer Situation, in der Tech-Unternehmen ohne erkennbaren Grund Konten sperren oder proprietäre APIs statt Protokollen erzwingen, gewährleistet der Betrieb eigener Server auf Basis offener Standardprotokolle digitale Souveränität
  • Vorgestellt werden praktische Self-Hosting-Dienste wie CalDAV/CardDAV-Server, Mailserver, Home Assistant, RSS-Reader und Standort-Tracker sowie konkrete Software-Optionen
  • Trotz der Komplexität der Ersteinrichtung ist es für Datenschutz und technische Unabhängigkeit wichtig, sich langfristig die Kontrolle über die eigenen Daten und die Stabilität der Dienste zu sichern

Warum man Self-Hosting wählen sollte

  • Nachdem ich kürzlich meine Homelab-Umgebung mit einem Kollegen geteilt hatte, wurde ich gefragt: „Warum installiert man überhaupt selbst Server, richtet Container ein und gibt viel Geld für Hardware aus, um sich diesen Aufwand anzutun?“
  • Ausgehend von dieser Frage erkläre ich die wichtigsten Motive für Self-Hosting und konkret, welche Dienste man tatsächlich selbst hosten kann

Privatsphäre

  • Privatsphäre ist kein automatisch gewährtes Recht, sondern ein Recht, für das man kämpfen muss
  • Big-Tech-Unternehmen und einige Regierungen versuchen weiterhin, Einblick in das Privatleben von Menschen zu bekommen, etwa durch Vorhaben wie die Chatkontrolle der EU
  • Wer Dienste selbst hostet, kann das Risiko von Überwachung reduzieren oder ganz beseitigen, braucht dafür aber technisches Wissen
  • Indem man Familie oder Bekannten Dienste bereitstellt, kann man auch ihnen zu mehr Datenunabhängigkeit verhelfen

  • Kalender & Kontakte

    • Kalender geben mehr Informationen preis, als man erwartet
      • Neben Identitätsdaten auch regelmäßige Treffen, Informationen über Familie, Kollegen und vertrauliche Geschäftstermine
      • Gesundheitsinformationen durch Arzttermine sowie Schlaf- und Trainingsroutinen
      • Rechtliche Verpflichtungen und Finanzinformationen wie Kredittermine oder Abonnements
      • Politische Überzeugungen durch die Teilnahme an Demonstrationen
      • Daraus lässt sich ableiten, wann jemand erreichbar ist, was sich für Identitätsdiebstahl nutzen lässt
    • Kontaktdaten sind ebenso sensibel
      • Über Social Graphs und Metadaten wie Suchverlauf oder Erstellungsdatum lassen sich persönliche Informationen ableiten
      • Beispiel: Wenn plötzlich viele Kontakte mit demselben Geschlecht und nur Vornamen auftauchen, könnte man auf Dating schließen; ein neu angelegter Kontakt für einen Therapeuten kann auf einen Besuch in psychologischer Behandlung hindeuten
    • Den meisten Menschen ist nicht bewusst, wo ihre Social-Graph-Daten gespeichert werden; tatsächlich verarbeiten sie Unternehmen wie Google, Apple oder Samsung
    • Selbst Apples Advanced Data Protection bedeutet nicht, dass Kalender und Kontakte Ende-zu-Ende verschlüsselt sind

  • Standortdaten

    • Vor einigen Jahren entdeckte ich bei der Nutzung von Android und Google Maps in meinem Google-Konto detaillierte Standortverläufe über mehrere Jahre
      • Eine Funktion, die ich nie bewusst aktiviert hatte, protokollierte automatisch jede Bewegung und jeden besuchten Ort mit Geokoordinaten
    • Das war faszinierend, aber auch beängstigend, und ich wollte die Daten selbst kontrollieren und sicherstellen, dass nur ich darauf zugreifen kann

  • Sonstiges

    • Alle Wege aufzulisten, wie Daten getrackt werden, und warum man sich dessen bewusst sein sollte, würde den Rahmen dieses Artikels sprengen
    • Ziel ist es, zur eigenen Reise in dieses Thema zu motivieren

Souveränität

  • Digitale Souveränität bedeutet, die eigenen Daten zu kontrollieren, zu entscheiden, was mit ihnen geschieht, und zu bestimmen, mit wem sie geteilt werden

  • Problem mit Kontosperrungen

    • Immer wieder werden Fälle bekannt, in denen Tech-Unternehmen ohne offensichtlichen Grund Konten sperren; ich habe das in der Vergangenheit selbst bei Google erlebt
    • Ich möchte nicht von der Gnade riesiger Tech-Konzerne abhängen, die man nicht einmal kontaktieren kann oder die einen an einen KI-Chatbot verweisen
    • Es ist fraglich, warum Regulierungsbehörden von Tech-Unternehmen nicht verlangen, eine Kontaktmöglichkeit zu realen Menschen bereitzustellen

  • Protokolle und Standards

    • Ich bevorzuge Protokolle und Dateistandards
      • Statt einer „Gmail“-API nutze ich SMTP und IMAP (alt, aber derzeit noch das Beste; die neue JMAP-Initiative ist willkommen)
    • Big-Tech-Unternehmen wie Microsoft zwingen Nutzer zur Verwendung von Office-365-Software mit AI-Copilot-Integration und haben kürzlich den SMTP-Zugriff für Office-365-Konten deaktiviert

Was man selbst hosten kann

  • Hardware

    • Ich arbeite bei einem Unternehmen namens enum.co, in einem Umfeld, das digitale Souveränität wichtig nimmt
    • Aktuell betreibe ich einen hochverfügbaren Kubernetes-Cluster aus drei Mini-Servern (mit Hilfe meines Chefs eingerichtet)

  • Kalender & Kontakte

    • Da es sich um sensible Daten handelt, hoste ich einen eigenen CalDAV/CardDAV-Server
    • Server-Optionen:
      • Radicale: auf Python-Basis, einfaches Web-UI, unterstützt nur Einzelbenutzer, nicht kompatibel mit Apple-Geräten
      • ⭐ Empfohlen: Baïkal: auf PHP-Basis, aktiv entwickelt, besseres Web-UI, Mehrbenutzer-Unterstützung
      • DAViCal: auf PHP-Basis, nicht ausprobiert
      • Xandikos: auf Python-Basis, keine eingebaute Authentifizierung, kein Web-UI
      • Nextcloud: auf PHP-Basis, okay, wenn man es ohnehin schon nutzt, aber zu schwergewichtig
    • Sich der Kalender- und Kontaktdaten bewusst zu sein, bedeutet auch zu prüfen, welche Apps darauf zugreifen dürfen

  • E-Mail

    • Ein selbst gehosteter Mailserver galt lange als Tabu, ist in Wirklichkeit aber gar nicht so schwierig
    • Neuere Lösungen wie Stalwart oder Mailcow machen es einfacher, persönliche Postfächer selbst zu hosten (nicht für Marketing-Mails)
    • Vom Hosting zu Hause wird abgeraten (man braucht eine statische IP und der Server muss aus dem gesamten Internet erreichbar sein)
    • Einrichtungsschritte:
      • Einen vertrauenswürdigen Hosting-Anbieter auswählen
      • Eine saubere IP-Adresse beschaffen (Mail-Blacklists prüfen und bei Bedarf wiederholen)
      • Den Server einrichten und prüfen, ob er E-Mails empfangen kann und alle Protokolle korrekt konfiguriert sind
      • Mit dem Online-Testtool internet.nl validieren
      • E-Mails an Google-, Microsoft- und Yahoo-Adressen senden und prüfen, ob sie als Spam eingestuft werden
      • DNS, DMARC, SPF, TLS usw. wiederholt kontrollieren
    • Ein ausführlicher Blogpost dazu ist geplant

  • Smart Home

    • Vor Jahren begann ich, eine Home-Assistant-Instanz zu hosten; damals reichte Apple HomeKit zwar aus, aber ich wollte experimentieren
    • Seitdem sind viele Smart-Home-Unternehmen pleitegegangen, haben Cloud-Dienste eingestellt, Preise erhöht oder kostenlose Angebote kostenpflichtig gemacht
    • Vor ein paar Wochen hörte ich, dass Philips Hue Nutzer zur Kontoerstellung zwingt, und da zeigte Home Assistant seinen Wert
      • Um alle Funktionen der bereits bezahlten Beleuchtung zu nutzen, ist ein Konto erforderlich
      • Ich habe immer Firewall-Regeln gesetzt, die ausgehenden Netzwerkverkehr von Smart-Home-Geräten blockieren
      • Offenbar lassen sich selbst im lokalen Netzwerk app-spezifische Philips-Hue-Funktionen wie kerzenähnliche Animationen nicht nutzen
      • Hoffentlich gibt es ein Community-Plugin, das diese Funktion emuliert
    • Für Geräte, die nur lokal genutzt werden, werde ich niemals ein Online-Konto anlegen
    • Derzeit bin ich stark mit der Verfolgung des Energieverbrauchs beschäftigt und plane, ein Raspberry-Pi-plus-Kamera-Gerät zu entwickeln, das den Gasverbrauch per Machine Vision erfasst

  • RSS-Aggregator

    • Ich abonniere viele Nachrichtenseiten und Blogs per RSS; RSS selbst ist bereits dezentral und souverän
    • Deshalb ist Self-Hosting eines RSS-Aggregators optional und eher der letzte Schritt
    • Auf iPhone und Mac nutze ich NetNewsWire
      • Der beste RSS-Reader, Open Source und von großartigen Menschen unterstützt
      • Bietet native Integration mit FreshRSS
    • FreshRSS bietet als Feed-Aggregator zusätzliche Funktionen wie Filterung
      • Man kann damit auch Quellen abonnieren, die selbst keinen RSS-Feed anbieten

  • Standort-Tracker

    • Ich habe eine dawarich-Instanz bereitgestellt (bedeutet auf Deutsch „ich war da“)
      • Ein Server zum Sammeln und Anzeigen geografischer Positionsdaten
      • Es gibt verschiedene mobile Apps, die den aktuellen Standort an den Server senden können
    • Verfügbare Apps:
      • Offizielle dawarich-App: zeigt auf iOS ständig ein Navigationssymbol in der Notch an
      • Overland: hoher Akkuverbrauch
      • ⭐ Owntracks: funktioniert auf iOS am besten, aber die App-Einstellungen sind sehr verwirrend
      • PhoneTrack

Ideen & Ausblick

  • Kürzlich habe ich mein Homelab neu aufgebaut und von einem einzelnen großen Server auf einen 3-Node-Kubernetes-Cluster umgestellt
    • Das bietet deutlich mehr Flexibilität bei den Arten von Anwendungen, die ich hosten kann
  • Liste von Apps und Tools, die ich mir ansehen möchte:
    • EteSync: Ende-zu-Ende-verschlüsseltes CalDAV & CardDAV
    • AnyType: eine eigene AnyType-Serverinstanz hosten
    • Immich oder ente: von iCloud Fotos zu Self-Hosting wechseln
    • Passbolt: Passwortmanager (Bitwarden bevorzuge ich nicht)
    • BirdNET: Vogelarten-Monitoring im Außenbereich mit Mikrofon
    • penpot: ähnlich wie Figma, aber kostenlos & Open Source
    • Habitica: Gewohnheitsmanager
    • vert: Dateikonverter
    • InvoiceShelf: Rechnungsmanager
  • selfh.st ist eine großartige Ressource, um selbst hostbare Anwendungen zu finden

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-10-11
Hacker-News-Kommentare

  • Ich möchte sagen, dass nicht nur persönliche Dienste direkt selbst gehostet werden sollten, sondern dass auch Software- oder SaaS-Kleinunternehmen darüber nachdenken sollten, direkter zu hosten.
    Cloud-Anbieter behaupten wegen Komplexität und Skalierung, dass man sie unbedingt brauche, aber in Wirklichkeit brauchen die meisten Softwareprojekte oder Unternehmen das gar nicht.
    Zum Beispiel muss man sich für ein NextJS-Deployment nicht zwingend auf Vercel oder Netlify verlassen; ein VPS mit Ubuntu, auf dem Nginx oder Caddy läuft (mein Favorit), reicht aus.
    Für weit über 90 % der Projekte reicht Self-Hosting etwa so völlig aus:

    • ein gut abgesicherter VPS mit den nötigen Sicherheitsmaßnahmen (Root-Login deaktivieren, Login per SSH-Key usw.)

    • ein Reverse-Proxy-Setup mit Caddy/Nginx zum Ausliefern statischer Dateien oder Websites; solange es nicht um Millionen Requests pro Tag geht, braucht man nicht einmal ein CDN

    • Ausführung des Backends/der API mit Supervisor oder systemd

    • derselbe Reverse Proxy kann auch das Backend und andere Dienste proxien

    • eigene MySQL-/Postgres-Datenbank betreiben und absichern

    • alle Backups per Backup-Skript/Cron erledigen und regelmäßig testen

    • für DOS/DDOS-Schutz kann man eine Cloudflare-Schicht hinzufügen
      Am Ende ergibt sich Cloudflare/DNS→Reverse Proxy (Caddy/Nginx)→App.
      Für Deployments reicht meistens schon git pull, bei Bedarf kann man zusätzlich builden.
      Docker oder Container sind ebenfalls nicht zwingend nötig; für kleine bis mittelgroße Projekte kann man gut darauf verzichten.
      Es wirkt vielleicht schwierig, ist in der Praxis aber nicht so schwer wie gedacht; die meisten Projekte brauchen kein großflächiges Webscale.

    • Was mir am meisten Sorgen macht, ist das Sicherheitsrisiko, das mit der Verwaltung des gesamten OS entsteht, inklusive Kernel und Userland.
      Ich frage mich dann, ob die Firewall korrekt konfiguriert ist, ob auf aktuelle CVEs schnell reagiert wird usw.
      Deshalb fühlt es sich für mich stabiler an, mit GitHub Actions einen Workflow aufzubauen → Container-Image zu bauen und in eine private Registry zu pushen → dieses Image per k8s-Konfiguration auf den Dienst auszurollen.
      Das ist genauso einfach wie direkt auf einer VM zu deployen, und so muss ich nur für meine App und ihre Schnittstellen Verantwortung tragen.

    • Genau deshalb habe ich canine.sh gebaut: Ich wollte den gesamten oben beschriebenen Setup-Prozess auf einen Klick reduzieren.
      Als ich früher ein kleines SaaS mitgegründet habe, lagen unsere Cloud-Kosten bei über 500.000 Dollar pro Jahr.
      Im Betrieb eines echten Produkts merkt man schnell, dass Sentry unverzichtbar ist, und statt Fehler in Serverlogs von Hand zu suchen, kostet Cloud Sentry grob 40 Dollar im Monat.
      Für Daten-Monitoring braucht man dann auch Datadog für 300 Dollar im Monat.
      Für Dashboards in Kund:innenpräsentationen kosten BI-Tools wie Looker/Tableau/Omni 20.000 Dollar im Jahr.
      Data Warehouse und Replikation kosten 150.000 Dollar im Jahr.
      Die Kosten für solche externen Dienste summieren sich immer weiter, und am Ende bin ich zu dem Schluss gekommen, dass es am besten ist, all diese externen Services auf der eigenen Infrastruktur zu betreiben und zu verwalten.
      Zum Beispiel Cloud Sentry→Self Hosted Sentry, Datadog→Prometheus/Grafana, Looker→Metabase, Snowflake→Clickhouse, ETL→Airbyte usw.
      Das ist der Grund, warum die meisten Unternehmen am Ende bei Kubernetes landen.
      Indie-Hacker verstehen vielleicht nicht, warum man die Komplexität von Kubernetes braucht, aber genau darin liegt der Grund, warum man nicht einfach alles auf einen einzelnen VPS packen kann.

    • Ich stimme der Aussage zu, dass „die meisten Projekte kein Webscale brauchen“.
      Das Marketing der großen Cloud-Plattformen wirkt heute fast so, als würde YAGNI (You Ain’t Gonna Need It) auch im Infrastruktur-Bereich Realität.
      Ich arbeite seit Anfang der 2000er als Systemadministrator, und es ist amüsant zu sehen, wie der Trend, Dienste selbst zu hosten, plötzlich wie eine Innovation behandelt wird.
      Schon vor Docker wurden Code und Dienste mit LXC, BSD Jails usw. isoliert betrieben; das ist eine lange Tradition noch aus der Zeit vor dem anderen DevOps.
      Es ist auch interessant zu beobachten, wie Entwickler so etwas heute neu entdecken.
      Zum Schluss: Es wäre gut, mit grauhaarigen Veteranen unter den Systemadministratoren zusammenzuarbeiten oder sich bei einem Kaffee von ihnen helfen zu lassen.
      Viele verwalten Infrastruktur auf die alte Art gern selbst und bringen viel praktisches Know-how mit.

    • Ein weiterer Vorteil von Self-Hosting ist, dass das nötige Systemwissen im Gegensatz zu Cloud-Services viel portabler ist.
      Wenn man einmal gelernt hat, wie systemd, ufw und ssh funktionieren, kann man das direkt auch auf anderen Systemen anwenden.
      Ich denke sogar, dass Zeit und Aufwand, die in Docker und Container-Layer-Builds samt allerlei Tricks fließen, größer sind als bei der Verwaltung eines normalen Debian-Webservers.

    • Ich stimme insgesamt zu und danke fürs Teilen der Meinung.
      Nur in einem Punkt sehe ich es anders: bei der Aussage, dass man ein CDN erst bei größerem Maßstab braucht.
      Ein CDN dient nicht nur dazu, Origin-Requests zu verteilen, sondern vor allem dazu, die Latenz in der User Experience zu senken.
      Die gefühlte Geschwindigkeit ist in Wahrheit eine der wichtigsten Funktionen überhaupt, und auch wenn man mit vorzeitiger Optimierung vorsichtig sein sollte, gehört das Ausliefern statischer Assets von einem Edge in Nutzernähe seit gut zehn Jahren zum Grundniveau.

  • Großartiges Thema, ich kann aus eigener Erfahrung eine Perspektive beitragen.
    Wenn man ein Homelab selbst betreibt, ist der größte Vorteil nicht Kostenersparnis oder Datenprivatsphäre an sich, sondern dass man dadurch wirklich tiefes praktisches Wissen erwirbt.
    Über Docker, Networking und Linux-Administration zu lesen ist etwas völlig anderes, als einen Dienst selbst für die Familie zu betreiben und dann bei ausgefallenem DNS oder einem Docker-Container, der nach einem Reboot nicht startet, alles eigenhändig zu reparieren.
    Allerdings gibt es auch eine andere Realität.
    Am Anfang ist es ein spaßiges Projekt, aber sobald man kritische Dienste wie Passwortmanager oder Dateisynchronisierung selbst hostet, wird man zum 24/7-On-Call-Verantwortlichen.
    Für Backups, Sicherheitsupdates und Verfügbarkeit ist dann alles meine Verantwortung, und ab diesem Punkt ist es nicht mehr nur ein Hobby, sondern ein „Job“.
    Letztlich bietet Self-Hosting also viel Kontrolle über die eigenen Daten und ein großes Gefühl der Erfüllung, aber der Preis von SaaS wird durch die eigene Zeit und mentale Belastung in der Rolle der IT-Verantwortlichen ersetzt.
    Für HN-Nutzer ist es den Versuch meiner Meinung nach trotzdem absolut wert.

  • Jemand schrieb, er habe das Glück, bei seiner Firma (enum.co) mit Fokus auf digitale Souveränität arbeiten zu können, aber ein Blick auf deren Mailserver über info.addr.tools zeigte MX auf smtp.google.com und viele Google-bezogene Properties in den TXT-Records.
    Das ist nicht bloß ein „Slogan“, sondern DNS-Realität.
    Digitale Souveränität zu betonen und gleichzeitig auf Googles Maildienst zu setzen, ist widersprüchlich.
    https://info.addr.tools/enum.co

    • Zur Verteidigung von enum: Ihr angebotener Service betrifft k8, S3-kompatiblen Storage und DevOps.
      Wenn sie Self-Hosting oder E-Mail-Souveränität verkaufen und dann Gmail nutzen würden, wäre das etwas völlig anderes.
      Es ist nicht vollständig 100 % unabhängig, und auch das OP erwähnt tatsächlich, dass selbstgehostete Mailserver als großes Tabu gelten, man aber nicht so viel Angst davor haben müsse, wie oft angenommen.
      Allen ist dieses Problem bewusst, und es gibt noch Dinge zu verbessern.

    • Hallo, ich bin der Gründer von enum.
      Der Hinweis ist berechtigt und ein guter Punkt.
      Ehrlich gesagt war der Einsatz von Google Workspace für unsere internen E-Mails anfangs eine pragmatische Entscheidung, damit wir uns auf die Entwicklung des Kernprodukts konzentrieren konnten.
      Das ist in Startups eine sehr übliche Entscheidung, und wir planen die Umstellung in den nächsten Wochen.
      Unsere Kundenplattform und alle Daten waren jedoch immer zu 100 % souverän.
      Unsere Infrastruktur ist vollständig unabhängig von Big Tech.
      Danke, dass du auf das Problem hingewiesen hast.

    • E-Mail betrachte ich als Ausnahme vom Self-Hosting.
      Ich hoste alle anderen Dienste selbst, aber E-Mail überlasse ich einem Drittanbieter.

    • Ich bin beeindruckt, wie konsequent hier die Google-bezogenen DNS-Einträge angesprochen wurden.
      Wirklich bemerkenswert.

    • Der TXT-Eintrag google-site-verification=... ist nicht unbedingt etwas „Böses“, sondern eher ein Kompromiss, damit Google ausgehende Mails nicht als Spam behandelt.

  • Wenn man E-Mail selbst hostet und digitale Souveränität wichtiger ist als Privatsphäre,
    nutze ich Gmail mit einer eigenen Domain und betreibe zusätzlich selbst einen eigenen Mailserver, der per mbsync weiterhin Mails von Gmail herunterlädt.
    Speicherung und Lesen erfolgen auf meinem Server, aber zum Senden verwende ich weiterhin Gmail.
    Selbst wenn Google mir den Zugriff auf mein Konto sperrt, habe ich meine E-Mails direkt bei mir, und wenn ich den Anbieter wechsle, muss ich nur DNS ändern.
    Auch mit der Zustellbarkeit gesendeter Mails gibt es dann keine Probleme.

    • Vor sechs Jahren habe ich mit Self-Hosting von E-Mail begonnen, inklusive DNS-Konfiguration für SPF, DMARC usw.
      Probleme gab es nur ein- oder zweimal; meistens waren eher andere Dinge lästig, etwa irgendwelche Dienste, zufällige Ausfälle, IP-Änderungen oder Backup-Automatisierung, nicht der Mailserver selbst.
      Im Gegenteil: Der Mailserver läuft einfach stabil vor sich hin.

    • Wenn man fragt, warum du nicht auch das Versenden von E-Mails selbst hostest,
      liegt das vermutlich an Zustellbarkeitsproblemen?

    • Vollständige E-Mail-Souveränität hängt von einer eigenen Domain ab.
      Wenn man die sauber absichert, kann man jederzeit zwischen mehreren Anbietern wählen und bleibt beim Wechsel flexibel.

  • Self-Hosting ist wirklich großartig.
    Seit ich vor einem Jahr vom Software Engineer zum SaaS-Gründer geworden bin, hoste ich mit Coolify und einem 20-Dollar-Server von Hetzner selbst Postgres, eine alte Minio-Version, Nuxt, NextJs, Umami Analytics, Open WebUI, statische Sites und mehr.
    Anfangs musste ich erst lernen, aber nachdem das Setup einmal stand, wurde das Starten neuer Services fast zu Plug-and-Play.
    Ich nutze nicht einmal ein Viertel der Server-Ressourcen aus (weil ich so wenige Nutzer habe, haha).
    https://coolify.io/docs/

  • Ich arbeite als IT-Profi, habe Self-Hosting oder den Aufbau eines NAS zu Hause aber lange aufgeschoben und mir dann am Ende direkt ein Ugreen-NAS mit 4 Bays gekauft und sofort TrueNAS CE installiert.
    Ich habe ChatGPT sogar meinen eigenen Kontext wie meine docker-compose-Dateien gegeben und damit das Setup umgesetzt.
    Abgesehen von etwas Erfahrung mit Docker und Networking aus meiner Studienzeit hatte ich vorher fast kein Wissen darüber.
    Aktuell betreibe ich Folgendes:

    • mehrere Dockerized Apps
    • ein separates Netzwerk für jeden App-Stack
    • Steuerung der Veröffentlichung von Web-UIs über Traefik + Docker-Labels
    • nur Port 443 von Traefik nach außen geöffnet, Port-Forwarding nur bei Bedarf
    • optionale Cloudflare-Tunnel
    • automatische TLS-Terminierung für die Domain durch Traefik (LAN/WAN gleichermaßen)
    • Split-DNS für LAN/WAN
    • CrowdSec auf allen exponierten Containern
    • MFA für exponierte Dienste über Cloudflare
    • lokales DHCP/DNS mit Technitium
    • automatische ZFS-Snapshots/Remote-Backups
    • Trennung von flüchtigen Daten wie DBs und Logs auf SSDs und großen Dateien auf HDDs

  • Self-Hosting ist gut, aber das Problem sind Backups und Upgrades.
    Ich hoste verschiedenste Ressourcen selbst, aber keine wichtigen Daten und nichts, worauf sich andere verlassen müssen.
    Wenn Wiederherstellung oder Upgrade einer App nicht einfach sind, versuche ich, nicht davon abhängig zu werden.
    Tatsächlich gibt es unter selbstgehosteten Apps nur wenige, bei denen Backup/Wiederherstellung in ein oder zwei Zeilen erledigt sind.
    Übrigens sind Tailscale und Pangolin beim sicheren Self-Hosting zu Hause ein Geschenk des Himmels.

    • Mich würde interessieren, was für eine Backup-Lösung du erwartest.
      Alle meine selbstgehosteten Apps laufen in Docker, also muss ich nur die Container-Volume-Ordner und die docker-compose.yml sichern.
      Für die Wiederherstellung kopiere ich die Ordner zurück und führe docker compose up aus, fertig.
      Ich finde nicht, dass jede App eine eigene Backup-Implementierung braucht; das ist nur verschwendete Entwicklerzeit.

    • Ich würde statt Tailscale stark zu selbstgehostetem netbird raten.
      Es wird sehr aktiv entwickelt und hat eine hervorragende UI.
      https://github.com/netbirdio/netbird

    • Was ist Pangolin?
      Wenn ich danach suche, finde ich nur das Tier.

  • Mein Self-Hosting-Stack:

    1. immich
    2. jellyfin
    3. ghost
    4. wallabag
    5. freshrss
    6. vaultwarden
    7. nextcloud
    8. overleaf/sharelatex
    9. Matrix-Server
    10. pds für atproto
    • Mich würde interessieren, wie du Upgrades machst, wie Sicherheitsupdates eingespielt werden, wie Backups funktionieren und ob du das wirklich regelmäßig testest.
      Hinweise auf neue Versionen oder Security Patches sind oft dürftig, und manchmal muss man sogar jede einzelne Version nacheinander durchgehen.

  • Wenn man „Self-Hosting“ zu sehr auf Heimserver beschränkt, wird es zwangsläufig immer eine Nische bleiben.
    Man sollte jede nicht-SaaS-Variante fördern: Open-Source-Apps ohne Abo, klassische Windows-PC-Anwendungen, leicht migrierbare Cloud-Apps usw.
    Egal in welcher Form, das eigentliche Ziel von Self-Hosting ist es, Lock-in zu vermeiden und den Nutzern Kontrolle zurückzugeben.

    • Trotzdem sollte die Bedeutung des Begriffs nicht verwässert werden.
      Selbst wenn eine Cloud-App dank Standardprotokollen portabel ist, kann der Betreiber Datenrichtlinien und Erfassungspraktiken jederzeit nach eigenem Gutdünken ändern, solange der Server nicht in meinem Besitz oder unter meiner Kontrolle steht.
      Man kann nie sicher sein, ob Daten unerwartet gesammelt werden oder ob vor einer Einstellung des Dienstes eine Migration überhaupt möglich ist.

    • Auch installierbare Windows-Software kann in die Kategorie Self-Hosting fallen.
      In der Praxis fängt man manchmal eben mit einer Windows-EXE oder Docker an und entwickelt sich von dort aus weiter.

    • Zumindest würde ich sagen, dass auch ein Server in einem fremden Rechenzentrum (Colocation usw.), auf dem man selbst Root-Rechte hat, unter Self-Hosting fällt.

  • Vor 20 Jahren konnten sogar Großväter auf limewire.com eine setup.exe herunterladen, einfach auf Weiter → Weiter → Weiter klicken und einen perfekten Fileserver plus Client installieren.
    2007 lief LimeWire auf einem Drittel aller Computer weltweit.
    Heute hingegen ist selbst ganz grundlegende Self-Hosting-Software praktisch nur noch von professionellen Engineers installierbar.
    Man muss SSH und Docker benutzen, Tailscale, TLS-Zertifikate und all diese komplexe Verwaltung verstehen, dazu Backups und zahllose weitere Automatisierungen …
    Ich frage mich, warum es so wenig „Self-Hosting“-Software gibt, bei der apt-get install reicht und man fertig ist.
    Darum hostet am Ende niemand selbst.
    https://en.wikipedia.org/wiki/LimeWire

    • Manche Software lässt sich tatsächlich mit apt-get install vollständig installieren, aber sobald man einen Dienst im Internet verfügbar machen will, muss man schon mit Domainnamen und HTTPS anfangen.
      Clients wie Limewire oder BitTorrent konnten ohne Domain auskommen, weil zentrale Server wie Tracker dahinterstanden.

    • Viele Leute würden einen Installer wie Limewire wahrscheinlich nicht als Self-Hosting bezeichnen.
      Das ist eher einfach die Installation eines lokalen Programms.

    • Auf Ubuntu wollte man serverseitige Apps per snap leicht installierbar machen, aber die Community hat so stark dagegen reagiert, dass es gescheitert ist.
      snap hat zwar Nachteile, war aber ein Format, das die Bereitstellung von Server-Apps vereinfachen sollte.
      Zum Beispiel kann man Nextcloud bis heute per snap installieren.
      Weil es nicht perfekt war, hat man damit sogar ein praktisch „gutes genug“ verworfen.

    • Limewire war nur ein Client, kein Server.
      Wenn man wirklich ordentlich hochladen wollte, musste man Firewall und Port-Forwarding konfigurieren und oft auch UPnP zulassen (nicht empfehlenswert).
      Selbstgehostete Server sind eine ganz andere Kategorie.
      In einer Welt, in der Anfänger vieles automatisch hätten machen können, haben bösartige Hacker den Schwierigkeitsgrad für Setup und Betrieb stark erhöht.
      Selbst Experten sind gegenüber professionellen Penetrationstestern oder staatlichen Angreifern nicht wirklich geschützt.

    • Ich denke, moderne Softwareentwicklung ist insgesamt zu komplex geworden.
      Es erinnert an eine Bürokratie, die künstlich unnötige Probleme erzeugt, um sich selbst zu erhalten.
      Die meisten Menschen brauchen gar kein Self-Hosting; es würde reichen, Dinge einfach lokal auf dem Computer laufen zu lassen und gelegentlich aus dem lokalen Netzwerk darauf zuzugreifen.
      Stattdessen fehlt ein Geschäftsmodell, und Entwickler sind besessen von speziellen Layern und unnötig komplexen Architekturen.
      Das Ergebnis sind Server-Software, WebView-basierte Lösungen, eine Entkopplung von Daten und lokaler Umgebung und immer mehr Geräte, die verwaltet werden müssen.
      Die meisten Computer stehen untätig herum, während sich nur die Administrationsschichten weiter stapeln.
      Auch der Trend bei Laptops ist meiner Meinung nach Teil dieses Chaos.
      Gute lokale Mac-Apps verschwinden, und übrig bleiben Cloud-Abos.
      Selbst Open Source kommt am Ende mit Docker-Images, komplizierten Konfigurationen und Bergen von Gotchas daher.
      Wenn einfache Installation und Verwaltung möglich wären, würde man dafür sogar bezahlen,
      aber so weiß man nie, wie viel Zeit es verschlingen wird, und deshalb überlassen am Ende alle alles einfach Big Tech.
      Web-Technologien sind zwar gut für interaktive Dokumente, aber außerhalb dieses Einsatzzwecks gibt es nach wie vor große Schwierigkeiten bei der Nutzbarkeit.