Sådan selvhoster du Kanboard i 2026: SQLite, plugins og sikre opgraderinger

En fejlslagen Kanboard-deployment går ikke altid ned. Den kan godt vise en login-side, mens SQLite ikke kan skrive, fordi den mountede data-mappe har den forkerte ejer. Start i stedet med en end-to-end-check: Erstat standardloginet, opret et projekt og en opgave, flyt den på tværs af kolonner, upload en fil, og afprøv ét installeret plugin.

Det matcher Kanboards registrerede formål: et minimalistisk kanban-board baseret på SQLite. Det afslører også manglende dependencies, forkerte antagelser om proxyen og ephemeral data tidligere, end en uptime-probe kan.

Adskil Kanboard fra dets dependencies

Den mindste ansvarlige Kanboard-topologi består af én privat listener på port 80, en ingress-route og en dokumenteret state-grænse. Det lokale runtime-krav er en skrivbar datavolume og valgfri SMTP. Gør livscyklussen eksplicit, så flytning af Kanboard mellem hosts ikke ændrer funktionaliteten ubemærket.

Validér topologien ved at bede en ren klient om at erstatte standardloginet, oprette et projekt og en opgave, flytte den på tværs af kolonner, uploade en fil og afprøve ét installeret plugin. Hold øje med SQLite-locking, attachment-volume, background actions og plugin-adfærd under samtidige brugere, mens det kører. Resultatet viser, om den næste forbedring hører hjemme i memory, storage, networking eller en separat worker, i stedet for at opfordre til tilfældig containersizing.

Domæner, proxy-headers og port 80

TLS-udstedelse er kun halvdelen af Kanboard-routen. Servér boardet over HTTPS, og angiv application URL, hvis plugins har brug for den. Send trafikken internt til port 80, og videresend den eksterne scheme, så genererede URL'er og secure cookies forbliver konsistente.

Brug det komplette Kanboard-scenarie fra et rent netværk, ikke kun root-siden. En 502- eller certifikatfejl kan isoleres med automatisk domæne- og TLS-opsætning. Hvis trafikken når processen, og SQLite ikke kan skrive, fordi den mountede data-mappe har den forkerte ejer, skal du diagnosticere forholdet dér, hvor det opstår, i stedet for at stable redirects oven på hinanden.

Gør Kanboard-start reproducerbar

En produktionslignende launch er med vilje kedelig: navngiven state, eksplicit port og ingen secret inde i imaget.

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

Eksemplet er et udgangspunkt og ikke en komplet supporting stack. Bekræft det lokale krav, før du eksponerer servicen: en skrivbar datavolume og valgfri SMTP. Kontrollér de effektive mounts og listeneren, og prøv derefter at erstatte standardloginet, oprette et projekt og en opgave, flytte den på tværs af kolonner, uploade en fil og afprøve ét installeret plugin. Pin det fungerende image før næste restart.

Overvåg workloaden, ikke kun containeren

For Kanboard skal du overvåge en transaction i stedet for en proces: Erstat standardloginet, opret et projekt og en opgave, flyt den på tværs af kolonner, upload en fil, og afprøv ét installeret plugin. Kombinér dens latency og error rate med SQLite-locking, attachment-volume, background actions og plugin-adfærd under samtidige brugere, så en alert identificerer den komponent, der er under pres.

Upgrade-rehearsalen skal dække, at databasemigreringer og plugin-kompatibilitet kræver et snapshot før en Kanboard image-opdatering. Restore, migrér, og kør transactionen før udskiftning i produktion. Hvis SQLite ikke kan skrive, fordi den mountede data-mappe har den forkerte ejer, skal du ikke slette data for at få en grøn startup; sammenlign version, variabler, mounts og dependency reachability i den rækkefølge.

Bevis Kanboard-deploymenten end-to-end

En produktionsgate for Kanboard skal kunne udføres af en person, der ikke har bygget deploymenten. Giv personen den pinnede version, en ikke-sensitiv testkonto og denne opgave: Erstat standardloginet, opret et projekt og en opgave, flyt den på tværs af kolonner, upload en fil, og afprøv ét installeret plugin. Hvis instruktionerne kræver udokumenteret shell-adgang, er servicen endnu ikke driftsklar.

Gentag gaten efter kun at have udskiftet containeren. Gendan derefter SQLite-database, uploadede filer, plugins og konfiguration i blank infrastruktur, og bevis, at projekter, opgavehistorik, brugere, attachments og plugins kommer tilbage, og at det gendannede board accepterer en ny opgave. Mål SQLite-locking, attachment-volume, background actions og plugin-adfærd under samtidige brugere under begge vellykkede kørsler; uventede forskelle afslører ofte en manglende cache, et manglende index, en worker eller et data-mount.

Tilføj en failure drill: Indsend harmløst input tæt på den ressource- eller formatgrænse, der er knyttet til denne grænse: SQLite kan ikke skrive, fordi den mountede data-mappe har den forkerte ejer. Kanboard skal vise en nyttig fejl, bevare eksisterende state og komme sig, når den gyldige tilstand vender tilbage. Gem tidsstemplerne og de relevante loglinjer med secrets redacted. Det bevis bliver referencepunktet for det næste image eller den næste konfigurationsændring.

Volumes er kun det første recovery-lag

Lav et recovery-manifest for Kanboard: SQLite-database, uploadede filer, plugins og konfiguration. Mount /var/www/app/data før bootstrap, skriv harmløse eksempeldata, og udskift containeren for at bevise, at stien faktisk er persistent. Kontrollér ejerskab og ledig plads nu, fordi en mountet, men ikke-skrivbar sti i praksis opfører sig som om der slet ikke var persistence.

Tag backup til et failure domain, der er adskilt fra den kørende server. Genskab Kanboard fra det pinnede image, og kontrollér, at projekter, opgavehistorik, brugere, attachments og plugins kommer tilbage, og at det gendannede board accepterer en ny opgave. Guiden til persistent volumes hjælper med at omsætte øvelsen til en snapshot- og retention-policy.

Beskyt den værdifulde del af Kanboard

En sikker Kanboard-deployment begynder med at fjerne authority. Undgå at beholde standardcredentials admin/admin; fjern i stedet admin/admin med det samme, begræns projektadgang, og gennemgå plugins, før de får adgang til produktionsdata.

Kanboard har ingen obligatorisk bootstrap-secret i denne baseline; beskyt i stedet den faktiske administratorkonto eller upstream authentication. Begræns administrative routes, brug private DNS-navne til dependencies, og gennemgå hvert bind mount. Når logs sendes centralt, skal du filtrere secrets og privat indhold, før de forlader serveren.

Sådan fjerner Dockup arbejde for Kanboard

En Dockup-template bør indeholde image, port 80, mounts, health timing, domæne, TLS og secret delivery. Dockup bør bevare Kanboards runtime-indstillinger, mens operatøren bekræfter dette lokale krav: en skrivbar datavolume og valgfri SMTP. Den samme deployment kan målrettes Dockup-servere eller kundetilknyttet kapacitet.

Når routen er live, skal du anvende den offentlige indstilling og prøve at erstatte standardloginet, oprette et projekt og en opgave, flytte den på tværs af kolonner, uploade en fil og afprøve ét installeret plugin. Tag backup af SQLite-database, uploadede filer, plugins og konfiguration, og behold restore-øvelsen i driftsplanen; det er Kanboard-ansvar, som stadig er synligt efter infrastrukturprovisionering.

Ofte stillede spørgsmål

Hvad kræver Kanboard til en produktionsdeployment?

Route Kanboard-containeren via port 80 gennem én HTTPS-origin. Det lokale runtime-krav er en skrivbar datavolume og valgfri SMTP. Erklær ikke Kanboard klar, før du kan erstatte standardloginet, oprette et projekt og en opgave, flytte den på tværs af kolonner, uploade en fil og afprøve ét installeret plugin.

Hvilke Kanboard-data hører hjemme i en backup?

Gør /var/www/app/data persistent, og inkludér SQLite-database, uploadede filer, plugins og konfiguration i det samme recovery-manifest. En ren Kanboard-restore er først godkendt, når projekter, opgavehistorik, brugere, attachments og plugins kommer tilbage, og det gendannede board accepterer en ny opgave.

Kræver Kanboard HTTPS bag en reverse proxy?

Brug HTTPS til den offentlige Kanboard-origin, og behold port 80 på den interne route. Anvend Kanboard-indstillingen korrekt: Servér boardet over HTTPS, og angiv application URL, hvis plugins har brug for den. For Kanboard beskytter HTTPS credentials eller brugerindhold under transport og sikrer, at origin-følsom klientadfærd forbliver konsistent.

Hvordan bør en Kanboard-opgradering testes?

Gendan den aktuelle Kanboard-state i en isoleret deployment, anvend kandidatversionen, og gentag dens acceptance transaction. Vær særligt opmærksom, fordi databasemigreringer og plugin-kompatibilitet kræver et snapshot før en Kanboard image-opdatering. Behold det tidligere Kanboard-image, indtil dets datamigrations- og rollback-grænse er forstået.