Journal-IndexDockup / Feldnotiz
Note / self-host-actualbudget

Actual Budget 2026 selbst hosten: Sync, HTTPS und Backups von Finanzdaten

Actual Budget mit dem richtigen Port, dauerhaftem Storage, TLS, Authentifizierung und Backups bereitstellen. Fehler beheben, wenn das Sync-Verzeichnis in Produktion flüchtig ist.

Ein fehlgeschlagenes Actual-Budget-Deployment stürzt nicht immer ab. Es kann eine Login-Seite ausliefern, während das Sync-Verzeichnis flüchtig ist oder ein Proxy große Sync-Requests entfernt. Beginne stattdessen mit einer Ende-zu-Ende-Prüfung: Erstelle ein Budget oder importiere eines, füge Transaktionen hinzu, synchronisiere einen zweiten Browser und erstelle einen Export auf Anwendungsebene.

Diese Prüfung entspricht dem dokumentierten Zweck von Actual Budget: Budgetplanung nach dem Umschlagprinzip mit Daten, die auf deinem Datenträger gespeichert werden. Außerdem macht sie fehlende Abhängigkeiten, falsche Proxy-Annahmen und flüchtige Daten früher sichtbar als ein einfacher Uptime-Check.

Actual Budget von seinen Abhängigkeiten trennen

Beginne mit dem Netzwerk-Namespace von Actual Budget: Der Web-Listener läuft auf Port 5006 – nicht auf einem Host-Port, der aus einem Laptop-Tutorial übernommen wurde. Die lokale Laufzeitanforderung besteht aus einem dauerhaft gespeicherten Daten-Volume und einem unterstützten Browser für die Ersteinrichtung. Halte den Lifecycle explizit, damit ein Umzug von Actual Budget zwischen Hosts das Verhalten nicht unbemerkt verändert.

Sobald die Anforderung erfüllt ist, führe das vollständige Szenario aus – erstelle ein Budget oder importiere eines, füge Transaktionen hinzu, synchronisiere einen zweiten Browser und erstelle einen Export auf Anwendungsebene. Zeichne Logs und Messwerte für die Budgetdateigröße, den Sync-Traffic und den Server-Storage auf, statt eine aufwendige Berechnung auf dem Server vorauszusetzen. Diese Nachweise bilden die erste bekannte funktionierende Architektur und machen spätere Umzüge zwischen Dockup-Compute und einem angebundenen Server testbar.

Die erste produktionsnahe Instanz ausführen

Ein minimaler Befehl ist nützlich, wenn er sichtbar macht, was die Plattform später verwalten wird.

docker run -d \
  --name actual-budget \
  --restart unless-stopped \
  -p 127.0.0.1:5006:5006 \
  -v actual-budget-data:/data \
  -e ACTUAL_PORT=5006 \
  actualbudget/actual-server:latest

Port 5006 bleibt hier nur für den Host verfügbar, und jeder erforderliche Pfad ist explizit angegeben. Bestätige die lokale Anforderung vor der Freigabe: ein dauerhaft gespeichertes Daten-Volume und ein unterstützter Browser für die Ersteinrichtung. Überprüfe den Start sowohl anhand der Logs als auch mit dem anwendungsspezifischen Nachweis: Erstelle ein Budget oder importiere eines, füge Transaktionen hinzu, synchronisiere einen zweiten Browser und erstelle einen Export auf Anwendungsebene. Sobald alles verifiziert ist, pinne die Image-Version, damit ein routinemäßiger Austausch das Verhalten nicht unbemerkt verändert.

Die öffentliche Origin eindeutig festlegen

Wähle den endgültigen Hostnamen für Actual Budget, bevor Benutzer Callbacks oder Client-Einstellungen speichern, und verwende eine stabile HTTPS-URL, damit Sync-Clients dem Server vertrauen. Die Plattform-Route sollte TLS einmalig terminieren und auf den privaten Port 5006 zeigen.

Führe die Transaktion zur Abnahme von außen aus. Wenn der Client Actual Budget nie erreicht, verwende die Checkliste zur SSL-Validierung für DNS- und Zertifikatsprüfungen. Wenn der Request Actual Budget erreicht, das Sync-Verzeichnis jedoch flüchtig ist oder ein Proxy große Sync-Requests entfernt, ändere nicht weiter Proxy-Redirects, sondern überprüfe die anwendungsspezifische Grenze.

Die Wiederherstellung von Actual Budget messbar machen

Erstelle ein Wiederherstellungsmanifest für Actual Budget: Serverdateien sowie regelmäßige Budget-Exporte auf Anwendungsebene. Binde /data vor dem Bootstrap ein, schreibe harmlose Testdaten und ersetze den Container, um nachzuweisen, dass dieser Pfad tatsächlich dauerhaft gespeichert wird. Prüfe jetzt Besitzrechte und freien Speicherplatz, denn ein eingebundener, aber nicht beschreibbarer Pfad verhält sich wie fehlende Persistenz.

Erstelle Backups in einer von dem laufenden Server getrennten Failure Domain. Stelle Actual Budget aus dem gepinnten Image wieder her und überprüfe, dass der wiederhergestellte Server dieselben Konten und Salden synchronisiert und der unabhängige Export ebenfalls importiert werden kann. Der Leitfaden zu persistenten Volumes hilft dabei, diese Übung in eine Snapshot- und Retention-Policy zu überführen.

Actual Budget nach dem Bootstrap absichern

Bootstrap-Zugangsdaten sind temporär, das Trust-Modell bleibt dauerhaft bestehen. Achte bei Actual Budget darauf, keinen Finanzserver zu veröffentlichen, bevor sein Passwort konfiguriert ist. Setze das Serverpasswort vor der Freigabe und verwende HTTPS, da die Instanz die vollständige Finanzhistorie enthält.

ACTUAL_PORT steuert das Verhalten, nicht die Vertraulichkeit. Validiere Typ und Wert und speichere echte Actual-Budget-Zugangsdaten getrennt. Führe das Image ohne unnötige Linux-Capabilities aus und veröffentliche nur die öffentliche Anwendungsroute. Mache Administratoraktivitäten sichtbar, ohne geheime Werte aufzuzeichnen.

Actual Budget entlang seines tatsächlichen Engpasses betreiben

Erstelle Dashboards für die Budgetdateigröße, den Sync-Traffic und den Server-Storage, statt eine aufwendige Berechnung auf dem Server vorauszusetzen. Ein CPU-Graph ohne diesen Workload-Kontext kann nicht erklären, warum Actual Budget langsam ist. Ergänze einen synthetischen oder geplanten Check, der versucht, mit harmlosen Testdaten ein Budget zu erstellen oder zu importieren, Transaktionen hinzuzufügen, einen zweiten Browser zu synchronisieren und einen Export auf Anwendungsebene zu erstellen.

Berücksichtige vor einem Upgrade diese anwendungsspezifische Gefahrenquelle: Die Datenmigrationen von Actual sollten sowohl mit Serverdateien als auch mit einem exportierten Budget getestet werden, das für ein Rollback verfügbar ist. Stelle ein aktuelles Backup in einem isolierten Deployment wieder her, führe die Migrationen dort aus und vergleiche das Verhalten. Wenn das Sync-Verzeichnis flüchtig ist oder ein Proxy große Sync-Requests entfernt, überprüfe zuerst die betroffene Grenze – öffentliche Origin, Storage oder Abhängigkeit –, bevor du andere Einstellungen änderst.

Nachweise vor dem Go-live von Actual Budget sammeln

Erstelle ein kleines, wegwerfbares Actual-Budget-Fixture und bewahre es für jedes Release auf. Das Fixture sollte den echten Workflow abbilden: Erstelle ein Budget oder importiere eines, füge Transaktionen hinzu, synchronisiere einen zweiten Browser und erstelle einen Export auf Anwendungsebene. Zeichne den Image-Digest, den externen Hostnamen, die Adresse der Abhängigkeit und das erwartete Ergebnis auf, damit ein späterer Operator den Test wiederholen kann, ohne diesen Leitfaden interpretieren zu müssen.

Führe das Fixture dreimal aus. Verwende es zuerst mit dem frischen Deployment. Ersetze zweitens den Container, ohne den dauerhaft gespeicherten Zustand anzutasten. Stelle drittens das Backup in einer leeren Umgebung wieder her. Der dritte Lauf ist nur dann erfolgreich, wenn der wiederhergestellte Server dieselben Konten und Salden synchronisiert und der unabhängige Export ebenfalls importiert werden kann. Erfasse während jedes Laufs Latenz und Ressourcennutzung im Zusammenhang mit Budgetdateigröße, Sync-Traffic und Server-Storage, statt eine aufwendige Berechnung auf dem Server vorauszusetzen. Daraus entsteht die Grundlage für Alerts, nicht aus einem beliebigen CPU-Prozentsatz.

Teste schließlich bewusst den negativen Pfad: Sende harmlose Eingaben nahe am Ressourcen- oder Formatlimit, das mit dieser Grenze verbunden ist: Das Sync-Verzeichnis ist flüchtig oder ein Proxy entfernt große Sync-Requests. Bestätige, dass Actual Budget sichtbar fehlschlägt, ohne den Zustand zu beschädigen, stelle die korrekte Bedingung wieder her und wiederhole die erfolgreiche Transaktion. Ein Release-Eintrag mit diesen vier Ergebnissen ist aussagekräftiger als Dashboard-Screenshots oder eine einmalige curl-Antwort.

Wiederholbare Infrastrukturarbeiten zu Dockup verlagern

Dockup kann die austauschbaren Plattformbestandteile übernehmen: Traffic auf Port 5006 leiten, Domain und Zertifikat ausstellen, Secrets injizieren, persistenten Storage anbinden und Actual Budget mit verwalteten oder privat angebundenen Services verbinden. Das ist sowohl auf der Dockup-Infrastruktur als auch auf einem von dir angebundenen Server möglich.

Die Abnahme von Actual Budget bleibt explizit. Verwende nach dem One-Click-Deployment eine stabile HTTPS-URL, damit Sync-Clients dem Server vertrauen, bestätige die lokale Anforderung – ein dauerhaft gespeichertes Daten-Volume und ein unterstützter Browser für die Ersteinrichtung – und führe dieses Szenario aus: Erstelle ein Budget oder importiere eines, füge Transaktionen hinzu, synchronisiere einen zweiten Browser und erstelle einen Export auf Anwendungsebene. Diese Aufteilung ist bewusst gewählt: Dockup beseitigt wiederholte Infrastrukturarbeit, ohne so zu tun, als würden sich Anwendungsrollen, Provider-Zugangsdaten oder die Restore-Policy von selbst festlegen.

Häufig gestellte Fragen

Was benötigt Actual Budget für ein produktives Deployment?

Leite den Actual-Budget-Container über eine einzige HTTPS-Origin auf Port 5006. Die lokale Laufzeitanforderung besteht aus einem dauerhaft gespeicherten Daten-Volume und einem unterstützten Browser für die Ersteinrichtung. Erkläre Actual Budget erst dann für einsatzbereit, wenn du ein Budget erstellen oder importieren, Transaktionen hinzufügen, einen zweiten Browser synchronisieren und einen Export auf Anwendungsebene erstellen kannst.

Welche Actual-Budget-Daten gehören in ein Backup?

Persistiere /data und nimm Serverdateien sowie regelmäßige Budget-Exporte auf Anwendungsebene in dasselbe Wiederherstellungsmanifest auf. Eine saubere Wiederherstellung von Actual Budget ist nur dann erfolgreich, wenn der wiederhergestellte Server dieselben Konten und Salden synchronisiert und der unabhängige Export ebenfalls importiert werden kann.

Benötigt Actual Budget hinter einem Reverse Proxy HTTPS?

Verwende HTTPS für die öffentliche Actual-Budget-Origin und halte Port 5006 auf der internen Route. Setze die Actual-Budget-Einstellung korrekt: Verwende eine stabile HTTPS-URL, damit Sync-Clients dem Server vertrauen. Bei Actual Budget schützt HTTPS Zugangsdaten und Benutzerinhalte während der Übertragung und sorgt für konsistentes, originabhängiges Client-Verhalten.

Wie sollte ein Actual-Budget-Upgrade getestet werden?

Stelle den aktuellen Actual-Budget-Zustand in einem isolierten Deployment wieder her, spiele die Kandidatenversion ein und wiederhole die Abnahmetransaktion. Gehe dabei besonders sorgfältig vor, da die Datenmigrationen von Actual sowohl mit Serverdateien als auch mit einem exportierten Budget getestet werden sollten, das für ein Rollback verfügbar ist. Bewahre das vorherige Actual-Budget-Image auf, bis die Grenzen von Datenmigration und Rollback verstanden sind.