Ein Tag, ein Server, kaum noch Big Tech
Am 1. November hab ich fast alles, was ich täglich nutze, auf meinen eigenen Server geholt. Mit allen Pannen: vom Selbst-Bann bis zur Software, die wieder rausflog.
Ich hab mir am 1. November eine Spezi gemacht und gedacht: Heute räum ich mal auf. Ein Tag später läuft fast alles, was ich jeden Tag benutze, auf meinem eigenen Server. Passwörter, Dateien, Kalender, Dokumente, Fotos, VPN, Statistik, sogar dieser Blog. Hier ist, was passiert ist. Und zwar alles, auch die Sachen, die schiefgegangen sind. Davon gab es einige.
Warum überhaupt?
Ich sag meiner Kundschaft ständig, dass ihre Daten bei ihnen bleiben sollten. Ehrlicherweise lagen meine eigenen aber verteilt bei fünf, sechs großen Firmen. Das passt nicht zusammen. Außerdem macht mir sowas einfach Spaß.
YouTube benutz ich übrigens weiter ganz normal. Man muss nicht alles auf einmal machen.
Der Server ist ein VPS bei Datalix in Frankfurt. Darauf läuft alles in Docker-Containern, davor ein Reverse Proxy, der die Zertifikate macht.
Schritt 1: Raus aus AWS
Ein Teil meiner Dienste lief noch auf einem AWS-Server: Benachrichtigungen, ein Dashboard, ein paar Discord-Bots, mein Portfolio. Die sind jetzt alle auf meinem eigenen Server, jeder in seinem eigenen Container, verwaltet über Pelican. Das ist eigentlich ein Panel für Gameserver, aber es ist perfekt für kleine Bots und Node-Apps: Neustarten, Logs lesen, Dateien ändern, alles in einer Oberfläche.
Ein Dienst bleibt vorerst auf AWS, der Rest ist dort aus.
Was schiefging: Pelican läuft auf dem "richtigen" Docker mit Root-Rechten, mein Benutzer-Docker ist ein anderer. Dateien einfach rüberkopieren ging deshalb nicht, alles musste über die Dateischnittstelle von Pelican. Und weil ein paar alte Dienste ihre Ziele fest auf localhost eingetragen hatten, hängt jetzt ein kleiner Weiterleiter dazwischen, der die alten Ports auf die neuen umbiegt. Nicht schön, aber es läuft.
Schritt 2: Wissen, wenn was kaputt geht
Wenn alles auf einem Server läuft, muss ich wissen, wenn dort was schiefgeht. Also hab ich mir einen kleinen Wächter geschrieben. Der schaut sich Container, CPU, RAM, Platte, Zertifikate und die Erreichbarkeit aller Seiten an und schickt mir bei Problemen eine Push-Nachricht aufs Handy. Über ntfy, natürlich auch selbst gehostet. Dazu gibt es ein Dashboard für mich (mit Passwort und zweitem Faktor) und eine öffentliche Statusseite.

Was schiefging: Erstens hat Google die Statusseite anfangs nicht gefunden. Mein Bot-Schutz Anubis hat eine eigene robots.txt ausgeliefert, und die sagte am Ende einfach: alle draußen bleiben. Zweitens: Beim ersten großen Update hat mein Handy im Minutentakt vibriert, weil der Wächter jeden Neustart als Ausfall gemeldet hat. Seitdem gibt es einen Wartungsmodus. Der stellt sich nach einer Weile von selbst wieder ab, damit ich nicht aus Versehen tagelang blind bin.

Und drittens, weil es so schön ist: Als ich für diesen Beitrag einen Screenshot der Statusseite machen wollte, hat mein eigener Bot-Schutz meinen Screenshot-Bot rausgeworfen.

Schritt 3: Ein Honigtopf für Bots
Jeder Server im Internet wird ständig von Bots abgeklopft, die nach vergessenen Passwortdateien und Admin-Logins suchen. Statt die nur zu blocken, bekommen sie bei mir jetzt etwas zu tun: falsche Dateien, die sehr, sehr langsam laden, und eine Login-Seite, die nirgendwo hinführt. Wer reintappt, landet in meiner Statistik und ich bekomm eine Nachricht. Mehr verrat ich dazu nicht, sonst ist der Spaß weg.
Zwischendurch: Ich hab mich selbst gebannt
Auf dem Server läuft CrowdSec. Das erkennt verdächtiges Verhalten und sperrt die IP. Verdächtiges Verhalten war in dem Fall: ich. Ich hab so schnell durch meine eigenen Seiten geklickt, dass CrowdSec mich für einen Crawler gehalten hat. Vier Stunden Sperre, auf allen Ports. Für mich sah das erstmal aus wie "SSH ist kaputt". Die Verbindung, die schon offen war, lief auch nichtmehr, somit musste ich mich mit einer Fallback Shell entsperren.
Gelernt: Wer eine wechselnde IP vom Kabelanbieter hat, sollte den ganzen Adressbereich des Anbieters auf die Ausnahmeliste setzen und nicht nur eine einzelne IP. Die ist morgen sowieso eine andere.
Schritt 4: Mein eigenes "Proton"
Das Herzstück. Ich wollte das, was Proton oder Google als Paket anbieten, nur eben bei mir.
- Passwörter: Vaultwarden. Funktioniert mit den normalen Bitwarden-Apps.
- Dateien: Seafile. Schnell, mit Sync-Client für alles.
- Kalender und Kontakte: Baïkal.
- VPN: wg-easy, also WireGuard mit Weboberfläche.
- Dokumente: CryptPad. Ende-zu-Ende verschlüsselt, ich selbst kann nicht reinschauen.
- Papierkram: Paperless-ngx, dazu Paperless-AI, das Dokumente automatisch sortiert. Mein Lieblingsteil: Hat eine Rechnung einen Betrag und ein Fälligkeitsdatum, landet sie automatisch als Termin in meinem Kalender. Tagge ich sie als bezahlt, verschwindet der Termin wieder.
- PDFs: Stirling PDF. Zusammenfügen, schwärzen, umwandeln, ohne die Datei irgendwo hochzuladen.
- Lesezeichen: Linkwarden. Speichert nicht nur den Link, sondern auch eine Kopie der Seite.
Fotos liegen schon länger in Immich, und gesucht wird über SearXNG.
Ganz oben im Beitrag siehst du einmal alle Türen: Vaultwarden, Seafile, Paperless, CryptPad, Stirling PDF, Linkwarden, Immich und mein Pelican-Panel.
Was schiefging, und zwar einiges:
- Radicale war zu langsam. Als Kalender hatte ich erst Radicale. Mein Hauptkalender hat über 800 Termine, und mein Handy fragt beim Synchronisieren alles gleichzeitig ab. Das hat Radicale nicht gepackt. Also alles exportiert und auf Baïkal umgezogen, das macht das locker.
- Seafile wollte nicht starten. Seafile liest das Datenbank-Passwort an zwei verschiedenen Stellen, und beide müssen übereinstimmen. Beim ersten Start taten sie das nicht, die Einrichtung ist abgebrochen und ich hab den Datenbank-Benutzer am Ende von Hand angelegt.
- Ein falscher Haken hat alle Seiten gekillt. Im Proxy hab ich bei einer Seite eine Einstellung für Websockets doppelt gesetzt. Das Ergebnis: Die Konfiguration war ungültig, und zwar nicht nur für diese Seite, sondern für jede, die danach gespeichert wurde.
- CryptPad hat seinen Port geändert. Jede Anleitung im Netz sagt, die Live-Verbindung läuft über einen eigenen Port. In der aktuellen Version stimmt das nicht mehr. Hat eine Weile gedauert, bis ich das gemerkt hab.
Schritt 5: Alles aktualisieren
Am Ende vom Tag hab ich einmal den ganzen Stack durchgezogen. Rund 50 Container geprüft, die meisten waren schon aktuell, eine ganze Reihe hatte Updates.

Was schiefging: Baïkal. Das fertige Docker-Image gibt es nur bis Version 0.10.1, aktuell ist 0.13.0. Also hab ich mir das Image selbst gebaut. Erster Versuch: Fehler 500 auf allen Seiten, weil die neue Version mindestens PHP 8.2 braucht und das Basis-Image noch 8.1 hatte. Zweiter Versuch mit dem richtigen Basis-Image, dann noch den Upgrade-Assistenten für die Datenbank durchklicken, und alle vier Kalender waren wieder da. Ein Backup hatte ich vorher gemacht. Zum Glück unnötig.

Und eine Sache hab ich bewusst nicht angefasst: die Suchmaschine Meilisearch. Das Update dort will die gespeicherten Daten umbauen, und das mach ich nicht nachts um zwei ohne Plan.
Schritt 6: Neu dazu
- Umami statt Google Analytics. Ich seh, welche Seiten gelesen werden, aber ohne Cookies und ohne dich wiederzuerkennen. Die Daten liegen auf meinem Server und nirgendwo sonst. Auf meiner Website läuft das Skript sogar über meine eigene Domain, damit die Seite weiterhin nichts von fremden Servern nachlädt.
- Memos statt Google Keep, für schnelle Notizen vom Handy.
- Ghost für diesen Blog. Das Design hab ich an meine Website angepasst, damit sich beides wie ein Ort anfühlt.



Was schiefging:
- Falscher Name. Ich hab für Memos einen Image-Namen benutzt, den es gar nicht gibt. Und als es lief, hatte Memos seine alte Schnittstelle inzwischen abgeschafft.
- Ghost und das Theme. Ghost benennt ein hochgeladenes Theme nach dem Dateinamen der Zip-Datei, nicht nach dem Namen, der im Theme steht. Aktivieren ging deshalb erst im zweiten Anlauf.

Schritt 7: OpnForm. Und wieder weg
Eigentlich sollte noch OpnForm als Ersatz für Google Forms dazukommen, und mein Kontaktformular sollte darüber laufen. Hab ich gebaut, im Design meiner Website eingefärbt, und es lief auch. Aber: Der Dunkelmodus ist nur halb fertig, die Hälfte der Seite bleibt weiß. Eigene Schriften lassen sich nur mit Gewalt einbauen. Und dann hab ich im Log gesehen, dass es bei jedem abgeschickten Formular Telemetrie an die Entwickler schickt. Die lässt sich abschalten, aber das ist nicht das, was ich von einer Software will, die ich mir extra selbst hinstelle.

Also flog es wieder raus. Mein Kontaktformular speichert Anfragen jetzt direkt in Paperless, wo sowieso schon mein ganzer Papierkram liegt, und ich bekomm eine kurze Nachricht. Der Zugang, den die Website dafür hat, darf übrigens nur Dokumente hinzufügen. Lesen kann er nichts.
Was dabei auch noch schiefging: Die allererste Test-Anfrage ist in Paperless einfach stecken geblieben. "Wird verarbeitet", minutenlang, ohne Fehler. Neustart, zweiter Versuch, sofort durch. Warum, weiß ich bis jetzt nicht.
Und noch einer für die Sammlung: In der Datenschutzerklärung stand zuerst der falsche Hoster. Ist korrigiert.
Was noch fehlt
Ehrlich gesagt: Backups. Gerade liegt alles auf einem Server. Wenn der abraucht, ist alles weg. Das ist der nächste Schritt, sobald ich einen zweiten Ort dafür habe, und bis dahin ist das das größte Risiko an der ganzen Sache. Und Mail bleibt erstmal, wo sie ist. Eigene Mailserver sind ein Kampf gegen Spamfilter, den ich gerade nicht führen will.
Fazit
Anderthalb Tage Arbeit, ein paar Fehler mehr als geplant, und ich bin bei den Diensten, die ich wirklich jeden Tag nutze, kaum noch auf große Firmen angewiesen. Das meiste davon lässt sich genauso für einen kleinen Laden, eine Praxis oder einen Verein aufsetzen. Und die Fehler oben hab ich jetzt schon gemacht, die musst du nicht mehr machen. Wenn du sowas auch willst, schreib mir.