Kanboard 2026 selbst hosten: SQLite, Plugins und sichere Upgrades

Ein fehlgeschlagenes Kanboard-Deployment stürzt nicht immer ab. Es kann eine Login-Seite ausliefern, während SQLite nicht schreiben kann, weil das gemountete Datenverzeichnis den falschen Owner hat. Beginne stattdessen mit einer End-to-End-Prüfung: Ersetze den Standard-Login, erstelle ein Projekt und eine Aufgabe, verschiebe sie durch die Spalten, lade eine Datei hoch und führe ein installiertes Plugin aus.

Diese Prüfung entspricht dem dokumentierten Zweck von Kanboard: ein minimales Kanban-Board auf Basis von SQLite. Außerdem macht sie fehlende Abhängigkeiten, falsche Proxy-Annahmen und flüchtige Daten früher sichtbar als ein einfacher Uptime-Check.

Kanboard von seinen Abhängigkeiten trennen

Die kleinste verantwortbare Kanboard-Topologie umfasst einen privaten Listener auf Port 80, eine Ingress-Route und eine dokumentierte State-Grenze. Die lokale Runtime-Anforderung ist ein beschreibbares Daten-Volume sowie optional SMTP. Halte den Lifecycle explizit, damit ein Verschieben von Kanboard zwischen Hosts das Verhalten nicht unbemerkt verändert.

Validiere die Topologie, indem du einen sauberen Client den Standard-Login ersetzen, ein Projekt und eine Aufgabe erstellen, sie durch die Spalten verschieben, eine Datei hochladen und ein installiertes Plugin ausführen lässt. Beobachte währenddessen SQLite-Locking, das Attachment-Volume, Hintergrundaktionen und das Plugin-Verhalten bei gleichzeitiger Nutzung. Das Ergebnis zeigt dir, ob die nächste Verbesserung in Memory, Storage, Networking oder einem separaten Worker erforderlich ist, statt zu einer beliebigen Dimensionierung des Containers zu verleiten.

Domains, Proxy-Header und Port 80

Die Ausstellung von TLS-Zertifikaten ist nur die Hälfte der Kanboard-Route. Stelle das Board über HTTPS bereit und setze die Application-URL, wenn Plugins sie benötigen. Leite den Traffic intern an Port 80 weiter und übermittle das externe Schema, damit generierte URLs und Secure Cookies konsistent bleiben.

Verwende das vollständige Kanboard-Szenario aus einem sauberen Netzwerk und nicht nur die Root-Seite. Einen 502- oder Zertifikatsfehler kannst du mit automatischer Domain- und TLS-Einrichtung isolieren. Wenn der Traffic den Prozess erreicht und SQLite nicht schreiben kann, weil das gemountete Datenverzeichnis den falschen Owner hat, diagnostiziere diese Bedingung dort, wo sie auftritt, statt weitere Redirects darüberzulegen.

Den Kanboard-Start reproduzierbar machen

Ein produktionsnaher Start ist bewusst unspektakulär: benannter State, expliziter Port und kein Secret im Image.

docker run -d \
  --name kanboard \
  --restart unless-stopped \
  -p 127.0.0.1:80:80 \
  -v kanboard-data:/var/www/app/data \
  kanboard/kanboard:latest

Das Beispiel ist eine Ausgangsbasis und kein vollständiger Supporting Stack. Bestätige vor der Veröffentlichung die lokale Anforderung: ein beschreibbares Daten-Volume sowie optional SMTP. Prüfe die tatsächlich verwendeten Mounts und den Listener. Versuche anschließend, den Standard-Login zu ersetzen, ein Projekt und eine Aufgabe zu erstellen, sie durch die Spalten zu verschieben, eine Datei hochzuladen und ein installiertes Plugin auszuführen. Pinne das funktionierende Image vor dem nächsten Neustart.

Die Workload beobachten, nicht nur den Container

Überwache bei Kanboard eine Transaktion statt nur eines Prozesses: Ersetze den Standard-Login, erstelle ein Projekt und eine Aufgabe, verschiebe sie durch die Spalten, lade eine Datei hoch und führe ein installiertes Plugin aus. Kombiniere Latenz und Fehlerrate mit SQLite-Locking, dem Attachment-Volume, Hintergrundaktionen und dem Plugin-Verhalten bei gleichzeitiger Nutzung, damit ein Alert die betroffene Komponente identifiziert.

Die Upgrade-Generalprobe muss berücksichtigen, dass Datenbankmigrationen und Plugin-Kompatibilität vor einem Kanboard-Image-Update einen Snapshot erfordern. Stelle den Snapshot wieder her, führe die Migration durch und starte die Transaktion vor dem Austausch in der Produktion. Wenn SQLite nicht schreiben kann, weil das gemountete Datenverzeichnis den falschen Owner hat, lösche keine Daten, nur damit der Start grün wird. Vergleiche Version, Variablen, Mounts und die Erreichbarkeit der Abhängigkeiten in dieser Reihenfolge.

Das Kanboard-Deployment End-to-End prüfen

Ein Production Gate für Kanboard sollte von jemandem ausführbar sein, der das Deployment nicht erstellt hat. Gib dieser Person die gepinnte Version, einen nicht sensiblen Test-Account und diese Aufgabe: den Standard-Login ersetzen, ein Projekt und eine Aufgabe erstellen, sie durch die Spalten verschieben, eine Datei hochladen und ein installiertes Plugin ausführen. Wenn die Anleitung undokumentierten Shell-Zugriff erfordert, ist der Service operativ noch nicht bereit.

Wiederhole das Gate, nachdem du nur den Container ersetzt hast. Stelle anschließend die SQLite-Datenbank, hochgeladene Dateien, Plugins und Konfiguration in einer leeren Infrastruktur wieder her und beweise, dass Projekte, Aufgabenhistorie, Benutzer, Attachments und Plugins zurückkehren und das wiederhergestellte Board eine neue Aufgabe akzeptiert. Miss SQLite-Locking, das Attachment-Volume, Hintergrundaktionen und das Plugin-Verhalten bei gleichzeitiger Nutzung während beider erfolgreichen Durchläufe. Unerwartete Unterschiede weisen oft auf einen fehlenden Cache, Index, Worker oder Daten-Mount hin.

Füge eine Failure Drill hinzu: Übermittle harmlose Eingaben nahe dem Ressourcen- oder Formatlimit, das mit dieser Grenze verbunden ist: SQLite kann nicht schreiben, weil das gemountete Datenverzeichnis den falschen Owner hat. Kanboard sollte einen hilfreichen Fehler ausgeben, den bestehenden State bewahren und sich erholen, sobald die gültige Bedingung wiederhergestellt ist. Speichere Zeitstempel und relevante Log-Zeilen, wobei Secrets redigiert werden. Diese Belege dienen als Referenz für das nächste Image- oder Konfigurations-Update.

Volumes sind nur die erste Recovery-Schicht

Erstelle ein Recovery-Manifest für Kanboard: SQLite-Datenbank, hochgeladene Dateien, Plugins und Konfiguration. Mounte /var/www/app/data vor dem Bootstrap, schreibe harmlose Beispieldaten und ersetze den Container, um zu beweisen, dass dieser Pfad tatsächlich persistent ist. Prüfe jetzt Ownership und freien Speicherplatz, denn ein gemounteter, aber nicht beschreibbarer Pfad verhält sich überhaupt nicht persistent.

Sichere in eine Failure Domain, die vom laufenden Server getrennt ist. Erstelle Kanboard aus seinem gepinnten Image neu und überprüfe, dass Projekte, Aufgabenhistorie, Benutzer, Attachments und Plugins zurückkehren und das wiederhergestellte Board eine neue Aufgabe akzeptiert. Der Leitfaden zu persistenten Volumes hilft dabei, diese Übung in eine Snapshot- und Retention-Policy zu überführen.

Den wertvollen Teil von Kanboard schützen

Ein sicheres Kanboard-Deployment beginnt damit, Berechtigungen zu entziehen. Vermeide es, die Standard-Credentials admin/admin beizubehalten. Entferne admin/admin stattdessen sofort, beschränke den Projektzugriff und prüfe Plugins, bevor du ihnen Zugriff auf Produktionsdaten gewährst.

Kanboard benötigt in dieser Baseline kein verpflichtendes Bootstrap-Secret. Schütze stattdessen das tatsächliche Administrator-Konto oder die vorgelagerte Authentifizierung. Beschränke administrative Routen, verwende private DNS für Abhängigkeiten und prüfe jeden Bind-Mount. Wenn Logs zentral ausgeliefert werden, filtere Secrets und private Inhalte, bevor sie den Server verlassen.

Wo Dockup Arbeit für Kanboard abnimmt

Ein Dockup-Template sollte Image, Port 80, Mounts, Health-Timing, Domain, TLS und Secret-Übermittlung abbilden. Dockup sollte die Kanboard-Runtime-Einstellungen beibehalten, während der Operator diese lokale Anforderung bestätigt: ein beschreibbares Daten-Volume sowie optional SMTP. Dasselbe Deployment kann auf Dockup-Server oder an Kunden angebundene Kapazität zielen.

Nachdem die Route aktiv ist, wende die öffentliche Einstellung an und versuche, den Standard-Login zu ersetzen, ein Projekt und eine Aufgabe zu erstellen, sie durch die Spalten zu verschieben, eine Datei hochzuladen und ein installiertes Plugin auszuführen. Sichere die SQLite-Datenbank, hochgeladene Dateien, Plugins und Konfiguration und behalte die Restore-Übung im Betriebsplan. Diese Aufgaben gehören zu den Verantwortlichkeiten von Kanboard und bleiben auch nach der Bereitstellung der Infrastruktur sichtbar.

Häufig gestellte Fragen

Was benötigt Kanboard für ein Deployment in der Produktion?

Leite den Kanboard-Container über einen HTTPS-Origin auf Port 80. Die lokale Runtime-Anforderung ist ein beschreibbares Daten-Volume sowie optional SMTP. Erkläre Kanboard erst dann für bereit, wenn du den Standard-Login ersetzen, ein Projekt und eine Aufgabe erstellen, sie durch die Spalten verschieben, eine Datei hochladen und ein installiertes Plugin ausführen kannst.

Welche Kanboard-Daten gehören in ein Backup?

Persistiere /var/www/app/data und nimm die SQLite-Datenbank, hochgeladene Dateien, Plugins und Konfiguration in dasselbe Recovery-Manifest auf. Ein sauberer Kanboard-Restore ist nur dann erfolgreich, wenn Projekte, Aufgabenhistorie, Benutzer, Attachments und Plugins zurückkehren und das wiederhergestellte Board eine neue Aufgabe akzeptiert.

Benötigt Kanboard hinter einem Reverse Proxy HTTPS?

Verwende HTTPS für den öffentlichen Kanboard-Origin und behalte Port 80 in der internen Route bei. Setze die Kanboard-Einstellung korrekt: Stelle das Board über HTTPS bereit und setze die Application-URL, wenn Plugins sie benötigen. Bei Kanboard schützt HTTPS Credentials oder Benutzerinhalte bei der Übertragung und sorgt für ein konsistentes, vom Origin abhängiges Client-Verhalten.

Wie sollte ein Kanboard-Upgrade getestet werden?

Stelle den aktuellen Kanboard-State in einem isolierten Deployment wieder her, wende die Kandidatenversion an und wiederhole die Akzeptanztransaktion. Achte besonders darauf, dass Datenbankmigrationen und Plugin-Kompatibilität vor einem Kanboard-Image-Update einen Snapshot erfordern. Behalte das vorherige Kanboard-Image, bis die Grenzen der Datenmigration und des Rollbacks verstanden sind.