Comment auto-héberger Kanboard en 2026 : SQLite, plugins et mises à niveau sûres

Un déploiement Kanboard défaillant ne plante pas toujours. Il peut afficher une page de connexion alors que SQLite ne peut pas écrire, parce que le répertoire de données monté appartient au mauvais utilisateur. Commencez plutôt par une vérification de bout en bout : remplacez les identifiants par défaut, créez un projet et une tâche, déplacez-la entre les colonnes, importez un fichier et testez l’un des plugins installés.

Cette vérification correspond à la vocation répertoriée de Kanboard : un tableau kanban minimal basé sur SQLite. Elle révèle également plus tôt les dépendances manquantes, les hypothèses erronées sur le proxy et les données éphémères qu’un simple probe de disponibilité ne permettrait pas de détecter.

Séparer Kanboard de ses dépendances

La topologie Kanboard la plus réduite qui reste responsable comprend un seul listener privé sur le port 80, une route d’ingress et une limite d’état documentée. L’exigence du runtime local est un volume de données accessible en écriture et, en option, un serveur SMTP. Explicitez son cycle de vie afin que le déplacement de Kanboard entre plusieurs hôtes ne modifie pas son comportement sans que vous le sachiez.

Validez la topologie en demandant à un client vierge de remplacer les identifiants par défaut, de créer un projet et une tâche, de la déplacer entre les colonnes, d’importer un fichier et de tester l’un des plugins installés. Pendant l’exécution, surveillez les verrous SQLite, le volume des pièces jointes, les actions en arrière-plan et le comportement des plugins avec plusieurs utilisateurs simultanés. Le résultat vous indique si la prochaine amélioration concerne la mémoire, le stockage, le réseau ou un worker séparé, plutôt que de vous pousser à dimensionner arbitrairement le conteneur.

Domaines, en-têtes du proxy et port 80

L’émission du TLS ne représente que la moitié du routage de Kanboard. Servez le tableau via HTTPS et définissez l’URL de l’application si les plugins en ont besoin. Acheminez le trafic en interne vers le port 80 et transmettez le schéma externe afin que les URL générées et les cookies sécurisés restent cohérents.

Utilisez le scénario Kanboard complet depuis un réseau vierge, et pas seulement la page racine. Une erreur 502 ou un problème de certificat peut être isolé avec la configuration automatique du domaine et du TLS. Si le trafic atteint le processus mais que SQLite ne peut pas écrire parce que le répertoire de données monté appartient au mauvais utilisateur, diagnostiquez cette condition à l’endroit où elle se produit au lieu d’empiler les redirections.

Rendre le démarrage de Kanboard reproductible

Un lancement proche de la production est volontairement banal : un état nommé, un port explicite et aucun secret dans l’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

Cet exemple constitue une base, pas une stack complète. Confirmez l’exigence locale avant toute exposition : un volume de données accessible en écriture et, en option, un serveur SMTP. Vérifiez les mounts effectifs et le listener, puis essayez de remplacer les identifiants par défaut, de créer un projet et une tâche, de la déplacer entre les colonnes, d’importer un fichier et de tester l’un des plugins installés. Épinglez l’image qui fonctionne avant le prochain redémarrage.

Surveiller la charge, pas seulement le conteneur

Pour Kanboard, surveillez une transaction plutôt qu’un processus : remplacez les identifiants par défaut, créez un projet et une tâche, déplacez-la entre les colonnes, importez un fichier et testez l’un des plugins installés. Combinez sa latence et son taux d’erreur avec les verrous SQLite, le volume des pièces jointes, les actions en arrière-plan et le comportement des plugins avec plusieurs utilisateurs simultanés, afin qu’une alerte identifie le composant sous contrainte.

La répétition générale de la mise à niveau doit couvrir le fait que les migrations de base de données et la compatibilité des plugins justifient un snapshot avant la mise à jour de l’image Kanboard. Restaurez, migrez et exécutez la transaction avant de remplacer la version en production. Si SQLite ne peut pas écrire parce que le répertoire de données monté appartient au mauvais utilisateur, n’effacez pas les données pour obtenir un démarrage au vert ; comparez dans cet ordre la version, les variables, les mounts et l’accessibilité des dépendances.

Valider le déploiement Kanboard de bout en bout

Une gate de production pour Kanboard doit pouvoir être exécutée par une personne qui n’a pas construit le déploiement. Donnez-lui la version épinglée, un compte de test non sensible et la tâche suivante : remplacer les identifiants par défaut, créer un projet et une tâche, la déplacer entre les colonnes, importer un fichier et tester l’un des plugins installés. Si les instructions nécessitent un accès shell non documenté, le service n’est pas encore prêt pour l’exploitation.

Répétez cette gate après avoir remplacé uniquement le conteneur. Ensuite, restaurez la base SQLite, les fichiers importés, les plugins et la configuration dans une infrastructure vierge, puis vérifiez que les projets, l’historique des tâches, les utilisateurs, les pièces jointes et les plugins sont revenus et que le tableau restauré accepte une nouvelle tâche. Mesurez les verrous SQLite, le volume des pièces jointes, les actions en arrière-plan et le comportement des plugins avec plusieurs utilisateurs simultanés lors des deux exécutions réussies ; les différences inattendues révèlent souvent un cache, un index, un worker ou un mount de données manquant.

Ajoutez un exercice de panne : envoyez une entrée inoffensive proche de la limite de ressource ou de format associée à cette limite : SQLite ne peut pas écrire parce que le répertoire de données monté appartient au mauvais utilisateur. Kanboard doit produire une erreur exploitable, préserver l’état existant et revenir à la normale lorsque la condition valide est rétablie. Enregistrez les horodatages et les lignes de log pertinentes, après avoir masqué les secrets. Ces éléments serviront de référence pour la prochaine modification d’image ou de configuration.

Les volumes ne sont que la première couche de récupération

Créez un manifest de récupération pour Kanboard : base SQLite, fichiers importés, plugins et configuration. Montez /var/www/app/data avant le bootstrap, écrivez des données d’exemple inoffensives et remplacez le conteneur pour prouver que ce chemin est effectivement persistant. Vérifiez dès maintenant les droits et l’espace libre, car un chemin monté mais inaccessible en écriture se comporte exactement comme une absence de persistance.

Sauvegardez vers un failure domain distinct du serveur en production. Recréez Kanboard à partir de son image épinglée et vérifiez que les projets, l’historique des tâches, les utilisateurs, les pièces jointes et les plugins sont revenus et que le tableau restauré accepte une nouvelle tâche. Le guide des volumes persistants aide à traduire cet exercice en politique de snapshots et de rétention.

Protéger la partie importante de Kanboard

Un déploiement Kanboard sécurisé commence par la suppression des privilèges inutiles. Évitez de conserver les identifiants admin/admin par défaut ; supprimez-les immédiatement, limitez l’accès aux projets et examinez les plugins avant de leur donner accès aux données de production.

Kanboard n’a pas de secret de bootstrap obligatoire dans cette configuration de base ; protégez plutôt son véritable compte administrateur ou l’authentification en amont. Restreignez les routes d’administration, utilisez un DNS privé pour les dépendances et examinez chaque bind mount. Lorsque les logs sont centralisés, filtrez les secrets et les contenus privés avant leur envoi hors du serveur.

Ce que Dockup prend en charge pour Kanboard

Un template Dockup doit encoder l’image, le port 80, les mounts, les délais de health check, le domaine, le TLS et la transmission des secrets. Dockup doit conserver les paramètres du runtime Kanboard pendant que l’opérateur confirme cette exigence locale : un volume de données accessible en écriture et, en option, un serveur SMTP. Le même déploiement peut cibler des serveurs Dockup ou une capacité rattachée par le client.

Une fois la route active, appliquez le paramètre public et essayez de remplacer les identifiants par défaut, de créer un projet et une tâche, de la déplacer entre les colonnes, d’importer un fichier et de tester l’un des plugins installés. Sauvegardez la base SQLite, les fichiers importés, les plugins et la configuration, puis intégrez l’exercice de restauration au plan d’exploitation ; il s’agit de responsabilités Kanboard qui restent visibles après le provisioning de l’infrastructure.

Foire aux questions

De quoi Kanboard a-t-il besoin pour un déploiement en production ?

Acheminez le conteneur Kanboard sur le port 80 via une seule origine HTTPS. L’exigence du runtime local est un volume de données accessible en écriture et, en option, un serveur SMTP. Ne considérez pas Kanboard comme prêt tant que vous ne pouvez pas remplacer les identifiants par défaut, créer un projet et une tâche, la déplacer entre les colonnes, importer un fichier et tester l’un des plugins installés.

Quelles données Kanboard doivent faire partie d’une sauvegarde ?

Rendez /var/www/app/data persistant et incluez la base SQLite, les fichiers importés, les plugins et la configuration dans le même manifest de récupération. Une restauration Kanboard vierge n’est réussie que lorsque les projets, l’historique des tâches, les utilisateurs, les pièces jointes et les plugins sont revenus et que le tableau restauré accepte une nouvelle tâche.

Kanboard nécessite-t-il HTTPS derrière un reverse proxy ?

Utilisez HTTPS pour l’origine publique de Kanboard et conservez le port 80 sur la route interne. Appliquez correctement le paramètre Kanboard : servez le tableau via HTTPS et définissez l’URL de l’application si les plugins en ont besoin. Pour Kanboard, HTTPS protège les identifiants ou les contenus des utilisateurs pendant leur transmission et garantit un comportement cohérent des clients sensible à l’origine.

Comment tester une mise à niveau de Kanboard ?

Restaurez l’état actuel de Kanboard dans un déploiement isolé, appliquez la version candidate et répétez sa transaction de validation. Soyez particulièrement attentif au fait que les migrations de base de données et la compatibilité des plugins justifient un snapshot avant la mise à jour de l’image Kanboard. Conservez l’image Kanboard précédente jusqu’à ce que les limites de migration des données et de rollback soient comprises.