kanban.d4r.es: qué es Fizzy, cómo funciona y cómo se integra con el stack
kanban.d4r.es es la instancia self-hosted de Fizzy, la herramienta de gestión visual de tareas e ideas publicada por 37signals (los creadores de Basecamp y HEY) bajo una licencia de código abierto. En el stack D4R actúa como el espacio de coordinación interna del equipo: donde las ideas pasan de boceto a tarea concreta y las tareas se mueven hasta completarse.
Qué es Fizzy
Fizzy es un tablero Kanban minimalista pensado para equipos pequeños que no quieren la complejidad de Jira ni la imprecisión de una hoja de cálculo. Su filosofía viene directamente de la forma de trabajar de 37signals: pocas columnas, tarjetas concretas, sin estimaciones forzadas ni burocracia de estados.
Las piezas fundamentales son sencillas:
- Tablero — el espacio de trabajo, con columnas configurables.
- Tarjeta — la unidad mínima de trabajo. Tiene título, descripción enriquecida, comentarios y archivos adjuntos.
- Columnas — representan el estado de una tarjeta. Típicamente: Backlog → En curso → Revisión → Hecho.
- Draft — las tarjetas pueden estar en borrador antes de entrar al flujo activo. La URL
/cards/12/draftindica precisamente eso: la tarjeta 12 todavía en fase de borrador.
Cómo se accede: magic links
Fizzy no usa contraseñas. El flujo de acceso es siempre el mismo:
- Introduces tu email en la pantalla de login.
- Fizzy envía un código de 6 caracteres a ese email.
- Introduces el código y accedes.
Este mecanismo se llama magic link o autenticación sin contraseña. Elimina el riesgo de contraseñas débiles o reutilizadas y simplifica el proceso de incorporación de nuevos usuarios: no hay «crear contraseña», solo «confirmar tu email».
En el stack D4R, el acceso a kanban.d4r.es tiene dos capas:
- Capa perimetral — Authentik: solo los usuarios del grupo
kanban-userspasan el forward-auth de Traefik. Si no perteneces al grupo, Authentik redirige al login SSO y no llega ninguna petición a Fizzy. - Capa de identidad — Fizzy: una vez dentro del perímetro, Fizzy necesita que exista una
Identitycon tu email en su base de datos SQLite. Sin esa identidad, el magic link no puede generarse.
Esto significa que un usuario necesita estar dado de alta en ambos sistemas para poder usar Fizzy.
Dónde guarda Fizzy sus datos
Fizzy usa SQLite como base de datos. En la instalación del stack, la base de datos vive en un volumen Docker persistente montado en /rails/storage/production.sqlite3. No usa PostgreSQL ni ninguna base de datos externa.
Las tablas más relevantes desde el punto de vista operativo son:
| Tabla | Contenido |
|---|---|
| identities | Un registro por usuario: solo el email. Es el objeto mínimo que permite el login. |
| magic_links | Los códigos de acceso generados, con su expiración. Un usuario puede tener varios pendientes. |
| accounts | El espacio de trabajo (en modo single-tenant, uno solo). |
| buckets | Los tableros dentro de la cuenta. |
| cards | Las tarjetas de cada tablero, con estado, posición y contenido. |
| comments | Comentarios anidados en cada tarjeta. |
La URL de una tarjeta
La estructura de URLs de Fizzy es predecible y legible:
https://kanban.d4r.es/{account_id}/cards/{card_id}/draft
└── cuenta └── tarjeta └── estado
/1/— la cuenta (en modo single-tenant siempre es 1)./cards/12/— la tarjeta con ID 12./draft— la tarjeta está en estado borrador, todavía no ha entrado al flujo activo del tablero.
Una tarjeta activa en el tablero tendría una URL como /1/cards/12 sin el sufijo /draft. Las tarjetas en draft son visibles para los miembros del equipo pero no aparecen en las columnas del tablero hasta que se promueven.
Modo single-tenant vs. multi-tenant
Fizzy puede correr en dos modos:
| Modo | Comportamiento |
|---|---|
| Single-tenant (por defecto) | La primera cuenta que se crea bloquea el registro de nuevas cuentas. Es el modo recomendado para self-hosting de un solo equipo. |
Multi-tenant (MULTI_TENANT=true) | Permite crear múltiples cuentas independientes. Útil si se quiere ofrecer Fizzy como servicio a varios equipos desde una sola instancia. |
En el stack D4R corre en modo single-tenant, con una única cuenta que es el espacio de trabajo del equipo. El acceso perimetral via Authentik hace innecesario el modo multi-tenant: el control de quién puede acceder ya está en la capa SSO.
Notificaciones push (VAPID)
Fizzy soporta Web Push para notificaciones nativas del navegador. Para activarlas hace falta un par de claves VAPID que se generan una sola vez:
# Dentro del contenedor
docker exec app-fizzy-1 sh -lc "cd /rails && bin/rails c"
# En la consola Rails:
vapid_key = WebPush.generate_key
puts "VAPID_PRIVATE_KEY=#{vapid_key.private_key}"
puts "VAPID_PUBLIC_KEY=#{vapid_key.public_key}"
Las claves se añaden al .env.prod y el contenedor se reinicia. A partir de ese momento, los usuarios pueden suscribirse a notificaciones push directamente desde la interfaz del tablero.
Dar de alta un usuario nuevo
El flujo completo para incorporar a alguien a Fizzy — incluyendo el alta en Authentik y la sincronización de la identidad — está en un único comando desde el repo:
make kanban-user email='nuevo@dominio.com' name='Nombre Apellido'
Ese target hace tres cosas en secuencia:
- Crea o actualiza el usuario en Authentik con email, nombre y contraseña temporal generada aleatoriamente.
- Añade el usuario al grupo
kanban-usersen Authentik (lo que abre el perímetro de Traefik). - Crea la
Identityen la base SQLite de Fizzy (lo que permite el login via magic link).
Si el usuario ya existe en alguno de los dos sistemas, el script no duplica: actualiza lo que haya cambiado y crea lo que falte.
Consultar y depurar magic links desde el servidor
Si el email con el código no llega, el código sigue existiendo en la base de datos y puede recuperarse directamente:
docker exec app-fizzy-1 sh -lc "sqlite3 /rails/storage/production.sqlite3 "
SELECT identities.email_address, magic_links.code, magic_links.expires_at
FROM magic_links
JOIN identities ON identities.id = magic_links.identity_id
WHERE identities.email_address = 'usuario@dominio.com'
ORDER BY magic_links.created_at DESC LIMIT 3;
""
Ese código de 6 caracteres puede introducirse directamente en la pantalla de login de Fizzy para acceder, independientemente de si el email llegó o no.
Ficheros adjuntos: SQLite o S3
Por defecto, los archivos adjuntos a tarjetas se guardan en el mismo volumen que la base de datos (/rails/storage). Para instalaciones que prevean mucho almacenamiento de archivos, Fizzy admite delegar el almacenamiento a un bucket S3 compatible:
ACTIVE_STORAGE_SERVICE=s3
S3_BUCKET=fizzy-attachments
S3_REGION=eu-west-1
S3_ACCESS_KEY_ID=...
S3_SECRET_ACCESS_KEY=...
# Para MinIO u otros proveedores S3-compatible:
S3_ENDPOINT=https://minio.d4r.es
S3_FORCE_PATH_STYLE=true
En el stack D4R, MinIO está disponible en minio.d4r.es y es totalmente compatible con esta configuración, lo que permite mover los adjuntos de Fizzy fuera del volumen Docker sin cambiar la interfaz de usuario.