Så self-hostar du Kanboard 2026: SQLite, plugins och säkra uppgraderingar

En misslyckad Kanboard-deployment kraschar inte alltid. Den kan visa en inloggningssida samtidigt som SQLite inte kan skriva eftersom den monterade datakatalogen har fel ägare. Börja i stället med en end-to-end-kontroll: byt ut standardinloggningen, skapa ett projekt och en uppgift, flytta den mellan kolumner, ladda upp en fil och testa en installerad plugin.

Den kontrollen motsvarar Kanboards dokumenterade syfte: en minimalistisk kanban-tavla med SQLite som backend. Den avslöjar också saknade beroenden, felaktiga antaganden om proxyn och ephemeral data tidigare än vad en uptime-kontroll kan göra.

Separera Kanboard från dess beroenden

Den minsta ansvarsfulla Kanboard-topologin består av en privat listener på port 80, en ingress-route och en dokumenterad state-gräns. Det lokala runtime-kravet är en skrivbar datavolym och valfri SMTP. Håll livscykeln explicit så att en flytt av Kanboard mellan servrar inte i tysthet ändrar beteendet.

Validera topologin genom att låta en ren klient byta ut standardinloggningen, skapa ett projekt och en uppgift, flytta den mellan kolumner, ladda upp en fil och testa en installerad plugin. Övervaka SQLite-låsning, volymen för bilagor, bakgrundsåtgärder och plugin-beteende under samtidiga användare medan den körs. Resultatet visar om nästa förbättring hör hemma i minne, lagring, nätverk eller en separat worker, i stället för att uppmuntra till godtycklig storlek på containern.

Domäner, proxy headers och port 80

TLS-utfärdande är bara halva Kanboard-routen. Servera tavlan över HTTPS och ange applikationens URL om plugins behöver den. Skicka trafik internt till port 80 och vidarebefordra det externa schemat så att genererade URL:er och säkra cookies förblir konsekventa.

Använd hela Kanboard-scenariot från ett rent nätverk, inte bara root-sidan. Ett 502-fel eller ett certifikatfel kan isoleras med automatisk domän- och TLS-konfiguration. Om trafiken når processen och SQLite inte kan skriva eftersom den monterade datakatalogen har fel ägare, felsök det där problemet uppstår i stället för att lägga på fler redirects.

Gör Kanboard-starten reproducerbar

En produktionslik start är avsiktligt odramatisk: namngiven state, explicit port och inga secrets i imagen.

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

Exemplet är en baseline, inte en komplett supporting stack. Bekräfta det lokala kravet innan exponering: en skrivbar datavolym och valfri SMTP. Kontrollera de aktiva mountsen och lyssnaren och försök sedan byta ut standardinloggningen, skapa ett projekt och en uppgift, flytta den mellan kolumner, ladda upp en fil och testa en installerad plugin. Pinna den fungerande imagen före nästa omstart.

Övervaka workloaden, inte bara containern

För Kanboard ska du övervaka en transaktion i stället för en process: byt ut standardinloggningen, skapa ett projekt och en uppgift, flytta den mellan kolumner, ladda upp en fil och testa en installerad plugin. Kombinera dess latency och error rate med SQLite-låsning, volymen för bilagor, bakgrundsåtgärder och plugin-beteende under samtidiga användare, så att en alert identifierar den komponent som är begränsad.

Uppgraderingsrepetitionen måste omfatta att databas-migreringar och plugin-kompatibilitet kräver en snapshot före en Kanboard image update. Återställ, migrera och kör transaktionen före bytet i produktion. Om SQLite inte kan skriva eftersom den monterade datakatalogen har fel ägare ska du inte radera data för att få en grön startup; jämför version, variabler, mounts och nåbarhet till beroenden i den ordningen.

Verifiera Kanboard-deploymenten end to end

En production gate för Kanboard ska kunna köras av någon som inte byggde deploymenten. Ge personen den pinnade versionen, ett icke-känsligt testkonto och följande uppgift: byt ut standardinloggningen, skapa ett projekt och en uppgift, flytta den mellan kolumner, ladda upp en fil och testa en installerad plugin. Om instruktionerna kräver odokumenterad shell-åtkomst är tjänsten ännu inte operativt redo.

Upprepa kontrollen efter att endast containern har bytts ut. Återställ sedan SQLite-databasen, uppladdade filer, plugins och konfiguration till en tom infrastruktur och verifiera att projekt, uppgiftshistorik, användare, bilagor och plugins kommer tillbaka och att den återställda tavlan kan ta emot en ny uppgift. Mät SQLite-låsning, volymen för bilagor, bakgrundsåtgärder och plugin-beteende under samtidiga användare under båda lyckade körningarna; oväntade skillnader avslöjar ofta en saknad cache, ett saknat index, en worker eller en datamount.

Lägg till en failure drill: skicka ofarlig indata nära resurs- eller formatgränsen som hör till den här gränsen: SQLite kan inte skriva eftersom den monterade datakatalogen har fel ägare. Kanboard ska logga ett användbart fel, bevara befintlig state och återhämta sig när det giltiga tillståndet återkommer. Spara tidsstämplar och relevanta loggrader, med secrets redigerade. Den bevisningen blir referens för nästa image- eller konfigurationsändring.

Volymer är bara det första återställningslagret

Skapa ett recovery-manifest för Kanboard: SQLite-databas, uppladdade filer, plugins och konfiguration. Montera /var/www/app/data före bootstrap, skriv ofarliga exempeldata och byt ut containern för att bevisa att sökvägen faktiskt är persistent. Kontrollera ägarskap och ledigt utrymme nu, eftersom en monterad men oskrivbar sökväg i praktiken beter sig som om ingen persistence fanns.

Säkerhetskopiera till en failure domain som är separerad från den körande servern. Återskapa Kanboard från den pinnade imagen och verifiera att projekt, uppgiftshistorik, användare, bilagor och plugins kommer tillbaka och att den återställda tavlan kan ta emot en ny uppgift. Guiden om persistent volumes hjälper dig att omsätta övningen i en policy för snapshots och retention.

Skydda den värdefulla delen av Kanboard

En säker Kanboard-deployment börjar med att minska behörigheterna. Undvik att behålla standarduppgifterna admin/admin; ta i stället bort admin/admin omedelbart, begränsa projektåtkomsten och granska plugins innan de får tillgång till produktionsdata.

Kanboard har ingen obligatorisk bootstrap-secret i denna baseline; skydda i stället det faktiska administratörskontot eller upstream-autentiseringen. Begränsa administrativa routes, använd privat DNS för beroenden och granska varje bind mount. När loggar skickas centralt ska secrets och privat innehåll filtreras innan de lämnar servern.

Där Dockup minskar arbetet för Kanboard

En Dockup-mall bör beskriva imagen, port 80, mounts, health timing, domän, TLS och secret delivery. Dockup bör bevara Kanboards runtime-inställningar medan operatören bekräftar det lokala kravet: en skrivbar datavolym och valfri SMTP. Samma deployment kan köras på Dockup-servrar eller på kapacitet som kunden ansluter.

När routen är aktiv tillämpar du den publika inställningen och försöker byta ut standardinloggningen, skapa ett projekt och en uppgift, flytta den mellan kolumner, ladda upp en fil och testa en installerad plugin. Säkerhetskopiera SQLite-databasen, uppladdade filer, plugins och konfiguration och behåll återställningsövningen i driftplanen; det här är Kanboards ansvar som fortfarande är synligt efter att infrastrukturen har provisionerats.

Vanliga frågor

Vad behöver Kanboard för en produktionsdeployment?

Routa Kanboard-containern på port 80 via en HTTPS-origin. Det lokala runtime-kravet är en skrivbar datavolym och valfri SMTP. Anse inte Kanboard vara redo förrän du kan byta ut standardinloggningen, skapa ett projekt och en uppgift, flytta den mellan kolumner, ladda upp en fil och testa en installerad plugin.

Vilka Kanboard-data ska ingå i en backup?

Persist /var/www/app/data och inkludera SQLite-databas, uppladdade filer, plugins och konfiguration i samma recovery-manifest. En ren Kanboard-återställning är klar först när projekt, uppgiftshistorik, användare, bilagor och plugins kommer tillbaka och den återställda tavlan kan ta emot en ny uppgift.

Kräver Kanboard HTTPS bakom en reverse proxy?

Använd HTTPS för den publika Kanboard-originen och behåll port 80 i den interna routen. Tillämpa Kanboard-inställningen korrekt: servera tavlan över HTTPS och ange applikationens URL om plugins behöver den. För Kanboard skyddar HTTPS credentials eller användarinnehåll under överföring och håller originskänsligt klientbeteende konsekvent.

Hur bör en Kanboard-uppgradering testas?

Återställ aktuell Kanboard-state till en isolerad deployment, tillämpa kandidatversionen och upprepa dess acceptance-transaktion. Var särskilt uppmärksam eftersom databas-migreringar och plugin-kompatibilitet kräver en snapshot före en Kanboard image update. Behåll den tidigare Kanboard-imagen tills gränserna för datamigrering och rollback är förstådda.