Come eseguire il self-hosting di Kanboard nel 2026: SQLite, plugin e aggiornamenti sicuri

Un deployment di Kanboard che non funziona non va necessariamente in crash. Potrebbe mostrare la pagina di login mentre SQLite non riesce a scrivere perché la directory dei dati montata ha il proprietario sbagliato. Inizia invece con un controllo end-to-end: sostituisci il login predefinito, crea un progetto e un task, spostalo tra le colonne, carica un file e verifica il funzionamento di un plugin installato.

Questo controllo corrisponde allo scopo documentato di Kanboard: una kanban board minimale basata su SQLite. Inoltre mette in evidenza prima di un semplice uptime probe le dipendenze mancanti, le assunzioni errate sul proxy e i dati effimeri.

Separa Kanboard dalle sue dipendenze

La topologia Kanboard più piccola ma responsabile comprende un listener privato sulla porta 80, una route di ingresso e un confine di stato documentato. Il requisito del runtime locale è un volume dati scrivibile e, facoltativamente, SMTP. Mantieni esplicito il suo ciclo di vita, così spostare Kanboard tra host non ne modifica il comportamento senza preavviso.

Convalida la topologia chiedendo a un client pulito di sostituire il login predefinito, creare un progetto e un task, spostarlo tra le colonne, caricare un file e verificare il funzionamento di un plugin installato. Durante l'esecuzione, monitora i lock di SQLite, il volume degli allegati, le azioni in background e il comportamento dei plugin con utenti simultanei. Il risultato indica se il prossimo miglioramento riguarda memoria, storage, networking o un worker separato, invece di incoraggiare un dimensionamento arbitrario del container.

Domini, header del proxy e porta 80

L'emissione del certificato TLS è solo metà del percorso di Kanboard. Servi la board tramite HTTPS e imposta l'URL dell'applicazione se i plugin ne hanno bisogno. Inoltra internamente il traffico verso la porta 80 e trasferisci lo schema esterno, così gli URL generati e i cookie sicuri restano coerenti.

Usa lo scenario Kanboard completo da una rete pulita, non solo la pagina principale. Un errore 502 o un problema con il certificato possono essere isolati con la configurazione automatica del dominio e di TLS. Se il traffico raggiunge il processo e SQLite non riesce a scrivere perché la directory dei dati montata ha il proprietario sbagliato, diagnostica la condizione nel punto in cui si verifica invece di aggiungere altri redirect.

Rendi riproducibile l'avvio di Kanboard

Un avvio strutturato per la produzione è volutamente ordinario: stato denominato, porta esplicita e nessun secret dentro l'immagine.

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

L'esempio è una base di partenza, non uno stack di supporto completo. Conferma il requisito locale prima dell'esposizione: un volume dati scrivibile e, facoltativamente, SMTP. Controlla i mount effettivi e il listener, poi prova a sostituire il login predefinito, creare un progetto e un task, spostarlo tra le colonne, caricare un file e verificare il funzionamento di un plugin installato. Fissa l'immagine funzionante prima del riavvio successivo.

Monitora il carico di lavoro, non solo il container

Per Kanboard, monitora una transazione anziché un processo: sostituisci il login predefinito, crea un progetto e un task, spostalo tra le colonne, carica un file e verifica il funzionamento di un plugin installato. Combina latenza e tasso di errore con i lock di SQLite, il volume degli allegati, le azioni in background e il comportamento dei plugin con utenti simultanei, così un alert identifica il componente sotto pressione.

La prova di aggiornamento deve tenere conto del fatto che le migrazioni del database e la compatibilità dei plugin richiedono uno snapshot prima di aggiornare l'immagine di Kanboard. Esegui il restore, la migrazione e la transazione prima della sostituzione in produzione. Se SQLite non riesce a scrivere perché la directory dei dati montata ha il proprietario sbagliato, non cancellare i dati per rendere l'avvio verde; confronta in quest'ordine versione, variabili, mount e raggiungibilità delle dipendenze.

Dimostra il deployment di Kanboard end-to-end

Un gate di produzione per Kanboard deve poter essere eseguito da chi non ha realizzato il deployment. Fornisci a quella persona la versione fissata, un account di test non sensibile e questo task: sostituire il login predefinito, creare un progetto e un task, spostarlo tra le colonne, caricare un file e verificare il funzionamento di un plugin installato. Se le istruzioni richiedono un accesso shell non documentato, il servizio non è ancora pronto dal punto di vista operativo.

Ripeti il gate dopo aver sostituito solo il container. Poi ripristina il database SQLite, i file caricati, i plugin e la configurazione su un'infrastruttura vuota e dimostra che progetti, cronologia dei task, utenti, allegati e plugin sono tornati disponibili e che la board ripristinata accetta un nuovo task. Durante entrambe le esecuzioni riuscite, misura i lock di SQLite, il volume degli allegati, le azioni in background e il comportamento dei plugin con utenti simultanei; differenze inattese rivelano spesso una cache, un indice, un worker o un mount dati mancanti.

Aggiungi una simulazione di errore: invia un input innocuo vicino al limite di risorse o di formato associato a questo confine: SQLite non riesce a scrivere perché la directory dei dati montata ha il proprietario sbagliato. Kanboard dovrebbe produrre un errore utile, preservare lo stato esistente e ripristinarsi quando la condizione valida torna a essere presente. Salva i timestamp e le righe di log rilevanti, oscurando i secret. Questa evidenza diventa il riferimento per la successiva modifica dell'immagine o della configurazione.

I volumi sono solo il primo livello di ripristino

Crea un manifest di ripristino per Kanboard: database SQLite, file caricati, plugin e configurazione. Monta /var/www/app/data prima del bootstrap, scrivi dati di esempio innocui e sostituisci il container per dimostrare che quel percorso è realmente persistente. Controlla subito il proprietario e lo spazio libero, perché un percorso montato ma non scrivibile si comporta di fatto come se non ci fosse alcuna persistenza.

Esegui il backup in un failure domain separato dal server in esecuzione. Ricrea Kanboard dalla sua immagine fissata e verifica che progetti, cronologia dei task, utenti, allegati e plugin siano tornati disponibili e che la board ripristinata accetti un nuovo task. La guida ai volumi persistenti aiuta a trasformare questa esercitazione in una policy di snapshot e retention.

Proteggi la parte preziosa di Kanboard

Un deployment sicuro di Kanboard inizia dalla riduzione delle autorizzazioni. Evita di mantenere le credenziali admin/admin predefinite; rimuovi invece subito admin/admin, limita l'accesso ai progetti e verifica i plugin prima di concedere loro accesso ai dati di produzione.

In questa configurazione di base Kanboard non richiede un secret di bootstrap obbligatorio; proteggi invece il suo account amministratore effettivo o l'autenticazione upstream. Limita le route amministrative, usa DNS privato per le dipendenze e verifica ogni bind mount. Quando i log vengono inviati centralmente, filtra secret e contenuti privati prima che lascino il server.

Dove Dockup riduce il lavoro per Kanboard

Un template Dockup dovrebbe includere immagine, porta 80, mount, tempistiche degli health check, dominio, TLS e distribuzione dei secret. Dockup dovrebbe conservare le impostazioni del runtime di Kanboard mentre l'operatore conferma questo requisito locale: un volume dati scrivibile e, facoltativamente, SMTP. Lo stesso deployment può essere destinato ai server Dockup o a capacità collegata dal cliente.

Dopo che la route è attiva, applica l'impostazione pubblica e prova a sostituire il login predefinito, creare un progetto e un task, spostarlo tra le colonne, caricare un file e verificare il funzionamento di un plugin installato. Esegui il backup del database SQLite, dei file caricati, dei plugin e della configurazione e mantieni l'esercitazione di ripristino nel piano operativo; queste sono responsabilità di Kanboard che restano visibili anche dopo il provisioning dell'infrastruttura.

Domande frequenti

Di cosa ha bisogno Kanboard per un deployment in produzione?

Instrada il container Kanboard sulla porta 80 attraverso un'unica origine HTTPS. Il requisito del runtime locale è un volume dati scrivibile e, facoltativamente, SMTP. Non considerare Kanboard pronto finché non puoi sostituire il login predefinito, creare un progetto e un task, spostarlo tra le colonne, caricare un file e verificare il funzionamento di un plugin installato.

Quali dati di Kanboard devono essere inclusi in un backup?

Rendi persistente /var/www/app/data e includi database SQLite, file caricati, plugin e configurazione nello stesso manifest di ripristino. Un restore pulito di Kanboard ha esito positivo solo quando progetti, cronologia dei task, utenti, allegati e plugin sono tornati disponibili e la board ripristinata accetta un nuovo task.

Kanboard richiede HTTPS dietro un reverse proxy?

Usa HTTPS per l'origine pubblica di Kanboard e mantieni la porta 80 nella route interna. Applica correttamente l'impostazione di Kanboard: servi la board tramite HTTPS e imposta l'URL dell'applicazione se i plugin ne hanno bisogno. Per Kanboard, HTTPS protegge le credenziali o i contenuti degli utenti durante il transito e mantiene coerente il comportamento del client sensibile all'origine.

Come si deve testare un aggiornamento di Kanboard?

Ripristina lo stato corrente di Kanboard in un deployment isolato, applica la versione candidata e ripeti la relativa transazione di accettazione. Presta particolare attenzione al fatto che le migrazioni del database e la compatibilità dei plugin richiedono uno snapshot prima di aggiornare l'immagine di Kanboard. Mantieni l'immagine precedente di Kanboard finché non avrai compreso i limiti della migrazione dei dati e del rollback.