Cómo alojar Kanboard por tu cuenta en 2026: SQLite, plugins y actualizaciones seguras

Un despliegue de Kanboard fallido no siempre se bloquea. Puede mostrar la página de inicio de sesión mientras SQLite no puede escribir porque el directorio de datos montado tiene un propietario incorrecto. Empieza con una comprobación end-to-end: sustituye el inicio de sesión predeterminado, crea un proyecto y una tarea, muévela entre columnas, sube un archivo y prueba uno de los plugins instalados.

Esa comprobación coincide con la finalidad catalogada de Kanboard: un tablero kanban minimalista respaldado por SQLite. También revela antes que una comprobación de uptime las dependencias que faltan, las suposiciones incorrectas sobre el proxy y los datos efímeros.

Separa Kanboard de sus dependencias

La topología mínima responsable de Kanboard contiene un único listener privado en el puerto 80, una ruta de ingress y un límite de estado documentado. El requisito del runtime local es un volumen de datos con permisos de escritura y SMTP opcional. Mantén explícito su ciclo de vida para que mover Kanboard entre hosts no cambie el comportamiento de forma silenciosa.

Valida la topología pidiendo a un cliente limpio que sustituya el inicio de sesión predeterminado, cree un proyecto y una tarea, la mueva entre columnas, suba un archivo y pruebe uno de los plugins instalados. Mientras se ejecuta, observa el locking de SQLite, el volumen de adjuntos, las acciones en segundo plano y el comportamiento de los plugins con varios usuarios simultáneos. El resultado te indica si la siguiente mejora corresponde a la memoria, el almacenamiento, la red o un worker independiente, en lugar de fomentar un dimensionamiento arbitrario del contenedor.

Dominios, cabeceras del proxy y puerto 80

La emisión de TLS es solo la mitad de la ruta de Kanboard. Sirve el tablero mediante HTTPS y establece la URL de la aplicación si los plugins la necesitan. Envía el tráfico internamente al puerto 80 y reenvía el esquema externo para que las URL generadas y las secure cookies sean coherentes.

Usa el escenario completo de Kanboard desde una red limpia, no solo la página raíz. Un error 502 o un fallo del certificado se puede aislar con la configuración automática del dominio y TLS. Si el tráfico llega al proceso y SQLite no puede escribir porque el directorio de datos montado tiene un propietario incorrecto, diagnostica esa condición donde se produce en lugar de acumular redirecciones.

Haz reproducible el arranque de Kanboard

Un lanzamiento con forma de producción es deliberadamente aburrido: estado con nombre, puerto explícito y ningún secret dentro de la 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

El ejemplo es una base, no un stack de soporte completo. Confirma el requisito local antes de exponer el servicio: un volumen de datos con permisos de escritura y SMTP opcional. Comprueba los mounts efectivos y el listener; después, intenta sustituir el inicio de sesión predeterminado, crear un proyecto y una tarea, moverla entre columnas, subir un archivo y probar uno de los plugins instalados. Fija la imagen que funciona antes del siguiente reinicio.

Observa la carga de trabajo, no solo el contenedor

En Kanboard, monitoriza una transacción en lugar de un proceso: sustituye el inicio de sesión predeterminado, crea un proyecto y una tarea, muévela entre columnas, sube un archivo y prueba uno de los plugins instalados. Combina su latencia y tasa de errores con el locking de SQLite, el volumen de adjuntos, las acciones en segundo plano y el comportamiento de los plugins con varios usuarios simultáneos para que una alerta identifique el componente limitado.

El ensayo de actualización debe cubrir que las migraciones de base de datos y la compatibilidad de los plugins requieren un snapshot antes de actualizar la imagen de Kanboard. Restaura, ejecuta la migración y realiza la transacción antes de sustituir la versión en producción. Si SQLite no puede escribir porque el directorio de datos montado tiene un propietario incorrecto, no borres datos para que el arranque aparezca en verde; compara la versión, las variables, los mounts y la accesibilidad de las dependencias, en ese orden.

Demuestra el despliegue de Kanboard end-to-end

Una puerta de producción para Kanboard debe poder ejecutarla alguien que no haya creado el despliegue. Proporciona a esa persona la versión fijada, una cuenta de prueba no sensible y esta tarea: sustituir el inicio de sesión predeterminado, crear un proyecto y una tarea, moverla entre columnas, subir un archivo y probar uno de los plugins instalados. Si las instrucciones requieren acceso shell no documentado, el servicio aún no está listo para operar.

Repite la validación después de sustituir únicamente el contenedor. Después, restaura la base de datos SQLite, los archivos subidos, los plugins y la configuración en una infraestructura vacía y demuestra que vuelven los proyectos, el historial de tareas, los usuarios, los adjuntos y los plugins, y que el tablero restaurado acepta una tarea nueva. Mide el locking de SQLite, el volumen de adjuntos, las acciones en segundo plano y el comportamiento de los plugins con varios usuarios simultáneos durante ambas ejecuciones correctas; las diferencias inesperadas suelen revelar la ausencia de una caché, un índice, un worker o un mount de datos.

Añade un simulacro de fallo: envía una entrada inocua cerca del límite de recursos o formato asociado a este límite: SQLite no puede escribir porque el directorio de datos montado tiene un propietario incorrecto. Kanboard debe emitir un error útil, conservar el estado existente y recuperarse cuando vuelva a cumplirse la condición válida. Guarda las marcas de tiempo y las líneas de log relevantes, con los secrets ocultos. Esa evidencia se convierte en la referencia para el siguiente cambio de imagen o configuración.

Los volúmenes son solo la primera capa de recuperación

Crea un recovery manifest para Kanboard: base de datos SQLite, archivos subidos, plugins y configuración. Monta /var/www/app/data antes del bootstrap, escribe datos de ejemplo inocuos y sustituye el contenedor para demostrar que esa ruta es realmente persistente. Comprueba ahora el propietario y el espacio libre, porque una ruta montada pero sin permisos de escritura se comporta exactamente como si no hubiera persistencia.

Haz copias de seguridad en un failure domain separado del servidor en ejecución. Recrea Kanboard a partir de su imagen fijada y verifica que vuelven los proyectos, el historial de tareas, los usuarios, los adjuntos y los plugins, y que el tablero restaurado acepta una tarea nueva. La guía de persistent volumes ayuda a convertir este ejercicio en una política de snapshots y retención.

Protege la parte valiosa de Kanboard

Un despliegue seguro de Kanboard empieza por eliminar privilegios. Evita conservar las credenciales predeterminadas admin/admin; en su lugar, elimina admin/admin de inmediato, restringe el acceso a los proyectos y revisa los plugins antes de darles acceso a datos de producción.

Kanboard no tiene ningún secret de bootstrap obligatorio en esta configuración base; protege la cuenta de administrador real o la autenticación upstream. Restringe las rutas administrativas, usa DNS privado para las dependencias y revisa cada bind mount. Cuando los logs se envíen de forma centralizada, filtra los secrets y el contenido privado antes de que salgan del servidor.

Cómo Dockup elimina trabajo para Kanboard

Una plantilla de Dockup debe codificar la imagen, el puerto 80, los mounts, los tiempos de health check, el dominio, TLS y la entrega de secrets. Dockup debe conservar la configuración del runtime de Kanboard mientras el operador confirma este requisito local: un volumen de datos con permisos de escritura y SMTP opcional. El mismo despliegue puede dirigirse a servidores de Dockup o a capacidad vinculada por el cliente.

Cuando la ruta esté activa, aplica la configuración pública e intenta sustituir el inicio de sesión predeterminado, crear un proyecto y una tarea, moverla entre columnas, subir un archivo y probar uno de los plugins instalados. Haz copias de seguridad de la base de datos SQLite, los archivos subidos, los plugins y la configuración, y mantén el ejercicio de restauración en el plan operativo; son responsabilidades de Kanboard que siguen siendo visibles después del aprovisionamiento de la infraestructura.

Preguntas frecuentes

¿Qué necesita Kanboard para un despliegue de producción?

Dirige el contenedor de Kanboard en el puerto 80 a través de un único origen HTTPS. El requisito del runtime local es un volumen de datos con permisos de escritura y SMTP opcional. No consideres Kanboard listo hasta que puedas sustituir el inicio de sesión predeterminado, crear un proyecto y una tarea, moverla entre columnas, subir un archivo y probar uno de los plugins instalados.

¿Qué datos de Kanboard deben incluirse en una copia de seguridad?

Mantén /var/www/app/data y añade la base de datos SQLite, los archivos subidos, los plugins y la configuración al mismo recovery manifest. Una restauración limpia de Kanboard solo es válida cuando vuelven los proyectos, el historial de tareas, los usuarios, los adjuntos y los plugins, y el tablero restaurado acepta una tarea nueva.

¿Kanboard necesita HTTPS detrás de un reverse proxy?

Usa HTTPS para el origen público de Kanboard y mantén el puerto 80 en la ruta interna. Aplica correctamente la configuración de Kanboard: sirve el tablero mediante HTTPS y establece la URL de la aplicación si los plugins la necesitan. En Kanboard, HTTPS protege las credenciales o el contenido de los usuarios durante el tránsito y mantiene coherente el comportamiento del cliente sensible al origen.

¿Cómo se debe probar una actualización de Kanboard?

Restaura el estado actual de Kanboard en un despliegue aislado, aplica la versión candidata y repite su transacción de aceptación. Presta especial atención, porque las migraciones de base de datos y la compatibilidad de los plugins requieren un snapshot antes de actualizar la imagen de Kanboard. Conserva la imagen anterior de Kanboard hasta comprender sus límites de migración de datos y rollback.