Guía de despliegue

Alojar Kaneo en un VPS: gestión de proyectos open source ligera

Desplegar en un VPS Cloud →

Tutorial

Alojar Kaneo en un VPS: gestión de proyectos open source ligera

Autoalojamiento10 min de lectura5 pasos

Jira factura por usuario, Linear impone sus planes de precios y Trello limita las columnas en su nivel gratuito. Kaneo (MIT, 7.9 k+ estrellas, v2.16.2 — publicada el 10 de agosto de 2026) sigue otra lógica: un gestor de proyectos minimalista que usted aloja en su propio VPS. Tableros Kanban, integración de los GitHub Milestones y webhooks, sin las vistas que nunca va a usar ni el coste por asiento.

Contenido· Por qué elegir un gestor de proyectos minimalista1/11
  1. 01Por qué elegir un gestor de proyectos minimalista
  2. 02Lo que obtiene con Kaneo autoalojado
  3. 03Requisitos previos
  4. 04Desplegar Kaneo en su VPS
  5. 05Configuración avanzada: múltiples espacios de trabajo y aislamiento de equipos
  6. 06Webhooks para automatizar su CI/CD
  7. 07Backup y restauración de PostgreSQL
  8. 08Actualizar Kaneo a una nueva versión
  9. 09Configurar SMTP para notificaciones por correo
  10. 10Solución de errores: los problemas más frecuentes
  11. 11Kaneo, Plane y Huly: ¿cuál autoalojar?

Por qué elegir un gestor de proyectos minimalista

Las herramientas SaaS de gestión de proyectos tienden a engordar: cada actualización añade una vista, un informe o un módulo de IA que ahoga las funciones esenciales. Kaneo parte de la hipótesis contraria: la mayoría de los equipos solo necesita un Kanban y un vínculo con su repositorio de código. Al autoalojarlo, usted recupera el control total — sus tareas en una base de datos PostgreSQL en su VPS, exportables como SQL en cualquier momento, sin plan premium para desbloquear los webhooks o el historial ilimitado.

Lo que obtiene con Kaneo autoalojado

  • Tableros Kanban con arrastrar y soltar: cree columnas, añada tareas y siga el avance de un vistazo.
  • Sincronización con GitHub Milestones: conecte su GitHub App para reflejar automáticamente los milestones como proyectos y las issues como tareas.
  • Destinos de Webhook: dispare llamadas HTTP externas en cada cambio de estado de una tarea, para avisar a Slack o a su CI.
  • Licencia MIT: sin restricciones comerciales, con fork y adaptación libres.
  • Solo dos contenedores: aplicación Node.js y PostgreSQL 16, con una huella de memoria inferior a 400 MB en total.
  • Inicio de sesión sin SMTP: correo electrónico y contraseña de serie, sin paso de verificación por enlace.
  • Múltiples espacios de trabajo: aísle los proyectos por cliente o por equipo en espacios separados.

Requisitos previos

Un VPS ServOrbit con Ubuntu 24.04 y al menos 1 GB de RAM basta para un equipo pequeño. Kaneo es ligero: la API Hono (Node.js) y la SPA Vue.js consumen juntas menos de 200 MB en reposo; PostgreSQL 16 añade unos 300 MB. Docker y Docker Compose se aprovisionan automáticamente por AWX durante el despliegue. No es obligatorio un nombre de dominio — Kaneo funciona tras la URL asignada por ServOrbit — pero un subdominio dedicado (p. ej. projects.your-domain.com) facilita el acceso.

Desplegar Kaneo en su VPS

  1. Despliegue en un clic desde la marketplace de ServOrbit

    Vaya a Marketplace → Colaboración y productividad → Kaneo en su panel de control ServOrbit y haga clic en Desplegar. AWX instala Docker, genera los secretos de base de datos y autenticación, configura nginx y arranca los dos contenedores (aplicación + PostgreSQL) en menos de 2 minutos.

  2. Crear la primera cuenta de administrador

    Abra la URL de Kaneo en su navegador. Aparece un formulario de registro: es el primer arranque. Introduzca su nombre, su correo electrónico y una contraseña. El primer usuario obtiene automáticamente los derechos de administrador sobre el espacio de trabajo predeterminado.

  3. Crear un espacio de trabajo y su primer proyecto

    Tras iniciar sesión, llegará a la página de inicio del espacio de trabajo. Haga clic en Nuevo proyecto, asígnele un nombre y elija un color. Añada su primera tarea haciendo clic en + en la columna Kanban que prefiera. Asígnela, añada una descripción y una fecha de vencimiento si lo necesita.

  4. Conectar GitHub (opcional)

    Si su código vive en GitHub, instale la Kaneo GitHub App desde Configuración → Integraciones. Una vez autorizada, Kaneo sincroniza los GitHub Milestones como proyectos y las issues como tareas. Los webhooks pueden actualizar el estado de una tarea automáticamente cuando se fusiona un Pull Request.

  5. Configurar los webhooks de notificación (opcional)

    En Configuración → Webhooks, añada la URL de su canal de Slack Incoming Webhook o de su sistema de tickets. Kaneo envía un POST JSON en cada cambio de estado — útil para notificar al equipo sin polling.

Cierre el registro en cuanto su equipo esté configurado: en Configuración → General, desactive la opción «Permitir registros». Sin este paso, cualquiera que conozca la URL puede crear una cuenta. Para los equipos que prefieren los commits a las historias de usuario, conecte la GitHub App y deje que los PRs actualicen el tablero automáticamente.

Configuración avanzada: múltiples espacios de trabajo y aislamiento de equipos

Kaneo admite múltiples espacios de trabajo en una misma instancia. Cada workspace tiene sus propios proyectos, miembros y webhooks — útil para separar clientes o equipos en un único VPS sin multiplicar los despliegues.

Para crear un segundo espacio de trabajo, haga clic en el selector en la parte superior izquierda de la interfaz y elija Nuevo espacio de trabajo. Los miembros de un workspace no tienen acceso a los demás: el aislamiento es a nivel de aplicación. Puede alojar los proyectos del cliente A y del cliente B en el mismo servidor, cada uno con sus tableros e integraciones de GitHub independientes.

Si necesita campos personalizados en las tareas, consulte la documentación oficial de Kaneo antes de depender de ellos: los custom fields forman parte de la hoja de ruta, pero su disponibilidad puede variar según la versión desplegada.

Webhooks para automatizar su CI/CD

Los webhooks de Kaneo son una de sus ventajas más directas para los equipos de desarrollo. En cada cambio de estado de una tarea — movimiento de columna, asignación, comentario — Kaneo envía un POST JSON a la URL que elija.

Casos de uso habituales:

- Notificación de Slack: añada la URL de Incoming Webhook de su canal para recibir una alerta cuando una tarea pase a «En curso» o «Terminado».
- Disparo de pipeline CI: reenvíe el evento a su sistema de CI (GitHub Actions, Gitea Actions, Jenkins) para lanzar automáticamente una compilación o un despliegue cuando una tarea llegue a una columna objetivo.
- Sincronización con sistema externo: el endpoint puede apuntar a cualquier API REST — herramienta de reporting, base de tickets o un webhook de n8n para orquestar flujos complejos.

Pruebe sus endpoints con un servicio como webhook.site antes de conectarlos a producción, para verificar que el formato coincide con lo que espera su CI.

Backup y restauración de PostgreSQL

Kaneo almacena todos sus datos en PostgreSQL 16. Una copia de seguridad periódica es imprescindible: sin ella, una actualización fallida o una corrupción del volumen podría hacerle perder todo el historial de tareas.

Automatizar las copias de seguridad con cron y rclone

# /etc/cron.d/kaneo-backup
0 3 * * * root docker exec kaneo-db pg_dump -U kaneo kaneo | gzip > /var/backups/kaneo/$(date +\%Y\%m\%d).sql.gz
5 3 * * * root rclone copy /var/backups/kaneo/ s3:my-bucket/kaneo/ --max-age 30d

Reemplace kaneo-db por el nombre real de su contenedor PostgreSQL (docker ps para comprobarlo).

Restaurar una copia de seguridad

docker stop kaneo-app
gunzip -c /var/backups/kaneo/20260901.sql.gz | docker exec -i kaneo-db psql -U kaneo kaneo
docker start kaneo-app

Conserve al menos 7 dumps locales y 30 días de copias remotas. Pruebe una restauración en un entorno de prueba antes de necesitarla.

Actualizar Kaneo a una nueva versión

Kaneo publica sus versiones en GitHub. El procedimiento de actualización es estándar para un despliegue con Docker Compose:

docker compose pull
docker compose up -d
docker compose ps

Antes de cualquier actualización, realice una copia de seguridad completa. Lea las notas de la nueva versión en GitHub: algunas actualizaciones incluyen migraciones de base de datos que se aplican automáticamente al arrancar el contenedor. Si una migración falla, los logs del contenedor (docker logs kaneo-app) mostrarán los detalles.

Configurar SMTP para notificaciones por correo

Por defecto, Kaneo no requiere un servidor SMTP: el registro se hace con correo y contraseña, sin enlace de verificación. Esto simplifica el despliegue inicial pero limita las notificaciones por email (restablecimiento de contraseña, alertas de tareas).

Si su versión de Kaneo admite configuración SMTP, los parámetros se encuentran en las variables de entorno del docker-compose.yml desplegado:

SMTP_HOST=smtp.your-domain.com
SMTP_PORT=587
[email protected]
SMTP_PASSWORD=your-password
[email protected]

Tras modificar las variables, reinicie los contenedores con docker compose up -d. Pruebe el envío desde la interfaz de administración antes de cerrar el registro público.

Solución de errores: los problemas más frecuentes

El contenedor se reinicia continuamente en el primer arranque

Causa más frecuente: un secreto ausente o mal formateado en el archivo de entorno. Revise los logs del contenedor de la aplicación (docker logs kaneo-app).

La interfaz carga pero el inicio de sesión falla con «Invalid credentials»

La primera cuenta creada es la del administrador. Si reinició el contenedor sin eliminar el volumen de PostgreSQL, la cuenta ya existe en la base de datos: intente iniciar sesión con las credenciales introducidas en el primer registro.

Los webhooks no se disparan

Compruebe que la URL de destino es accesible desde el contenedor de Kaneo (no localhost en el VPS anfitrión — use una IP externa o un nombre de dominio).

La sincronización de GitHub se detiene tras unas horas

La GitHub App necesita que la URL de callback sea accesible por HTTPS desde Internet. Verifique que su certificado SSL es válido y que el puerto 443 está abierto en su VPS.

El rendimiento se degrada con muchas tareas

En un VPS con 1 GB de RAM, PostgreSQL puede convertirse en un cuello de botella cuando crece el volumen de datos. Aumente shared_buffers en la configuración de PostgreSQL o pase a un plan con 2 GB de RAM.

Kaneo, Plane y Huly: ¿cuál autoalojar?

Desplace la tabla

CriterioKaneoPlaneHuly
LicenciaMITAGPL-3.0EPL-2.0
Contenedores necesarios2 (app + PostgreSQL)5–7 (API, worker, Redis, RabbitMQ, MinIO…)6–8 (API, Collaborator, MongoDB, MinIO, Elastic…)
RAM recomendada1 GB (funciona)2–4 GB mínimo4–8 GB recomendados
Tableros KanbanSí (Cycles, Modules)Sí (Issues, Planner)
Integración GitHubMilestones + webhooksImportación de issues, GitLab tambiénIssues, PRs, ramas
Vistas GanttNoSí (Planner)
Chat integradoNoNoSí (Chunter)
Documentación / wikiNoPagesChunter + Documents
Complejidad de despliegueMuy bajaMediaAlta
Ideal paraEquipos code-first, solo KanbanEquipos de producto estructuradosReemplazar Linear + Notion + Slack

La elección correcta depende de lo que quiera reemplazar. Kaneo sustituye un Trello o un Kanban ligero con mínima fricción. Plane sustituye un Jira simplificado, con ciclos y módulos. Huly sustituye una pila más amplia (Linear + Notion + Slack) pero requiere una máquina más potente y una configuración más larga. En un VPS con 1 GB de RAM, solo Kaneo funciona con comodidad — Plane puede arrancar con 2 GB, Huly necesita al menos 4 GB para mantenerse estable.

Despliegue Kaneo en su propio servidor

Autoaloje Kaneo en un VPS ServOrbit — open source MIT, sin suscripción, toda su gestión de proyectos en su propia infraestructura.

¿Necesita ayuda?

Consulte nuestro centro de ayuda y nuestra FAQ, o contacte con nuestro equipo: llamada, WhatsApp o correo electrónico. Soporte en francés, inglés y árabe.

Escribir por WhatsAppse abre en una pestaña nueva