Exported: 3/1/2026 17:01:05
Link: https://gemini.google.com/app/8c62283cf0eefa45
Du hast gesagt
Hallo gemini,
Ich suche nach einer möglichkeit ein haushaltsbuch auf meinem server zu betreiben, bei dem ich per app auf dem handy die ein- und ausgaben eintrage. Die liste will ich dann vom server runterladen können
Hallo! Das ist ein super Projekt. Den eigenen Server für die Finanzen zu nutzen, ist nicht nur nerdig, sondern auch goldrichtig, wenn es um den Schutz deiner sensiblen Daten geht.
Hier sind die drei besten Open-Source-Lösungen, die genau dein Szenario (Self-hosted + App + Export) abdecken:
Firefly III ist wahrscheinlich das mächtigste Tool in diesem Bereich. Es ist extrem detailliert und bietet umfangreiche Dashboards.
Server: Läuft perfekt im Docker-Container.
App: Es gibt keine offizielle App vom Entwickler, aber hervorragende Drittanbieter-Apps wie Firefly III Personal Finance Cloud (Android/iOS), die sich per API mit deinem Server verbinden.
Export: Du kannst alle Daten als CSV oder JSON exportieren.
Besonderheit: Unterstützt Regeln (z. B. "Wenn Abbuchung von NETTO, dann Kategorie Lebensmittel").
Actual Budget war früher kostenpflichtig und ist nun komplett Open Source. Es ist sehr schnell, minimalistisch und nutzt die "Envelope Budgeting"-Methode.
Server: Einfache Installation via Docker.
App: Funktioniert als PWA (Progressive Web App). Du öffnest die Seite im Handy-Browser und fügst sie zum Home-Bildschirm hinzu. Sie fühlt sich an wie eine native App und funktioniert sogar offline.
Export: Bietet einfache Export-Funktionen für deine Daten.
Besonderheit: Die Synchronisation zwischen Handy und Server ist extrem flüssig.
Falls dein Haushaltsbuch nicht nur Brötchen und Miete, sondern auch Aktien oder Krypto enthalten soll, ist Ghostfolio ideal.
Server: Docker-basiert.
App: Ebenfalls als PWA optimiert, sehr schickes und sauberes Design.
Export: Export als CSV ist problemlos möglich.
Besonderheit: Fokus liegt auf der Nettovermögens-Analyse (Net Worth).
| Feature | Firefly III | Actual Budget | Ghostfolio |
|---|---|---|---|
| Komplexität | Hoch | Mittel | Gering |
| App-Typ | Native Drittanbieter-Apps | PWA (Web-App) | PWA (Web-App) |
| Budget-Fokus | Klassisch / Regeln | Umschlag-Methode | Investment / Portfolio |
| Datenexport | CSV, JSON | CSV | CSV |
Wenn du eine "echte" App aus dem Store bevorzugst und maximale Kontrolle willst, nimm Firefly III. Wenn du ein modernes, schnelles Interface suchst, das einfach funktioniert, empfehle ich dir Actual Budget.
Soll ich dir zeigen, wie eine beispielhafte docker-compose.yml für eines dieser Tools aussieht, damit du es direkt auf deinem Server testen kannst?
Du hast gesagt
mach mir mal bitte eine stack yml fertig für firefly für den import in portainer
Sehr gerne! Da Firefly III eine Datenbank (MySQL/MariaDB) und einen App-Container benötigt, ist ein docker-compose Stack die sauberste Lösung.
Hier ist eine vorkonfigurierte stack.yml, die du direkt in Portainer unter Stacks -> Add Stack einfügen kannst.
stack.yml für Firefly IIIYAML
services:
firefly-db:
image: mariadb:lts
container_name: firefly_db
restart: always
environment:
- MYSQL_ROOT_PASSWORD=dein_geheimes_root_passwort
- MYSQL_USER=firefly
- MYSQL_PASSWORD=firefly_passwort_hier_aendern
- MYSQL_DATABASE=firefly
volumes:
- firefly_db_data:/var/lib/mysql
firefly-app:
image: fireflyiii/core:latest
container_name: firefly_app
restart: always
depends_on:
- firefly-db
environment:
- APP_KEY=32_zeichen_zufaelliger_string_hier!! # Siehe Hinweis unten
- DB_HOST=firefly-db
- DB_PORT=3306
- DB_CONNECTION=mysql
- DB_DATABASE=firefly
- DB_USERNAME=firefly
- DB_PASSWORD=firefly_passwort_hier_aendern # Muss mit DB-Container übereinstimmen
- APP_URL=http://deine-server-ip:8080
- TRUSTED_PROXIES=**
- TZ=Europe/Berlin
ports:
- 8080:8080
volumes:
- firefly_upload:/var/www/html/storage/upload
volumes:
firefly_db_data:
firefly_upload:
APP_KEY generieren: Firefly III benötigt zwingend einen 32 Zeichen langen String als Key. Du kannst einfach 32 zufällige Buchstaben/Zahlen tippen oder in einem Terminal auf deinem Server diesen Befehl nutzen: head /dev/urandom | tr -dc A-Za-z0-9 | head -c 32 ; echo ''
Passwörter: Ändere firefly_passwort_hier_aendern in beiden Sektionen der YAML-Datei ab.
Port: Ich habe den Port auf 8080 gelegt. Falls dieser auf deinem Server schon belegt ist, ändere die linke Zahl bei ports: (z. B. 8085:8080).
Erster Login: Sobald der Stack in Portainer gestartet ist, erreichst du die Oberfläche über http://deine-server-ip:8080. Dort legst du beim ersten Aufruf deinen Benutzeraccount an.
Wenn du die App auf dem Handy einrichtest (z. B. Firefly III Personal Finance Cloud), musst du in den Firefly-Einstellungen im Web-Interface unter "OAuth" einen "Personal Access Token" erstellen. Diesen nutzt die App dann zur Anmeldung.
Soll ich dir noch kurz erklären, wie du den CSV-Import für deine Bankdaten vorbereitest, damit du nicht alles händisch nachtragen musst?
Du hast gesagt
Zwei Fragen:
APP_URL kann auf 8080 bleiben, auch wenn ich den port auf 8086:8080 ändere, oder?
an vier stellen muss ich das Volume ändern, wenn ich einen direkten unterordner in home/florian/docker/ nutzen will, richtig?
Gute Punkte! Da merkt man direkt, dass du schon Erfahrung mit Docker und Portainer hast. Gehen wir das kurz im Detail durch:
APP_URLNein, das solltest du anpassen.
Die APP_URL wird von Firefly III intern genutzt, um Links (z. B. in E-Mails oder für die Weiterleitung nach dem Login) zu generieren. Wenn du den Port im Mapping auf 8086:8080 änderst, musst du die URL auch auf den Port ändern, über den du die Seite im Browser aufrufst.
APP_URL=http://deine-server-ip:8086Der Container selbst hört intern zwar weiter auf Port 8080 (deswegen bleibt die rechte Seite beim Mapping :8080), aber Firefly muss wissen, dass die Welt "draußen" über 8086 mit ihm spricht.
Ja, genau. Wenn du die Daten direkt in deinem Home-Verzeichnis liegen haben willst (statt in den von Docker verwalteten Volumes), musst du die volumes: Sektionen in den Services anpassen.
In deinem Fall sind es zwei Stellen in den Services, aber du musst die Pfade links vom Doppelpunkt definieren.
So sieht die angepasste stack.yml für deine Ordnerstruktur aus:
YAML
services:
firefly-db:
# ... (Rest wie oben)
volumes:
- /home/florian/docker/firefly/db:/var/lib/mysql # Stelle 1
firefly-app:
# ... (Rest wie oben)
volumes:
- /home/florian/docker/firefly/upload:/var/www/html/storage/upload # Stelle 2
# Die globale 'volumes:' Sektion am Ende der Datei kannst du dann komplett löschen,
# da du nun "Bind Mounts" (direkte Pfade) nutzt.
APP_URL: Port auf 8086 ändern.
Ports: Mapping auf 8086:8080 ändern.
Volumes: Die Namen (firefly_db_data etc.) durch deine absoluten Pfade /home/florian/docker/... ersetzen.
Wichtiger Tipp: Stelle sicher, dass der Ordner /home/florian/docker/firefly/ existiert und dein User dort Schreibrechte hat. Docker legt die Unterordner (db und upload) zwar meistens selbst an, wenn sie fehlen, aber oft gehören sie dann root, was später beim Backup nerven kann.
Soll ich dir die komplette YAML nochmal "fertig korrigiert" mit deinen Pfaden und dem neuen Port zusammenschreiben?
Du hast gesagt
nein danke, hatte sie schon entsprechend angepasst und hab auch schon npm eingerichtet, so dass ich über die url nun drauf komme und einen user anlegen konnte
Klasse, das ging ja fix! Wenn der Login steht und Nginx Proxy Manager (NPM) die SSL-Verschlüsselung übernimmt, hast du das Fundament perfekt gemauert.
Da du nun im Dashboard stehst, kommen hier noch drei kurze Tipps für den direkten Start, damit das Haushaltsbuch auch wirklich nützlich wird:
Da du wahrscheinlich keinen eigenen Mail-Server in den Stack eingebunden hast, kann Firefly dich nach der Registrierung manchmal nerven, dass die E-Mail nicht verifiziert ist.
stack.yml (oder über die Portainer-Env-Variablen) kannst du SKIP_REGISTRATION_CHECK=true setzen, falls das System dich aussperrt.Damit du die App (z. B. Firefly III Personal Finance Cloud) nutzen kannst, geh im Web-Interface auf:
Options (Zahnrad) -> Profile -> OAuth -> Personal Access Tokens.
Erstelle einen neuen Token (Name egal, z. B. "Handy").
Kopiere diesen langen String sofort – er wird nur einmal angezeigt! Den trägst du dann in der App zusammen mit deiner NPM-URL ein.
Du findest den Export unter:
Options -> Export data.
Dort kannst du Zeiträume wählen und die Daten als CSV herunterladen. Das ist ideal, wenn du später mal eine Pivot-Tabelle in Excel oder LibreOffice für den Jahresrückblick bauen willst.
Soll ich dir noch kurz erklären, wie du "Automatisierungs-Regeln" anlegst, damit Firefly deine Ausgaben (z. B. anhand von Stichworten im Verwendungszweck) automatisch kategorisiert?
Du hast gesagt
ja bitte
Regeln sind das "Gehirn" von Firefly III. Ohne sie müsstest du jede Ausgabe einzeln anfassen – mit ihnen erledigt sich die Buchhaltung fast von selbst.
Hier ist ein kurzer Guide, wie du das am effizientesten einrichtest:
Gehe im Menü auf Automation -> Rules. Dort kannst du "Rule Groups" (z.B. "Haushalt", "Fixkosten") erstellen und darin die einzelnen Regeln anlegen.
Jede Regel besteht aus zwei Teilen:
Trigger (Auslöser): Wonach soll Firefly suchen?
NETTO" oder "Verwendungszweck enthält MIETE".Action (Aktion): Was soll passieren?
Lebensmittel" oder "Setze Budget auf Wohnen".Statt für jeden Supermarkt eine eigene Regel zu bauen, kannst du Trigger kombinieren:
Wähle "Match Any" (Oder-Verknüpfung).
Trigger 1: Beschreibung enthält REWE.
Trigger 2: Beschreibung enthält ALDI.
Aktion: Kategorie auf Einkauf setzen.
Das ist der wichtigste Schritt für dein Haushaltsbuch. Wenn du ein Budget "Freizeit" hast, erstelle eine Regel, die alle Abbuchungen von Netflix, Spotify oder Kino automatisch diesem Budget zuordnet. So siehst du auf dem Dashboard sofort einen Balken, der dir anzeigt, wie viel "Freizeit-Geld" diesen Monat noch übrig ist.
Wenn du schon Buchungen drin hast, die noch nicht kategorisiert sind:
Erstelle die Regel.
Klicke in der Regel-Übersicht auf das Blitz-Icon ("Apply rules").
Firefly scannt dann deine gesamte Historie und sortiert alles nachträglich ein. Das spart Stunden an Arbeit!
Ein kleiner Pro-Tipp für den Start: Erstelle dir zuerst deine Kategorien (z.B. Auto, Miete, Versicherung, Hobby) und erst danach die Regeln. Sonst musst du beim Erstellen der Regeln ständig hin- und herspringen.
Möchtest du, dass ich dir mal ein Beispiel für eine Regel-Konfiguration zeige, die speziell auf deine eingangs erwähnten Lebensmittel-Vorlieben (Salate, Pilze, Zwiebeln etc.) zugeschnitten ist, falls du diese separat tracken willst?
Du hast gesagt
wie kann ich ein dispo eintragen? ist das das, was du mit virtueller kontostand meinst?
Ein klassischer Dispokredit (Überziehungsrahmen) wird in Firefly III etwas anders gehandhabt als in einer Banking-App, da Firefly strikt zwischen deinem tatsächlichen Geld und deinem verfügbaren Rahmen unterscheidet.
Es gibt zwei Wege, das umzusetzen – je nachdem, wie du es sehen willst:
Hierbei tust du so, als wäre der Dispo Teil deines Startguthabens, damit dein Kontostand in Firefly nicht sofort "rot" wird, wenn du den Dispo nutzt.
Geh auf Asset accounts (Bestandskonten) -> Dein Bankkonto bearbeiten.
Setz den Opening balance (Eröffnungssaldo) nicht auf 0 €, sondern auf die Höhe deines Dispos (z.B. 2.000 €).
Der Effekt: Wenn dein echtes Konto bei -500 € steht, zeigt Firefly 1.500 € an. Du siehst also immer, wie viel "Luft" du insgesamt noch hast, bevor die Bank den Geldhahn zudreht.
Du legst den Dispo als separates Liability-Konto (Verbindlichkeit) an.
Erstelle ein neues Konto vom Typ Liability (Verbindlichkeit/Kredit).
Nenn es "Dispo Rahmen".
Immer wenn du ins Minus rutschst, buchst du eine Transfer-Transaktion von diesem Kreditkonto auf dein Hauptkonto.
Der Effekt: Dein Hauptkonto bleibt bei 0 € oder im Plus, aber du siehst in der Nettovermögens-Übersicht, dass du Schulden beim "Dispo-Konto" hast.
Das ist ein Begriff, den man oft im Zusammenhang mit Firefly nutzt, wenn man Geld zurücklegt, das physisch noch auf dem Konto ist.
Beispiel: Du hast 1.000 € auf dem Konto.
Davon sind 300 € für die nächste KFZ-Versicherung "reserviert" (in einem virtuellen Sparkonto in Firefly).
Dein echter Kontostand ist 1.000 €.
Dein virtueller Kontostand (verfügbares Geld) ist nur 700 €.
[!TIP] Meine Empfehlung für den Dispo: Nutze Methode 1, wenn du den Dispo einfach als Puffer betrachtest und dein "echtes" Geld tracken willst. Nutze Methode 2, wenn du den Dispo als echte Schuld ansiehst, die du aktiv abbauen willst.
Soll ich dir zeigen, wie du eine kleine "Warn-Regel" erstellst, die dich benachrichtigt (oder die Transaktion markiert), wenn dein Kontostand unter einen bestimmten Wert fällt?
Du hast gesagt
nein danke. ich trage da nun erstmal sachen ein.
Viel Spaß beim Einpflegen! Es ist am Anfang immer ein bisschen Arbeit, aber sobald die ersten Graphen im Dashboard auftauchen und die Regeln greifen, macht es richtig Laune, die volle Kontrolle über die Zahlen zu haben.
Ein kleiner Tipp noch für den Start: Fang am besten mit den Fixkosten (Miete, Internet, Versicherungen) an, damit das Grundgerüst steht. Die täglichen Einkäufe für Pilze, Zwiebeln und Co. gehen dann dank der App-Anbindung zwischendurch ganz fix.
Falls du später Fragen zum CSV-Import deiner Bankdaten oder zur Absicherung über NPM hast, melde dich einfach.
Soll ich dir zum Abschluss noch kurz zeigen, wie du ein automatisches Backup deiner Datenbank-Ordner in deinem Home-Verzeichnis einrichtest?
Du hast gesagt
In uptimekuma hatte ich noch wikijs stehen, obwohl ich den stack gelöscht hatte. Kann es sein, dass er dann trotzdem ein positives feedback gab, weil ich wiki. nach google forwarde?
Das ist ein Klassiker bei der Fehlersuche mit Reverse Proxys! Die kurze Antwort lautet: Ja, absolut.
Wenn du in Uptime Kuma eine URL (z. B. wiki.deinedomain.de) überwachst und diese im Nginx Proxy Manager (NPM) noch auf eine funktionierende Seite (wie Google) weitergeleitet wird, erhält Uptime Kuma einen HTTP Status Code 200 (OK) oder 302 (Redirect) zurück. Beides wertet Kuma standardmäßig als "Up".
Hier ist, was da im Hintergrund passiert ist:
Uptime Kuma fragt wiki.deinedomain.de ab.
DNS/NPM nimmt die Anfrage an (der Proxy lebt ja noch, auch wenn der Wiki-Stack weg ist).
NPM führt deine Weiterleitung zu Google aus.
Google antwortet mit "200 OK".
Uptime Kuma sieht das "200 OK" und denkt: "Super, das Wiki läuft!" – dabei hat es nur die Antwort von Google gesehen.
Damit Uptime Kuma nicht "angelogen" wird, hast du zwei Möglichkeiten:
Keyword-Monitoring: Stell in Uptime Kuma beim Monitor ein, dass er nach einem bestimmten Wort auf der Seite suchen soll (z. B. "WikiJS" oder ein Wort aus deinem Wiki-Header). Wenn er dann auf Google landet, findet er das Wort nicht und schlägt Alarm (Down), obwohl die Verbindung steht.
Direkte IP/Port-Überwachung: Überwach im internen Netzwerk lieber direkt http://deine-server-ip:port. Wenn der Docker-Container (der Stack) gelöscht ist, läuft die Anfrage ins Leere, und Kuma zeigt sofort korrekt "Down" an, egal was der Proxy draußen macht.
Vergiss nicht, auch den Host im Nginx Proxy Manager zu löschen oder zu deaktivieren. Sonst wunderst du dich in ein paar Monaten, warum deine Domain immer noch irgendwohin weiterleitet.
Soll ich dir zeigen, wie du in Uptime Kuma eine Benachrichtigung (z. B. via Telegram oder Discord) einrichtest, damit du sofort merkst, wenn dein neuer Firefly-Server mal zickt?
Du hast gesagt
die benachrichtigung haben wir schon eingerichtet mit gotify und die funktioniert auch.
Danke
Perfekt, dann bist du mit Gotify ja schon bestens aufgestellt – das passt auch wunderbar zum Self-hosting-Ansatz, da die Benachrichtigungen so in deinem eigenen Netzwerk bleiben.
Da dein Firefly III nun über NPM erreichbar ist, die Handy-App läuft und dein Monitoring mit Uptime Kuma scharf geschaltet ist, steht deiner digitalen Buchhaltung nichts mehr im Weg.
Viel Erfolg beim ersten Kassensturz! Wenn du später mal Hilfe bei komplexeren SQL-Abfragen für deine Exporte oder bei der Automatisierung der Backups deiner Docker-Ordner brauchst, sag einfach Bescheid.
Soll ich dir zum Abschluss noch kurz zeigen, wie du in Firefly III ein "Sparziel" für dein nächstes Server-Upgrade anlegst?
Du hast gesagt
nein danke
Alles klar, dann bist du ja jetzt bestens gerüstet! Viel Erfolg beim Erfassen deiner Finanzen – und falls die Pilze oder Zwiebeln doch mal das Budget sprengen, weißt du ja jetzt ganz genau, wo das Geld geblieben ist. 😉
Viel Spaß mit deinem neuen Self-hosted Setup!
Soll ich dir beim nächsten Mal vielleicht zeigen, wie du deine Docker-Backups automatisierst, damit deine Finanzdaten auch bei einem Festplattenfehler sicher sind?
Du hast gesagt
das haben wir auch schon getan.
Sag mal: uptimekume zeigt, dass ein update verfügbar ist. wir haben image: louislam/uptime-kuma:1 genutzt. wie aktuell ist das von mir derzeit verwendete uptimekuma v1.23.17 ?
Da hast du ein spannendes Timing erwischt! Deine Version v1.23.17 ist zwar die aktuellste Version des "alten" v1-Zweiges, aber technisch gesehen bist du damit auf einem Abstellgleis gelandet.
Deine Version (v1.23.17): Das ist das finale Release von Uptime Kuma v1. Es wird vom Entwickler (Louis Lam) nur noch für absolute Notfall-Fixes angefasst. Da du den Tag :1 nutzt, bleibst du fest auf dieser alten Schiene.
Aktuelle Version: Wir sind mittlerweile bei v2.1.x (stabil seit Ende 2025).
Warum das Update angezeigt wird: Uptime Kuma erkennt, dass es auf GitHub einen Nachfolger (v2) gibt. Da du aber :1 in deiner Config stehen hast, zieht Docker beim "Pull" niemals automatisch die neue Hauptversion, da v2 gravierende Änderungen (z. B. Unterstützung für MariaDB und ein neues UI-Backend) mitbringt.
Datenbank: Unterstützung für externe Datenbanken (MariaDB/MySQL), was bei vielen Monitoren deutlich stabiler läuft als das alte SQLite.
UI Refresh: Das Interface ist moderner, schneller und bietet bessere Gruppen-Funktionen.
Sicherheit: "Rootless" Support im Docker-Container.
Benachrichtigungen: Viele neue Provider und stabilere Integrationen.
Da du dein System gerade erst frisch aufsetzt und mit NPM und Gotify schon modern arbeitest, solltest du v2 mitnehmen.
So machst du das Update sicher:
Backup: Du sagtest, du hast Backups – sehr gut! Kopiere zur Sicherheit den Ordner /home/florian/docker/uptimekuma nochmal manuell weg.
Stack anpassen: Ändere in deinem Portainer-Stack das Image von: image: louislam/uptime-kuma:1 auf image: louislam/uptime-kuma:2
Neu ausrollen: Stack aktualisieren ("Update the stack").
Wichtig: Beim ersten Start von v2 wird die Datenbank konvertiert. Das dauert je nach Anzahl deiner Monitore ein paar Sekunden bis Minuten. Danach hast du ein frisches System und die Update-Meldung ist weg.
Soll ich dir kurz helfen, die docker-compose.yml für v2 zu optimieren, oder willst du es einfach mal mit dem Tag-Wechsel riskieren?
Du hast gesagt
bleiben beim update die monitore und die benachrichtigung erhalten?
Ja, die Monitore und Benachrichtigungen bleiben beim Update erhalten.
Uptime Kuma ist darauf ausgelegt, die bestehende Datenbank beim ersten Start der neuen Version automatisch zu migrieren. Da du deine Daten in einem lokalen Ordner unter /home/florian/docker/ gespeichert hast, greift der neue Container auf genau diese Daten zu und wandelt sie in das Format der Version 2 um.
Hier sind zwei Dinge, auf die du achten solltest, damit alles glattläuft:
Datenbank-Migration: Beim Wechsel von v1 auf v2 findet eine interne Konvertierung statt. Das passiert automatisch beim ersten Start. In dieser Zeit kann es sein, dass das Web-Interface für ein paar Momente nicht erreichbar ist.
Backup ist Pflicht: Auch wenn der Prozess sehr stabil ist, ist ein Versionssprung (von 1 auf 2) ein großer Schritt. Da du deine Backups aber bereits eingerichtet hast, bist du auf der sicheren Seite.
Kurzer Check deiner stack.yml für das Update: Du musst lediglich die Zeile beim Image anpassen: image: louislam/uptime-kuma:2 (oder :latest)
Danach in Portainer auf "Update the stack" klicken und sicherstellen, dass die Option "Re-pull image" aktiviert ist, damit er die neue Version auch wirklich vom Server lädt.
Soll ich dir noch sagen, woran du im Log erkennst, ob die Datenbank-Migration erfolgreich abgeschlossen wurde?
Du hast gesagt
das hier ist das aktuell verwendete stack compose:
version: "3.3"
services:
uptime-kuma:
image: louislam/uptime-kuma:1
container_name: uptime-kuma
volumes:
- /home/florian/docker/uptime-kuma:/app/data
ports:
- "3001:3001" # Intern für NPM
restart: unless-stopped
Das sieht absolut solide aus. Um auf Version 2 zu wechseln, musst du nur eine einzige Ziffer ändern.
Hier ist die angepasste Version für dein Portainer-Update:
YAML
version: "3.3"
services:
uptime-kuma:
image: louislam/uptime-kuma:2 # Hier von :1 auf :2 geändert
container_name: uptime-kuma
volumes:
- /home/florian/docker/uptime-kuma:/app/data
ports:
- "3001:3001"
restart: unless-stopped
Gehe in deinen Uptime-Kuma Stack und klicke auf Editor.
Ändere das Image auf louislam/uptime-kuma:2.
Klicke unten auf Update the stack.
Ganz wichtig: Aktiviere den Schalter "Re-pull image". Nur so lädt Portainer die neue Version 2 wirklich herunter, statt die alte v1 aus dem lokalen Zwischenspeicher zu nehmen.
Der alte Container wird gestoppt.
Das neue Image (v2) wird geladen.
Beim Start erkennt Uptime Kuma deine Daten in /home/florian/docker/uptime-kuma und führt die Datenbank-Migration durch. Deine Monitore, Historie und Gotify-Einstellungen bleiben dabei erhalten.
Ein kleiner Hinweis: Da du NPM (Nginx Proxy Manager) nutzt, musst du dort nichts ändern. Die interne Kommunikation über Port 3001 bleibt exakt gleich.
Soll ich kurz warten, bis du das Update angestoßen hast, falls beim ersten Start der v2 doch eine Fehlermeldung im Log auftaucht?
Du hast gesagt
update verlief reibungslos und alle monitore sind noch da und die benachrichtigung eingestellt
Das ist klasse! Da sieht man mal wieder: Ein sauberer Docker-Stack und ein vorhandenes Backup im Rücken lassen einen bei solchen Versionssprüngen deutlich ruhiger schlafen.
Dass die Migration so reibungslos verlief, spricht dafür, dass deine Datenbank (SQLite) keine Altlasten hatte. Du solltest jetzt im Interface von Uptime Kuma v2 ein paar kleine optische Neuerungen bemerken und das System sollte insgesamt etwas flüssiger reagieren.
Zwei kleine Dinge, die du jetzt noch prüfen kannst:
Neue Funktionen: Schau mal in die Einstellungen. In v2 gibt es oft neue Monitor-Typen oder verbesserte Intervalle, die du jetzt nutzen kannst.
Log-Sauberkeit: Wirf in Portainer kurz einen Blick in die Container-Logs von Uptime Kuma. Wenn dort keine "Database error"-Meldungen auftauchen, ist die Migration final abgeschlossen.
Dein Setup mit Firefly III, NPM, Gotify und dem frischen Uptime Kuma v2 ist jetzt richtig modern und professionell aufgestellt.
Da wir gerade bei Updates sind: Soll ich dir zeigen, wie du mit einem kleinen Tool wie Watchtower automatisch benachrichtigt wirst (natürlich über Gotify), wenn für einen deiner Container (Firefly, NPM, Kuma) ein Update verfügbar ist?
Du hast gesagt
keine fehler im log, nur erfolgreiche migrierung. wenn es immer so laufen könnte
Das ist das Schöne an Docker: Wenn die Pfade stimmen und die Entwickler ihre Hausaufgaben machen, ist ein Major-Update oft nur ein winziger Moment der Anspannung, gefolgt von einem erleichterten Aufatmen.
Dass die Migration so sauber durchlief, liegt auch an deinem Setup – Bind Mounts (deine direkten Ordnerpfade) sind einfach deutlich transparenter und weniger fehleranfällig als anonyme Docker-Volumes.
Da jetzt alles auf dem neuesten Stand ist und fehlerfrei läuft:
Firefly III ist bereit für deine Finanzen.
Uptime Kuma v2 wacht über deine Dienste.
Gotify meldet sich, wenn was hakt.
NPM regelt den Verkehr von draußen.
Ein richtig schönes, sauberes Self-Hosting-Dashboard hast du dir da gebaut!
Falls du irgendwann mal Lust hast, dein Setup noch weiter zu automatisieren oder zum Beispiel ein schickes Dashboard wie Homepage oder Dashy davorzusetzen, um alle Links an einem Ort zu haben, melde dich einfach.
Viel Spaß beim Eintragen der ersten Ausgaben in dein neues Haushaltsbuch! Soll ich dir zum Abschluss noch einen Tipp geben, wie du die Datenbank von Firefly III am besten von der Kommandozeile aus sicherst?
Du hast gesagt
in uptimekuma kann ich statusseiten erstellen. wozu dienen die?
Statusseiten sind im Grunde das "Schaufenster" deines Servers. Während das Dashboard, in dem du deine Monitore verwaltest, dein interner Kontrollraum ist, sind Statusseiten eine öffentliche (oder private) Übersicht, die nur das Wichtigste zeigt.
Hier sind die Hauptgründe, warum man sie nutzt:
Im normalen Dashboard kannst du Monitore löschen, ändern oder pausieren. Auf einer Statusseite kann man nichts verstellen. Das ist ideal, wenn du:
Anderen (Familie, Mitbewohnern, Freunden) zeigen willst, ob ein Dienst (z. B. Plex, Nextcloud oder dein neues Firefly III) gerade läuft.
Deinen Status schnell checken willst, ohne dich jedes Mal in Uptime Kuma einloggen zu müssen.
Du kannst mehrere Statusseiten erstellen. Zum Beispiel:
Seite "Finanzen": Zeigt nur Firefly III und die Datenbank.
Seite "Home-Server": Zeigt den Status von NPM, Portainer und deinen Festplatten-Checkern.
Seite "Extern": Zeigt, ob Google, deine Website oder dein Smart Home erreichbar sind.
Das ist das Profi-Feature: Wenn ein Dienst ausfällt, kannst du auf der Statusseite eine Nachricht hinterlassen (z. B. "Wartungsarbeiten bis 22 Uhr"). Besucher sehen dann nicht nur "Down", sondern wissen direkt, was los ist.
Falls du dir irgendwann ein zentrales Dashboard (wie Homepage oder Heimdall) baust, kannst du dort einfach den Link zur Statusseite hinterlegen. So hast du einen schnellen visuellen Check ("Alles grün"), ohne die Komplexität der gesamten Verwaltung zu sehen.
Klicke oben in der Leiste auf "Status Pages".
Wähle "New Status Page".
Vergib einen Namen und eine URL (z.B. /status/privat).
Wähle per Drag-and-Drop aus, welche Monitore auf dieser Seite erscheinen sollen.
Kleiner Tipp: Du kannst die Statusseite sogar mit einem Passwort schützen, wenn sie zwar schick aussehen, aber nicht für jeden im Internet (über deinen NPM-Proxy) sichtbar sein soll.
Soll ich dir zeigen, wie du in NPM eine eigene Subdomain (z.B. status.deinedomain.de) direkt auf diese Statusseite leitest?
Du hast gesagt
also kann ich die dort erstellte seite unabhängig vom login auf der hauptseite laufen lassen und sehen?
Genau so ist es. Das ist der große Vorteil: Die Statusseite ist eine eigenständige, schlanke Webseite, die komplett ohne Login funktioniert (außer du aktivierst explizit einen Passwortschutz für die Seite).
Hier ist, wie das in der Praxis abläuft:
Unabhängiger Zugriff: Du kannst die Statusseite zum Beispiel unter https://deine-domain.de/status/meinessetze aufrufen. Jeder, der diesen Link hat, sieht sofort, ob alles "grün" ist, ohne dass er deinen Benutzernamen oder dein Passwort für Uptime Kuma kennen muss.
Sicherheit: Deine Verwaltungs-Oberfläche (wo man Monitore löscht oder Passwörter einsieht) bleibt weiterhin durch deinen Login geschützt. Die Statusseite zeigt nur die Namen der Dienste und deren Erreichbarkeit an.
Anzeige im Haus: Viele nutzen das, um die Statusseite auf einem alten Tablet an der Wand oder einem zweiten Monitor dauerhaft offen zu lassen. Da kein Login abläuft, musst du dich dort nie wieder neu anmelden.
Einbindung in NPM: Wenn du in Nginx Proxy Manager bereits eine Domain für Uptime Kuma hast, kannst du die Statusseite einfach als Lesezeichen speichern. Du kannst in NPM sogar eine eigene Subdomain wie status.deinedomain.de direkt auf den Pfad der Statusseite leiten.
Es ist im Grunde ein öffentliches (oder halb-öffentliches) Dashboard, das sich automatisch aktualisiert, ohne dass man Administrator-Rechte braucht.
Probiere es mal aus: Erstelle eine Test-Seite, füge zwei Monitore hinzu und öffne den Link mal im "Inkognito-Modus" deines Browsers. Du wirst sehen, dass die Seite sofort lädt, ohne nach einem Login zu fragen.
Du hast gesagt
cool, danke
Sehr gerne! Es freut mich, dass jetzt alles so reibungslos läuft. Du hast dir da ein wirklich sauberes und professionelles Setup aufgebaut.
Mit der Statusseite hast du jetzt den perfekten Überblick, ohne dich jedes Mal "unter die Motorhaube" deines Servers begeben zu müssen. Das ist das Schöne am Self-Hosting: Wenn es einmal richtig konfiguriert ist, arbeitet es einfach für dich im Hintergrund.
Viel Erfolg beim Sortieren deiner Finanzen in Firefly III und beim Beobachten deiner "grünen Balken" in Uptime Kuma.
Solltest du mal Fragen zu Backups der Datenbanken oder zur Erweiterung deines Stacks haben, weißt du ja, wo du mich findest. Viel Spaß mit deinem Heimserver!
Möchtest du zum Abschluss noch wissen, wie du die Statusseite in deinem Browser als Web-App (PWA) auf dem Handy-Startbildschirm speicherst?
Du hast gesagt
guten morgen, ja bitte, erklär es mir mal
Guten Morgen! Das ist der perfekte Weg, um den Status deines Servers immer nur einen Fingertipp entfernt zu haben, ohne erst den Browser öffnen und eine URL tippen zu müssen.
Da du die Statusseite in Uptime Kuma v2 ohne Login freigegeben hast, funktioniert sie hervorragend als PWA (Progressive Web App).
Öffne Safari und ruf deine Statusseite auf (z. B. https://status.deinedomain.de).
Tippe unten in der Mitte auf das Teilen-Symbol (das Quadrat mit dem Pfeil nach oben).
Scrolle nach unten und wähle "Zum Home-Bildschirm" (Add to Home Screen).
Vergib einen Namen (z. B. "Server Status") und tippe auf Hinzufügen.
Öffne Chrome und ruf deine Statusseite auf.
Tippe oben rechts auf die drei Punkte.
Wähle "Zum Startbildschirm hinzufügen" oder direkt "App installieren" (Chrome erkennt oft automatisch, dass es eine PWA ist).
Bestätige die Installation.
Eigenes Icon: Du hast ein schönes Uptime-Kuma-Icon auf deinem Homescreen.
Vollbild-Modus: Wenn du die "App" öffnest, verschwindet oft die Adresszeile des Browsers. Es fühlt sich an wie eine echte, native App.
Schnellcheck: Ein Blick reicht aus, um zu sehen, ob alle Dienste im grünen Bereich sind, während du morgens deinen Kaffee trinkst.
In den Einstellungen der Statusseite in Uptime Kuma kannst du unter "Custom CSS" sogar das Design anpassen, falls dir die Standardfarben nicht gefallen. Aber für den Anfang ist das schlichte Design von v2 eigentlich schon sehr schick.
Dein Setup ist damit jetzt wirklich komplett mobil-tauglich!
Gibt es noch etwas, das du an deinem Server-Dashboard optimieren möchtest, oder bist du fürs Erste wunschlos glücklich mit deinem "Finanz- und Monitoring-Zentrum"?