Wallos mit Docker Compose selbst hosten: Abo- und Vertragskosten im Blick

Wer im Unternehmen oder im Homelab Abos und Verträge sammelt, verliert schnell den Überblick: Softwarelizenzen, Domains, Hosting, Mobilfunk, Versicherungen, Cloud-Speicher. Jede einzelne Position ist klein, die Summe ist es nicht. Wallos ist ein quelloffener, selbst hostbarer Tracker genau für diese wiederkehrenden Ausgaben. Die Anwendung läuft als einzelner Docker-Container mit SQLite-Datenbank, braucht keinen separaten Datenbankdienst und ist in wenigen Minuten betriebsbereit.

Diese Anleitung führt durch eine vollständige Installation mit Docker Compose. Alles, was hier als im Test bestätigt markiert ist, stammt aus einem tatsächlich durchgeführten Testlauf am 23.09.2026 mit dem Image bellamy/wallos:latest. Alles andere ist ausdrücklich als laut offizieller Dokumentation gekennzeichnet. Diese Trennung ist bewusst streng gehalten, damit Sie wissen, worauf Sie sich verlassen können.

Nutzen und Grenzen

Wallos beschreibt sich selbst als quelloffenen, selbst hostbaren persönlichen Abo-Tracker zur Visualisierung wiederkehrender Ausgaben und zur Budgetverwaltung. Genau das ist der Anwendungsfall, und genau dort hört er auch auf. Bevor Sie das Projekt in einem geschäftlichen Umfeld einplanen, sollten Sie die Grenzen kennen.

Der Funktionsumfang laut offizieller README umfasst die Verwaltung wiederkehrender Abos und Zahlungen mit Fälligkeitsterminen, anpassbare Kategorien, Mehrwährungsunterstützung mit Währungsumrechnung über die Fixer-API, anpassbare Währungen und Themes, Sortieroptionen, eine Logo-Suche im Web, eine mobile Ansicht, Statistiken, Benachrichtigungen über E-Mail, Discord, Pushover, Telegram, Gotify und Webhooks, Mehrsprachigkeit, OIDC-Anmeldung mit OAuth sowie KI-Empfehlungen über ChatGPT, Gemini oder ein lokales Ollama.

Was Wallos ausdrücklich nicht ist:

• Kein Buchhaltungssystem. Es gibt keine doppelte Buchführung, keine Kontenrahmen, keine GoBD-konforme Belegablage und keinen Export für den Steuerberater im üblichen Sinn.
• Kein ERP-System. Bestellwesen, Lagerhaltung, Auftragsabwicklung oder Personalverwaltung sind kein Thema des Projekts.
• Keine Bankanbindung. Wallos zieht keine Kontoumsätze per FinTS oder PSD2-Schnittstelle. Jede Position wird manuell gepflegt.
• Kein Mandantenmodell. Es gibt Haushaltsmitglieder innerhalb einer Instanz, aber keine getrennten Mandanten mit eigener Datenhaltung und eigenen Rechten. Für mehrere Kunden oder Gesellschaften brauchen Sie mehrere Instanzen.
• Keine Vertragsdokumentenverwaltung im Sinne eines DMS. Kündigungsfristen lassen sich über Fälligkeitstermine abbilden, ein rechtssicheres Fristenmanagement ist das nicht.

Für eine Einzelperson, ein kleines Team oder die IT-Abteilung, die ihre Softwareabos im Blick behalten will, ist das Werkzeug sehr gut geeignet. Für die Finanzbuchhaltung eines Unternehmens ist es das falsche Werkzeug.

Verbreitung des Projekts

Die Zahlen zum Projekt wurden am 23.09.2026 über die GitHub-API abgerufen: Das Repository ellite/Wallos hatte zu diesem Zeitpunkt 8567 Sterne, der letzte Push datiert auf den 18.09.2026, das Repository ist nicht archiviert und steht unter der Lizenz GPL-3.0. Das aktuelle Release ist v5.8.1 vom 18.09.2026. Das Projekt wird also aktiv gepflegt. Weitergehende Trend- oder Wachstumsaussagen lassen sich aus diesen Momentaufnahmen nicht seriös ableiten, deshalb bleiben sie hier bewusst aus.

Voraussetzungen und Ressourcenbedarf

Für den Betrieb mit Docker brauchen Sie laut offizieller Dokumentation nichts weiter als Docker selbst. Kein separater Datenbankserver, kein Webserver davor, keine Laufzeitumgebung auf dem Host. Die Anwendung bringt alles mit.

• Docker Engine mit dem Compose-Plugin (docker compose, nicht das alte docker-compose).
• Ein freier TCP-Port auf dem Host. Das offizielle Beispiel veröffentlicht Port 8282.
• Speicherplatz: sehr wenig. Im Test war die frisch angelegte SQLite-Datenbank wallos.db 200704 Bytes groß, ein Offline-Backup aus Datenbank und Logo-Verzeichnis als tar.gz kam auf 7413 Bytes. Rechnen Sie mit wenigen hundert Megabyte inklusive Image und hochgeladenen Logos.
• Arbeitsspeicher: Es handelt sich um eine PHP-Anwendung mit SQLite. Ein kleiner Server mit 1 GB RAM reicht in der Praxis aus. Eine offizielle Mindestangabe nennt das Projekt nicht, deshalb ist dies eine Erfahrungseinschätzung und keine belegte Herstellerangabe.

Wer Wallos ohne Container betreiben will, braucht laut README NGINX oder Apache sowie PHP 8.3 mit den Modulen curl, dom, gd, intl, openssl, sqlite3, zip, mbstring und fpm. Im Test bestätigt: Im Container läuft PHP 8.3.33, gebaut am 17.09.2026. Die Container-Variante nimmt Ihnen also genau diese Abhängigkeitspflege ab.

Unterstützte Plattformen

Das Image bellamy/wallos:latest wird über Docker Hub bereitgestellt. Es basiert auf Alpine Linux, erkennbar daran, dass der Webserver-Benutzer www-data im Container die UID 82 trägt, was die Alpine-Konvention ist. Damit läuft Wallos überall dort, wo eine Docker Engine läuft: Linux-Server, Proxmox-LXC mit Docker, NAS-Systeme mit Container-Unterstützung, Docker Desktop unter Windows oder macOS. Der Testlauf für diese Anleitung fand auf einem Linux-Host statt. Aussagen zu anderen Plattformen sind daher dokumentiert, nicht selbst geprüft.

Getestete Version

Getestet wurde am 23.09.2026 das Image bellamy/wallos:latest, passend zum Release v5.8.1 vom 18.09.2026. Ein latest-Tag ist bequem, aber nicht reproduzierbar: Er zeigt morgen möglicherweise auf eine andere Version. Für produktive Installationen sollten Sie prüfen, ob auf Docker Hub ein versionierter Tag verfügbar ist, und diesen festnageln. Der Vorteil ist, dass ein Update dann eine bewusste Entscheidung ist und nicht die Nebenwirkung eines docker compose pull.

Die compose.yaml

Das Projekt liefert in der README folgende Vorlage. Sie ist hier unverändert wiedergegeben, damit Sie die Abweichungen der Praxisvariante darunter nachvollziehen können:

services:
  wallos:
    container_name: wallos
    image: bellamy/wallos:latest
    ports:
      - "8282:80/tcp"
    environment:
      TZ: 'America/Toronto'
    volumes:
      - './db:/var/www/html/db'
      - './logos:/var/www/html/images/uploads/logos'
    restart: unless-stopped

Für eine deutsche Installation ist mindestens die Zeitzone anzupassen. Die folgende Praxisvariante setzt zusätzlich eine Bindung an die Loopback-Adresse, damit die Anwendung nicht ungeschützt aus dem Netz erreichbar ist, solange kein Reverse Proxy mit TLS davor steht:

services:
  wallos:
    container_name: wallos
    image: bellamy/wallos:latest
    # Nur lokal veroeffentlichen, der Reverse Proxy nimmt den externen Verkehr an
    ports:
      - "127.0.0.1:8282:80/tcp"
    environment:
      TZ: 'Europe/Berlin'
    volumes:
      - './db:/var/www/html/db'
      - './logos:/var/www/html/images/uploads/logos'
    restart: unless-stopped

Parameter im Detail

• container_name: wallos vergibt einen festen Containernamen. Das erleichtert Befehle wie docker logs wallos. Wer mehrere Instanzen betreibt, muss diesen Namen je Instanz eindeutig wählen oder die Zeile weglassen.
• image: bellamy/wallos:latest benennt das offizielle Image auf Docker Hub. Ersetzen Sie latest für reproduzierbare Installationen durch einen konkreten Versions-Tag.
• ports veröffentlicht den Container-Port 80 auf dem Host. Der Container lauscht intern immer auf Port 80, das ist im Image fest verdrahtet. Sie ändern nur die linke Seite. Das Präfix 127.0.0.1: begrenzt die Erreichbarkeit auf den Host selbst.
• TZ setzt die Zeitzone im Container. Das ist nicht kosmetisch: Fälligkeitstermine, die Berechnung der nächsten Zahlung und die geplanten Hintergrundaufgaben hängen daran. Für Deutschland gehört hier Europe/Berlin hinein.
• ./db:/var/www/html/db bindet das Verzeichnis mit der SQLite-Datenbank auf den Host. Ohne diesen Mount sind sämtliche Daten nach dem Entfernen des Containers verloren.
• ./logos:/var/www/html/images/uploads/logos sichert die hochgeladenen beziehungsweise per Websuche gefundenen Anbieter-Logos.
• restart: unless-stopped startet den Container nach einem Neustart des Hosts automatisch wieder, sofern Sie ihn nicht ausdrücklich gestoppt haben.

Die README nennt laut Dokumentation zwei weitere Varianten. Erstens eine Fassung mit abgeschaltetem Healthcheck, gedacht für Docker-Versionen älter als 25 oder für eine schnellere Statusmeldung beim Start:

services:
  wallos:
    container_name: wallos
    image: bellamy/wallos:latest
    ports:
      - "8282:80/tcp"
    environment:
      TZ: 'Europe/Berlin'
    volumes:
      - './db:/var/www/html/db'
      - './logos:/var/www/html/images/uploads/logos'
    healthcheck:
      test: ["NONE"]
    restart: unless-stopped

Zweitens ein reiner docker run-Aufruf mit denselben Mounts, falls Sie ganz ohne Compose arbeiten:

# Variante ohne Compose, gleiche Mounts und gleiche Zeitzone
docker run -d   --name wallos   -e TZ=Europe/Berlin   -p 8282:80   -v ./db:/var/www/html/db   -v ./logos:/var/www/html/images/uploads/logos   --restart unless-stopped   bellamy/wallos:latest

Für den dauerhaften Betrieb ist die Compose-Variante vorzuziehen, weil die gesamte Konfiguration versionierbar in einer Datei liegt.

Installation und Start

Legen Sie ein eigenes Verzeichnis für den Stack an und speichern Sie die Praxisvariante der compose.yaml darin:

# Verzeichnis fuer den Stack anlegen und hineinwechseln
mkdir -p /opt/wallos
cd /opt/wallos

# Image ziehen und Stack im Hintergrund starten
docker compose up -d

Der erste Aufruf lädt das Image herunter und kann je nach Anbindung einige Minuten dauern. Danach prüfen Sie den Status:

# Laufzustand und Healthcheck des Containers anzeigen
docker compose ps

Im Test bestätigt: Der Container meldete nach rund 19 Sekunden den Status Up (healthy). Das Image bringt also einen eigenen Healthcheck mit, Sie müssen keinen selbst definieren. Wenn die Spalte nach einer halben Minute weiterhin starting zeigt, lohnt ein Blick in die Logs:

# Laufende Logausgabe des Containers verfolgen
docker compose logs -f wallos

Funktions- und Healthcheck

Bevor Sie den Browser öffnen, lässt sich die Erreichbarkeit direkt auf der Kommandozeile prüfen. Im Test bestätigt sind die folgenden beiden Antworten (der Test lief auf dem abweichenden Port 18282, weil 8282 lokal belegt war; die Antworten selbst sind davon unabhängig):

# Startseite abfragen, nur den HTTP-Status ausgeben
curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8282/

Die Antwort ist 302 mit einer Weiterleitung auf /login.php. Das ist das erwartete Verhalten: Wallos schickt nicht angemeldete Besucher zur Anmeldung. Eine 302 ist hier also ein Erfolg und kein Fehler.

# Registrierungsseite fuer den ersten Benutzer pruefen
curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8282/registration.php

Die Antwort ist 200. Diese Seite ist die Erstregistrierung. Sobald der erste Benutzer angelegt ist, sollte sie nicht mehr offen für beliebige Dritte erreichbar sein. Genau deshalb ist die Bindung an 127.0.0.1 plus Reverse Proxy die bessere Ausgangslage als eine direkte Veröffentlichung ins Netz.

Ebenfalls im Test bestätigt: Im Container läuft PHP 8.3.33. Das lässt sich so nachvollziehen:

# PHP-Version im laufenden Container auslesen
docker compose exec wallos php -v

Erstkonfiguration

Laut offizieller Dokumentation läuft die Ersteinrichtung vollständig über die Weboberfläche. Rufen Sie die Instanz im Browser unter http://ip:port auf. Beim ersten Start muss ein Benutzerkonto angelegt werden, danach folgen die Einstellungen.

• Benutzerkonto anlegen: Der erste Aufruf führt zur Registrierung. Vergeben Sie ein starkes, eigenständiges Passwort.
• Avatar und Haushaltsmitglieder: In den Einstellungen lassen sich weitere Mitglieder pflegen, denen Abos zugeordnet werden können.
• Kategorien und Währungen anpassen: Die mitgelieferten Kategorien sind ein Vorschlag. Für eine betriebliche Nutzung bilden Sie hier besser Ihre eigene Struktur ab, etwa Softwarelizenzen, Hosting, Telekommunikation, Versicherungen.
• Fixer-API-Schlüssel eintragen: Für die automatische Währungsumrechnung hinterlegen Sie einen kostenlosen API-Schlüssel von Fixer. Laut README lösen Sie eine Aktualisierung der Wechselkurse aus, indem Sie nach dem Eintragen des Schlüssels die Hauptwährung wechseln und anschließend wieder zurückstellen.

Diese Schritte sind ausdrücklich nur dokumentiert und wurden im Testlauf nicht durchgespielt. Ebenfalls nicht getestet wurden die Benachrichtigungswege über E-Mail, Discord, Telegram, Gotify, Pushover und Webhook, die KI-Empfehlungen sowie die Cronjobs im Container.

OIDC-Anmeldung über Umgebungsvariablen

Laut README lässt sich OIDC auf der Admin-Seite aktivieren und mit jedem Anbieter nutzen, der OAuth unterstützt. Interessant für automatisierte Installationen ist die deklarative Variante: Wallos kann OIDC-Einstellungen aus Umgebungsvariablen auflösen. Ist eine OIDC_-Variable gesetzt, überschreibt sie den Datenbankwert zur Laufzeit, ohne die Datenbank umzuschreiben. Ist OIDC_ISSUER gesetzt, ruft Wallos zur Laufzeit /.well-known/openid-configuration ab und nutzt Discovery für Authorization-, Token- und Userinfo-Endpunkt, sofern kein spezifischerer Endpunkt zusätzlich gesetzt ist.

Ein Beispiel mit Platzhaltern, das in eine .env neben der compose.yaml gehört. Tragen Sie hier niemals echte Geheimnisse in ein versioniertes Repository ein:

# .env neben der compose.yaml, Platzhalter durch eigene Werte ersetzen
OIDC_ISSUER=https://idp.example.com/realms/EXAMPLE
OIDC_CLIENT_ID=PLATZHALTER_CLIENT_ID
OIDC_CLIENT_SECRET=PLATZHALTER_CLIENT_SECRET

Die .env sollte nur dem Dienstbenutzer gehören und mit chmod 600 abgesichert sein. In der compose.yaml binden Sie sie über env_file: .env ein. Der OIDC-Betrieb wurde im Testlauf nicht geprüft.

Persistente Daten und Rechte

Im Test bestätigt: Nach dem ersten Start liegen im gemounteten Verzeichnis ./db zwei Dateien, nämlich wallos.db mit 200704 Bytes und setup_token.db mit 64 Bytes. Die Datenbank ist SQLite, ein separater Datenbankcontainer ist nicht nötig. Das ist der Grund für den geringen Ressourcenbedarf und macht Backups angenehm einfach.

Ebenfalls im Test bestätigt und in der Praxis wichtig: Die Dateien im Bind-Mount gehören der UID 82, also www-data im Alpine-Image, und nicht dem Host-Benutzer. Das hat zwei unmittelbare Folgen.

• Ein rm -rf auf das Stack-Verzeichnis als normaler Host-Benutzer scheitert mit Permission denied. Das ist kein Defekt, sondern die erwartete Folge fremder Dateieigentümer im Bind-Mount.
• Backup-Werkzeuge, die als unprivilegierter Host-Benutzer laufen, können die Datenbank unter Umständen nicht lesen. Prüfen Sie das, bevor Sie sich auf eine Sicherung verlassen.

So sehen Sie die tatsächlichen Eigentümer:

# Eigentuemer und Rechte im Datenbankverzeichnis anzeigen
ls -ln /opt/wallos/db

Wenn Sie als Host-Benutzer an die Dateien müssen, ist der saubere Weg ein Wegwerfcontainer, der die Arbeit mit passenden Rechten erledigt, statt die Rechte auf dem Host dauerhaft aufzuweichen:

# Dateien im Bind-Mount ueber einen Wegwerfcontainer bearbeiten
docker run --rm -v /opt/wallos:/host alpine sh -c 'ls -ln /host/db'

Sichere Netzwerkfreigabe und Reverse Proxy mit TLS

Wallos spricht im Container reines HTTP auf Port 80. Es bringt kein TLS mit und sollte niemals unverschlüsselt aus dem Internet erreichbar sein. Anmeldedaten würden dabei im Klartext übertragen. Es gilt die einfache Regel: entweder ausschließlich im internen Netz beziehungsweise über VPN, oder mit einem Reverse Proxy und einem gültigen Zertifikat davor.

Der praktische Ablauf sieht so aus:

• Den Port wie oben gezeigt an 127.0.0.1 binden, damit niemand die Anwendung am Proxy vorbei erreicht.
• Einen Reverse Proxy mit automatischem Zertifikat davorsetzen, etwa Caddy oder den Nginx Proxy Manager.
• Im Proxy HTTP auf HTTPS umleiten und moderne TLS-Voreinstellungen belassen.
• Die Header X-Forwarded-For und X-Forwarded-Proto durchreichen, damit die Anwendung das ursprüngliche Schema kennt.
• Die Registrierungsseite nach Anlage des ersten Kontos nicht offen ins Internet stellen, idealerweise über eine zusätzliche Zugriffsbeschränkung im Proxy.

Die vollständige Einrichtung eines Reverse Proxy mit Zertifikatsverwaltung ist ein eigenes Thema und hier nicht noch einmal ausgerollt. Der weiter unten verlinkte Bestandsartikel zum Nginx Proxy Manager zeigt den Weg im Detail. Der Reverse-Proxy-Betrieb von Wallos selbst wurde im Testlauf nicht geprüft.

Backup und Wiederherstellung

Weil die gesamte Anwendung aus einer SQLite-Datei und einem Logo-Verzeichnis besteht, ist die Sicherung unkompliziert. Es gibt zwei Wege, und beide wurden im Test angefasst.

Offline-Backup, der empfohlene Weg

Im Test bestätigt: Der Container wurde per docker compose stop angehalten, ein tar-Archiv über die Verzeichnisse db und logos erzeugt (Ergebnis 7413 Bytes) und der Stack danach per docker compose start wieder angefahren. Anschließend antwortete /login.php wieder mit HTTP 302, der Stack kam also nach Stop und Start sauber zurück.

# Container anhalten, damit keine Schreibzugriffe laufen
docker compose stop

# Datenbank und Logos in ein Archiv sichern
tar czf /var/backups/wallos-$(date +%F).tar.gz -C /opt/wallos db logos

# Container wieder starten
docker compose start

Der Stillstand dauert nur Sekunden und liefert einen garantiert konsistenten Stand. Für eine kleine Anwendung wie diese ist das der beste Kompromiss.

Online-Backup im laufenden Betrieb

Im Test bestätigt: Ein Backup im laufenden Betrieb per sqlite3 .backup hat funktioniert und erzeugte eine Datei mit 200704 Bytes. Dabei ist ein Detail wichtig, das ebenfalls im Test auffiel: sqlite3 ist im Image nicht vorinstalliert und musste per apk nachinstalliert werden. Eine Nachinstallation im laufenden Container ist beim nächsten Neustart wieder verschwunden. Wer regelmäßig online sichern will, sollte deshalb besser ein separates Wegwerfcontainer-Image mit sqlite3 auf denselben Mount zugreifen lassen.

# Konsistente Kopie der laufenden Datenbank ueber einen Wegwerfcontainer
docker run --rm -v /opt/wallos/db:/db alpine sh -c   'apk add --no-cache sqlite >/dev/null && sqlite3 /db/wallos.db ".backup /db/wallos-backup.db"'

Ein einfaches cp der laufenden Datenbankdatei ist ausdrücklich kein Backup. Es kann eine inkonsistente Kopie erzeugen, wenn währenddessen geschrieben wird.

Wiederherstellung

Die Wiederherstellung kehrt das Offline-Backup um. Wichtig ist die Reihenfolge: erst stoppen, dann austauschen, dann starten.

# Container anhalten
docker compose stop

# Alte Daten beiseite legen, statt sie sofort zu loeschen
mv /opt/wallos/db /opt/wallos/db.alt
mv /opt/wallos/logos /opt/wallos/logos.alt

# Sicherung entpacken
tar xzf /var/backups/wallos-2026-09-23.tar.gz -C /opt/wallos

# Container starten und Erreichbarkeit pruefen
docker compose start
curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8282/

Beachten Sie die Eigentümerrechte: Das Archiv sollte die ursprünglichen Eigentümer erhalten, sonst kann der Container die Datenbank nicht mehr schreiben. Entpacken Sie es deshalb als root beziehungsweise mit --same-owner. Eine echte Wiederherstellung aus dem tar-Archiv in eine frische Instanz wurde im Testlauf nicht durchgespielt, insofern beruht dieser Abschnitt auf dem allgemeinen Vorgehen und nicht auf einer eigenen Messung. Testen Sie Ihre Wiederherstellung deshalb einmal bewusst, bevor Sie sich im Ernstfall darauf verlassen.

Updates und Rollback-Grenzen

Ein Update mit Docker Compose besteht aus drei Befehlen:

# Neues Image herunterladen
docker compose pull

# Container mit dem neuen Image neu erzeugen
docker compose up -d

# Status und Healthcheck kontrollieren
docker compose ps

Entscheidend ist der Punkt davor: Erstellen Sie vor jedem Update ein Backup. Der Grund ist, dass Datenbankmigrationen beim Start ausgeführt werden. Wurde die SQLite-Datenbank einmal auf ein neueres Schema gehoben, ist ein Rückschritt auf ein älteres Image nicht ohne Weiteres möglich. Die alte Anwendungsversion erwartet das alte Schema und kann mit der migrierten Datenbank in der Regel nichts anfangen. Ein Rollback bedeutet in diesem Fall praktisch immer: altes Image plus eingespielte Sicherung aus der Zeit vor der Migration. Die Änderungen seit dem Backup sind dann verloren.

Daraus folgen drei Regeln für den Betrieb:

• Vor jedem docker compose pull ein Offline-Backup ziehen und aufbewahren, bis die neue Version eine Weile stabil läuft.
• Für Produktionsinstanzen einen festen Versions-Tag statt latest verwenden, damit ein unbeabsichtigter pull nicht zu einer Migration führt.
• Die Release-Notes vor dem Update lesen, insbesondere bei Sprüngen über mehrere Nebenversionen.

Ein Update auf eine neuere Version wurde im Testlauf nicht durchgeführt. Die Aussagen zur Migration folgen dem dokumentierten Verhalten des Projekts.

Cronjobs, der Hauptvorteil der Container-Variante

Wer Wallos ohne Container betreibt, muss laut README mehrere Cronjobs selbst einrichten, unter anderem updatenextpayment.php täglich um 01:00 Uhr, updateexchange.php täglich um 02:00 Uhr, sendnotifications.php täglich um 09:00 Uhr und checkforupdates.php alle sechs Stunden. Im Docker-Image laufen diese Aufgaben mit. Genau das ist der wesentliche praktische Vorteil der Container-Variante.

Ein Update bei Bare-Metal-Betrieb erfordert laut README zusätzlich, das Repository neu zu ziehen beziehungsweise git pull auszuführen, die Voraussetzungen zu prüfen und anschließend die Migration anzustoßen, entweder über den Aufruf von http://domain.example/endpoints/db/migrate.php im Browser oder auf der Kommandozeile mit php /var/www/html/endpoints/db/migrate.php. Der Schwerpunkt dieser Anleitung bleibt bewusst die Container-Variante.

Typische Fehler mit Diagnose und Lösung

• Der Aufruf der Startseite liefert 302 statt 200. Das ist kein Fehler. Im Test bestätigt: Wallos leitet nicht angemeldete Besucher auf /login.php um. Prüfen Sie mit curl -sL oder greifen Sie direkt auf /login.php zu.
• Der Port ist bereits belegt. Docker meldet beim Start, dass der Port bereits zugewiesen ist. Ermitteln Sie mit ss -tlnp | grep 8282, welcher Dienst ihn hält, und wählen Sie in der compose.yaml einen freien Host-Port. Im Testlauf war genau das der Fall, deshalb lief der Test auf Port 18282.
• Das Stack-Verzeichnis lässt sich nicht löschen. Im Test bestätigt: Die Dateien gehören UID 82, ein rm -rf als normaler Host-Benutzer scheitert mit Permission denied. Lösung: als root löschen oder einen Wegwerfcontainer verwenden, wie im Abschnitt zu den Rechten gezeigt.
• Der Healthcheck bleibt auf starting stehen. Laut README kann bei Docker-Versionen älter als 25 die Variante mit healthcheck: test: ["NONE"] helfen. Prüfen Sie zuerst mit docker compose logs, ob die Anwendung tatsächlich startet.
• Wechselkurse aktualisieren sich nicht. Laut README muss ein gültiger Fixer-API-Schlüssel hinterlegt sein. Eine Aktualisierung lösen Sie aus, indem Sie die Hauptwährung wechseln und wieder zurückstellen.
• Falsche Fälligkeitstermine oder verschobene Hintergrundaufgaben. Meist steht die Zeitzone noch auf dem Vorgabewert aus der offiziellen Vorlage. Setzen Sie TZ auf Europe/Berlin und erzeugen Sie den Container mit docker compose up -d neu.
• Nach einem Update funktioniert etwas nicht mehr und das alte Image startet nicht sauber. Ursache ist die bereits gelaufene Datenbankmigration. Der einzige verlässliche Weg zurück ist das Einspielen des Backups aus der Zeit vor dem Update.
• sqlite3 fehlt im Container. Im Test bestätigt: Das Werkzeug ist im Image nicht vorinstalliert. Nutzen Sie für Sicherungen einen Wegwerfcontainer statt einer Nachinstallation, die beim Neustart wieder verschwindet.

Saubere Deinstallation

Zum Entfernen des Stacks genügt ein Befehl im Stack-Verzeichnis:

# Container stoppen und entfernen, Daten im Bind-Mount bleiben erhalten
docker compose down

Warnung vor Datenverlust: Der Zusatz -v in docker compose down -v entfernt die zum Stack gehörenden Volumes. Führen Sie diesen Befehl nur aus, wenn Sie Ihre Daten wirklich dauerhaft loswerden wollen, und niemals ohne ein geprüftes Backup. Bei der hier gezeigten Konfiguration liegen die Daten zwar in Bind-Mounts und nicht in benannten Volumes, weshalb sie ein down -v überleben würden. Wer die compose.yaml jedoch auf benannte Volumes umgestellt hat, verliert mit diesem einen Zusatzzeichen die gesamte Abo-Historie ohne Rückfrage und ohne Wiederherstellungsmöglichkeit.

Das Image räumen Sie anschließend so ab:

# Nicht mehr benoetigtes Image entfernen
docker image rm bellamy/wallos:latest

Zuletzt die Datenverzeichnisse. Wegen der Eigentümerschaft durch UID 82 geht das als normaler Benutzer nicht, deshalb über einen Wegwerfcontainer:

# Datenverzeichnisse endgueltig entfernen, vorher Backup sichern
docker run --rm -v /opt:/host alpine sh -c 'rm -rf /host/wallos/db /host/wallos/logos'

Passende Anleitungen auf S-EDV

• Collabora Online mit Docker, Nextcloud und Nginx Proxy Manager zeigt die Einrichtung des Reverse Proxy mit Zertifikat, der auch vor Wallos gehört.
• Borgmatic im Docker-Container für automatische Server-Backups beschreibt, wie Sie die hier gezeigten Sicherungen automatisiert und versioniert ablegen.
• 2FAuth mit Docker Compose selbst hosten ist ein vergleichbar kleiner, selbst gehosteter Dienst und ein gutes Beispiel für den Umgang mit Anwendungsschlüsseln.

Quellen

• GitHub: ellite/Wallos, Repository mit README und Installationshinweisen
• GitHub: Wallos Releases und Versionshinweise
• Docker Hub: bellamy/wallos, offizielles Container-Image