Kanboard zelf hosten in 2026: SQLite, plugins en veilige upgrades

Een mislukte Kanboard-deployment crasht niet altijd. De applicatie kan een loginpagina tonen terwijl SQLite niet kan schrijven omdat de gekoppelde datamap de verkeerde eigenaar heeft. Begin daarom met een end-to-end-controle: vervang de standaardlogin, maak een project en taak aan, verplaats de taak tussen kolommen, upload een bestand en gebruik een geïnstalleerde plugin.

Die controle sluit aan bij het gedocumenteerde doel van Kanboard: een minimalistisch kanbanbord dat door SQLite wordt ondersteund. Ook ontbrekende dependencies, verkeerde aannames over de proxy en vluchtige data komen hiermee eerder aan het licht dan met een uptime-probe.

Scheid Kanboard van zijn dependencies

De kleinste verantwoorde Kanboard-topologie bestaat uit één private listener op 80, een ingress-route en een gedocumenteerde scheiding van state. De lokale runtimevereiste is een schrijfbare datavolume en optioneel SMTP. Houd de lifecycle expliciet, zodat het verplaatsen van Kanboard tussen hosts niet ongemerkt het gedrag verandert.

Valideer de topologie door een schone client de standaardlogin te laten vervangen, een project en taak te laten aanmaken, de taak tussen kolommen te laten verplaatsen, een bestand te laten uploaden en een geïnstalleerde plugin te laten gebruiken. Controleer tijdens het uitvoeren SQLite-locking, het volume van bijlagen, background actions en het gedrag van plugins bij gelijktijdige gebruikers. Het resultaat laat zien of de volgende verbetering thuishoort in geheugen, opslag, networking of een aparte worker, in plaats van willekeurige containergrootte aan te moedigen.

Domeinen, proxyheaders en poort 80

Het uitgeven van TLS is slechts de helft van de Kanboard-route. Bied het bord aan via HTTPS en stel de applicatie-URL in als plugins die nodig hebben. Stuur verkeer intern naar 80 en geef het externe schema door, zodat gegenereerde URL's en secure cookies consistent blijven.

Gebruik het volledige Kanboard-scenario vanaf een schoon netwerk, niet alleen de rootpagina. Een 502- of certificaatfout kan worden geïsoleerd met automatische domein- en TLS-configuratie. Als het verkeer het proces bereikt en SQLite niet kan schrijven omdat de gekoppelde datamap de verkeerde eigenaar heeft, onderzoek die toestand op de plek waar die optreedt in plaats van redirects op elkaar te stapelen.

Maak het opstarten van Kanboard reproduceerbaar

Een production-shaped launch is bewust saai: benoemde state, een expliciete poort en geen secret in de 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

Het voorbeeld is een basisconfiguratie en geen complete supporting stack. Controleer de lokale vereiste voordat je Kanboard beschikbaar maakt: een schrijfbare datavolume en optioneel SMTP. Controleer de effectieve mounts en listener en probeer vervolgens de standaardlogin te vervangen, een project en taak aan te maken, de taak tussen kolommen te verplaatsen, een bestand te uploaden en een geïnstalleerde plugin te gebruiken. Pin de werkende image vóór de volgende restart.

Monitor de workload, niet alleen de container

Monitor voor Kanboard een transactie in plaats van een proces: vervang de standaardlogin, maak een project en taak aan, verplaats de taak tussen kolommen, upload een bestand en gebruik een geïnstalleerde plugin. Combineer de latency en error rate hiervan met SQLite-locking, het volume van bijlagen, background actions en het gedrag van plugins bij gelijktijdige gebruikers, zodat een alert de component met de beperking identificeert.

De upgrade-repetitie moet omvatten dat databasemigraties en plugincompatibiliteit een snapshot vóór een Kanboard-image-update vereisen. Herstel, migreer en voer de transactie uit voordat je de productieomgeving vervangt. Als SQLite niet kan schrijven omdat de gekoppelde datamap de verkeerde eigenaar heeft, wis dan geen data om de startup groen te maken; vergelijk versie, variabelen, mounts en bereikbaarheid van dependencies in die volgorde.

Bewijs de Kanboard-deployment end-to-end

Een production gate voor Kanboard moet uitvoerbaar zijn door iemand die de deployment niet heeft gebouwd. Geef die persoon de gepinde versie, een niet-gevoelig testaccount en deze taak: vervang de standaardlogin, maak een project en taak aan, verplaats de taak tussen kolommen, upload een bestand en gebruik een geïnstalleerde plugin. Als de instructies ongedocumenteerde shelltoegang vereisen, is de service operationeel nog niet klaar.

Herhaal de gate nadat je alleen de container hebt vervangen. Herstel vervolgens de SQLite-database, geüploade bestanden, plugins en configuratie in lege infrastructuur en bewijs dat projecten, taakgeschiedenis, gebruikers, bijlagen en plugins terugkomen en dat het herstelde bord een nieuwe taak accepteert. Meet tijdens beide geslaagde runs SQLite-locking, het volume van bijlagen, background actions en het gedrag van plugins bij gelijktijdige gebruikers; onverwachte verschillen wijzen vaak op een ontbrekende cache, index, worker of datamount.

Voeg een failure drill toe: dien onschadelijke invoer in die dicht bij de resource- of formaatslimiet ligt die bij deze grens hoort: SQLite kan niet schrijven omdat de gekoppelde datamap de verkeerde eigenaar heeft. Kanboard moet een bruikbare foutmelding geven, bestaande state behouden en herstellen zodra de geldige toestand terugkeert. Sla de tijdstempels en relevante logregels op, met secrets verwijderd. Dit bewijs wordt de referentie voor de volgende image- of configuratiewijziging.

Volumes zijn slechts de eerste herstellaag

Maak een recoverymanifest voor Kanboard: SQLite-database, geüploade bestanden, plugins en configuratie. Mount /var/www/app/data vóór de bootstrap, schrijf onschadelijke voorbeelddata en vervang de container om te bewijzen dat dit pad daadwerkelijk persistent is. Controleer nu het eigenaarschap en de beschikbare ruimte, want een gemount maar niet-schrijfbaar pad gedraagt zich alsof er helemaal geen persistentie is.

Maak back-ups naar een failure domain dat losstaat van de draaiende server. Recreate Kanboard vanuit de gepinde image en controleer of projecten, taakgeschiedenis, gebruikers, bijlagen en plugins terugkomen en of het herstelde bord een nieuwe taak accepteert. De handleiding voor persistente volumes helpt om deze oefening te vertalen naar een snapshot- en retentiebeleid.

Bescherm het waardevolle deel van Kanboard

Een veilige Kanboard-deployment begint met het beperken van bevoegdheden. Gebruik niet de standaardreferenties admin/admin; verwijder admin/admin in plaats daarvan onmiddellijk, beperk de projecttoegang en controleer plugins voordat je ze toegang geeft tot productiedata.

Kanboard heeft in deze basisconfiguratie geen verplichte bootstrap-secret; bescherm in plaats daarvan het daadwerkelijke administratoraccount of de upstream-authenticatie. Beperk administratieve routes, gebruik private DNS voor dependencies en controleer elke bind mount. Wanneer logs centraal worden verzameld, filter je secrets en private content voordat ze de server verlaten.

Waar Dockup werk voor Kanboard wegneemt

Een Dockup-template moet de image, poort 80, mounts, health timing, het domein, TLS en secret delivery vastleggen. Dockup moet de Kanboard-runtime-instellingen behouden terwijl de operator deze lokale vereiste controleert: een schrijfbare datavolume en optioneel SMTP. Dezelfde deployment kan gericht zijn op Dockup-servers of capaciteit die door de klant is gekoppeld.

Nadat de route actief is, pas je de publieke instelling toe en probeer je de standaardlogin te vervangen, een project en taak aan te maken, de taak tussen kolommen te verplaatsen, een bestand te uploaden en een geïnstalleerde plugin te gebruiken. Maak back-ups van de SQLite-database, geüploade bestanden, plugins en configuratie en neem de restore-oefening op in het operationele plan; dit zijn verantwoordelijkheden van Kanboard die zichtbaar blijven nadat de infrastructuur is ingericht.

Veelgestelde vragen

Wat heeft Kanboard nodig voor een production deployment?

Routeer de Kanboard-container op poort 80 via één HTTPS-origin. De lokale runtimevereiste is een schrijfbare datavolume en optioneel SMTP. Markeer Kanboard pas als klaar wanneer je de standaardlogin kunt vervangen, een project en taak kunt aanmaken, de taak tussen kolommen kunt verplaatsen, een bestand kunt uploaden en een geïnstalleerde plugin kunt gebruiken.

Welke Kanboard-data hoort in een back-up?

Maak /var/www/app/data persistent en neem de SQLite-database, geüploade bestanden, plugins en configuratie op in hetzelfde recoverymanifest. Een schone Kanboard-restore is alleen geslaagd wanneer projecten, taakgeschiedenis, gebruikers, bijlagen en plugins terugkomen en het herstelde bord een nieuwe taak accepteert.

Heeft Kanboard HTTPS nodig achter een reverse proxy?

Gebruik HTTPS voor de publieke Kanboard-origin en houd poort 80 op de interne route. Pas de Kanboard-instelling correct toe: bied het bord aan via HTTPS en stel de applicatie-URL in als plugins die nodig hebben. Voor Kanboard beschermt HTTPS credentials en gebruikerscontent tijdens transport en houdt het gedrag van clients dat gevoelig is voor de origin consistent.

Hoe moet je een Kanboard-upgrade testen?

Herstel de huidige Kanboard-state in een geïsoleerde deployment, pas de kandidaatversie toe en herhaal de acceptatietransactie. Let hier extra op, omdat databasemigraties en plugincompatibiliteit een snapshot vóór een Kanboard-image-update vereisen. Houd de vorige Kanboard-image beschikbaar totdat de grenzen voor datamigratie en rollback duidelijk zijn.