Gestión de coros: una zona web privada para gestionar coros: repertorio, calendario, asistencia y ensayo individual
En Ars Mvsica necesitábamos algo muy concreto: compartir el programa en curso, saber quién asistirá a cada ensayo y ofrecer materiales de estudio sin convertir la gestión del coro en otra profesión. De esa necesidad ha nacido una aplicación sencilla, privada y de código abierto que cualquier coro puede adaptar.
Dirigir un coro produce una cantidad sorprendente de información. Hay fechas de ensayos y conciertos, cambios de última hora, partituras, grabaciones de estudio, listas de reproducción, instrucciones para la semana siguiente y, por supuesto, mensajes de cantantes que no podrán asistir o llegarán tarde.
Nada de eso es especialmente complicado por separado. El problema aparece cuando cada cosa vive en un lugar distinto: un grupo de WhatsApp, una carpeta compartida, una hoja de cálculo, un calendario, varios correos y la memoria del director. Entonces una pregunta tan sencilla como «¿cuántos tenores vienen el viernes?» obliga a reconstruir media docena de conversaciones y encomendarse al patrón o patrona del pueblo del director.
En Ars Mvsica queríamos (en concreto YO quería) una solución pequeña y muy enfocada, y pensé en diseñar una zona privada para nuestra web que respondiera bien a unas pocas necesidades reales:
- que cada cantante pudiera consultar el calendario y el repertorio activo;
- que pudiera confirmar si asistirá, llegará tarde o no podrá acudir;
- que cada persona viera únicamente sus propias respuestas;
- que yo como director tuviera una visión completa, ordenada por cuerdas;
- que las partituras y los audios de ensayo estuvieran en el mismo sitio;
- y que pasar de un programa al siguiente no exigiera rehacer toda la web.
El resultado es Gestión de coros, una aplicación web que ya usamos en producción y que hemos publicado con licencia MIT en GitHub. Puede utilizarse, modificarse y adaptarse libremente.
Este artículo tiene dos partes. En la primera enseño qué puede hacer la aplicación y cómo se utiliza. En la segunda explico cómo puede instalarla otro coro, qué decisiones debe tomar y qué alternativas existen cuando su organización no se parece a la nuestra.
Primera parte: cómo funciona
Entrar sin recordar otra contraseña
El acceso se realiza mediante un enlace mágico por email. El cantante escribe su dirección y, si está autorizado, recibe un mensaje con un botón para entrar. No tiene que crear ni recordar una contraseña nueva, porque tengo claro que de hacerlo así, la plataforma nacería muerta.
El enlace ordinario de acceso caduca a los 15 minutos y sólo se puede usar una vez. Después de abrirlo se crea una sesión privada en ese navegador que dura hasta 30 días, salvo que el usuario cierre sesión, cambie de navegador o elimine sus datos de navegación. Por eso, en condiciones normales, no es necesario pedir un correo cada vez que se visita la web.
La comprobación de permisos se hace en el servidor. El navegador nunca recibe las claves utilizadas para consultar el listado de miembros ni tiene capacidad para decidir quién es administrador.
Un calendario mensual pensado para responder
La pantalla principal es un calendario mensual. Sólo se puede navegar por los meses que contienen eventos del programa, de modo que el usuario no termina perdido en años de páginas vacías.
Los ensayos, conciertos y otros compromisos aparecen en sus fechas. Al seleccionar un día se muestran el título del evento, la hora, el lugar y las notas que haya añadido la dirección. Esas notas admiten Markdown básico, así que pueden contener encabezados, listas, negritas, cursivas o enlaces. Resulta útil para indicar qué obras se trabajarán en un ensayo o qué debe llevar el coro a un concierto.
Cada cantante debe responder expresamente una de estas tres opciones:
- Asistiré.
- Llegaré tarde.
- No podré asistir.
No hay una asistencia afirmativa marcada por defecto. Mientras la persona no elija nada, el evento permanece sin respuesta. Si marca retraso o ausencia, aparece además un campo opcional para poder explicar el motivo o indicar, por ejemplo, a qué hora espera llegar. Tras guardar, la aplicación muestra una confirmación clara.
En la cuadrícula mensual se conserva una señal visual discreta para que cada cantante reconozca sus propias excepciones sin llenar el calendario de texto. Nadie puede ver las respuestas o comentarios de los demás.
El repertorio activo, reunido en una sola página
La sección Repertorio contiene cuatro bloques:
- El listado de obras del programa.
- Las instrucciones de ensayo.
- Los materiales de estudio.
- Las listas de reproducción de Apple Music, Spotify y YouTube.
El listado de obras y las instrucciones admiten Markdown básico. Esto permite que cada coro decida cuánto detalle necesita: desde una lista sencilla hasta un documento con apartados, enlaces y observaciones destacadas.
Los enlaces musicales se muestran con el icono de cada servicio. No es un detalle revolucionario, pero evita dudas y hace que la página se lea de un vistazo, especialmente en el móvil.
Dos formas de gestionar partituras y audios
No todos los coros organizan sus materiales del mismo modo, así que la aplicación ofrece dos modalidades.
La opción más sencilla es usar una carpeta externa. La dirección pega el enlace de Google Drive, Dropbox, OneDrive o cualquier servicio similar. Los cantantes verán un botón para abrirla. En este modo, los permisos y la privacidad de la carpeta dependen del servicio externo.
La segunda opción es guardar los archivos en el mismo servidor de la zona privada. Los PDF y MP3 quedan fuera de la carpeta pública y el servidor sólo los entrega a usuarios con una sesión válida. En Repertorio aparece un navegador de materiales desde el que se pueden abrir o descargar los archivos.
Cuando se usa el servidor privado aparece además la sección Ensayo individual.
Ensayar una voz mientras se sigue la partitura
En Ensayo individual, el cantante elige una obra y encuentra dos cosas en la misma pantalla:
- el reproductor MP3 correspondiente a la cuerda indicada en Mis datos;
- la partitura PDF abierta para poder seguirla mientras escucha.
Si una obra divide una cuerda, por ejemplo Soprano I y Soprano II, se muestran ambos reproductores. Cada persona puede elegir el suyo sin que tengamos que complicar el perfil general del coro con subdivisiones que sólo existen en algunas piezas.
La asociación entre obras y archivos se basa en una convención de nombres previsible. Un ejemplo sería:
Bouzignac - Ave Maria.pdf
Bouzignac - Ave Maria - Soprano.mp3
Bouzignac - Ave Maria - Alto.mp3
Bouzignac - Ave Maria - Tenor.mp3
Bouzignac - Ave Maria - Bajo.mp3
El nombre visible puede ser más breve que el nombre de archivo. Así, en la web puede aparecer «O magnum mysterium» aunque los materiales comiencen por «Victoria - O magnum mysterium». El sistema también ignora diferencias de mayúsculas, minúsculas y acentos al buscar coincidencias.
No es obligatorio preparar este sistema. Un coro que sólo quiera compartir su carpeta habitual puede elegir el enlace externo y olvidarse por completo de las reglas de nombres y del almacenamiento de audios.
Mis datos: sólo lo necesario
Cada cantante dispone de una sección muy pequeña para indicar:
- su nombre;
- su cuerda: Soprano, Alto, Tenor o Bajo;
- si prefiere las partituras en papel o en formato digital.
La cuerda sirve para seleccionar el audio de ensayo y para agrupar los informes. La preferencia de partituras permite saber cuántas copias físicas deben prepararse. El avatar se obtiene de Gravatar cuando existe uno asociado al email; en caso contrario se utiliza una imagen genérica.
La aplicación no intenta convertirse en una base de datos personal exhaustiva. Guarda sólo la información útil para este flujo de trabajo.
La vista de administración
La experiencia cambia cuando entra la dirección del coro. El administrador conserva todas las pantallas normales, pero añade las secciones Administración y Coro.
Para cada evento, el panel muestra cuatro grupos:
- Asistirán.
- Sin respuesta.
- No asistirán.
- Llegarán tarde.
Dentro de cada grupo, las personas aparecen ordenadas por cuerda. Los comentarios de ausencias y retrasos se muestran junto al nombre. Esto permite obtener en segundos la información que antes estaba dispersa en mensajes privados.
Hay una precisión importante: el grupo «Sin respuesta» se calcula a partir de los perfiles que la aplicación ya conoce. Un perfil local se crea cuando una solicitud de acceso autorizada llega a la aplicación. Por tanto, este panel ayuda también a detectar quién todavía no ha empezado a utilizar la zona privada, pero no sustituye por sí solo al censo maestro del coro.
Crear, corregir y comunicar eventos
Desde Administración se pueden crear ensayos, conciertos y otros eventos indicando fecha, hora, lugar y notas. Los eventos existentes se pueden editar o borrar, y la aplicación confirma visualmente cada operación.
Al crear una fecha nueva existe la opción Avisar al coro por email. Está pensada para esos ensayos extraordinarios, misas o actuaciones que aparecen cuando el programa ya está en marcha. El correo informa del nuevo evento y contiene un enlace directo para entrar y responder. En este caso el enlace dura siete días, más que el acceso ordinario que dura 15 minutos, porque puede pasar algún tiempo entre el anuncio y la lectura del mensaje.
La demostración pública no envía correos reales. En una instalación normal, el envío masivo necesita que el sistema de autorización pueda proporcionar también el listado de destinatarios.
Una pequeña ficha del coro
La sección Coro agrupa a los usuarios conocidos por Soprano, Alto, Tenor, Bajo o Sin cuerda. Junto a cada persona aparecen su email, su preferencia de partituras y el número de respuestas registradas.
En la parte superior hay tres sumatorios: Papel, Digital y Sin partituras. El administrador no se cuenta como cantante, por lo que el resumen sirve directamente para preparar materiales. También es posible eliminar un perfil duplicado u obsoleto; al hacerlo se borran sus respuestas y sus sesiones locales.
Del programa actual al siguiente
La aplicación está organizada alrededor de un programa activo, que suele corresponder a unos meses de ensayos y a uno o varios conciertos. Cuando termina, la dirección puede iniciar un programa nuevo desde el panel.
La operación borra el repertorio, los eventos y las respuestas del ciclo anterior, pero conserva los perfiles, las cuerdas, las preferencias de partituras y las sesiones. Antes de ejecutarla se pide confirmación, porque está pensada como un cambio deliberado de etapa, no como un botón de limpieza cotidiana.
También puede cambiarse el nombre del programa, la descripción y el logotipo del coro sin tocar el código.
Privacidad por diseño
La regla fundamental es muy sencilla:
Un cantante sólo puede leer y modificar sus propias respuestas. Un administrador puede consultar y gestionar el conjunto.
Esta separación no depende de ocultar botones en la pantalla. Se aplica también en las rutas del servidor. Los materiales privados exigen sesión, las cookies de acceso son HttpOnly, las claves permanecen en el servidor y la instalación de producción debe utilizar HTTPS.
La aplicación no sustituye una política de protección de datos ni elimina la necesidad de hacer copias de seguridad. Sí intenta recopilar únicamente lo necesario y evitar que las ausencias de una persona se conviertan en información pública para el resto del coro.
Una demostración que se puede tocar
La aplicación puede probarse en privado.arsmvsica.com usando este email:
fecorem@fecorem.es
Ese usuario entra directamente, sin recibir correo, y obtiene una vista de administrador con un programa ficticio, calendario, cantantes de distintas cuerdas, respuestas de asistencia y materiales reales de ensayo. Los datos de la demostración están aislados de los datos de Ars Mvsica, así que se pueden editar sin miedo.
Segunda parte: cómo instalarlo en otro coro
A partir de aquí el contenido es exclusivamente técnico. Esta parte déjasela a un desarrollador o a tu IA de confianza 😅
Qué hay realmente en GitHub
El repositorio público emilcar74/gestion-de-coros contiene la aplicación completa bajo licencia MIT:
- un servidor escrito para Node.js 20 o posterior;
- la interfaz web adaptable a ordenador y móvil;
- un archivo de datos JSON para instalaciones pequeñas;
- una plantilla de variables de entorno;
- una configuración inicial para Render;
- documentación sobre materiales protegidos;
- y una guía específica para sustituir la autenticación de Ghost.
No es un tema de Ghost ni una página estática. Es una aplicación independiente con servidor propio. Puede convivir con la web pública del coro en un subdominio como privado.ejemplo.org, pero su funcionamiento no depende de que esa web pública use Ghost, WordPress u otro gestor.
Tampoco puede publicarse tal cual en GitHub Pages, porque necesita ejecutar código en el servidor, guardar datos, crear sesiones y enviar emails.
Las decisiones que hay que tomar antes de instalar
Una instalación empieza mejor respondiendo a siete preguntas:
- ¿En qué dominio o subdominio estará la zona privada?
- ¿Dónde se ejecutará Node.js y dónde se guardarán los datos persistentes?
- ¿Cuál será la fuente de usuarios autorizados?
- ¿Qué direcciones tendrán permisos de administrador?
- ¿Qué servicio enviará los enlaces mágicos?
- ¿Los materiales estarán en Drive o en el servidor privado?
- ¿Qué nombre, logotipo, textos y colores identifican al coro?
Con esas respuestas, un desarrollador o una IA puede realizar la adaptación sin tener que rediseñar el producto.
Opción 1: una plataforma Node gestionada
Es la ruta más cómoda para quien no quiere administrar un servidor completo. Servicios como Render y otras plataformas compatibles con aplicaciones Node se ocupan del proceso, del certificado HTTPS y del reinicio de la aplicación.
El repositorio incluye render.yaml, que sirve como punto de partida para crear el servicio. Sigue siendo necesario configurar las variables secretas y utilizar almacenamiento persistente para que los datos no desaparezcan en un nuevo despliegue.
En términos generales, el proceso es:
- Crear una copia o fork del repositorio en GitHub.
- Conectar el repositorio a la plataforma elegida.
- Crear un servicio web Node con
npm startcomo comando de inicio. - Montar un disco o volumen persistente.
- Introducir las variables de entorno.
- Asociar el subdominio y comprobar que HTTPS funciona.
- Probar por separado el acceso de un cantante y el de un administrador.
La comodidad de esta modalidad suele tener un coste mensual, especialmente cuando se necesita disco persistente para datos y materiales.
Opción 2: un VPS propio
La instalación original funciona en un VPS de Hetzner, pero serviría igualmente un servidor equivalente de otros proveedores. Esta opción ofrece más control y puede resultar económica si el coro o su director ya dispone de un VPS.
El servidor necesita:
- Node.js 20 o posterior;
- una copia del repositorio;
- una carpeta persistente para
db.jsony el registro de auditoría; - opcionalmente, otra carpeta para PDF y MP3;
- un servicio de sistema que mantenga la aplicación activa;
- y un proxy como Caddy o Nginx que publique el subdominio mediante HTTPS.
En producción conviene ejecutar la aplicación con un usuario sin privilegios, limitar los permisos de las carpetas, abrir únicamente los puertos necesarios y automatizar copias de seguridad de los datos y los materiales.
Esta vía requiere algunos conocimientos de administración de sistemas, pero es directa y no depende de un panel propietario.
¿Y un alojamiento compartido tradicional?
Sólo es adecuado si permite ejecutar de forma permanente una aplicación Node, definir variables de entorno y conservar archivos fuera de la carpeta pública. Muchos alojamientos compartidos están pensados exclusivamente para PHP o para páginas estáticas y no cumplen esas condiciones.
Este proyecto no mantiene una versión PHP. Si un proveedor sólo ofrece PHP, habría que portar el servidor o elegir otro alojamiento. Es una adaptación posible, pero ya no sería una instalación directa del repositorio.
Configuración básica
El repositorio incluye .env.example. En una instalación Node, la configuración gira alrededor de estas variables:
PORT=3010
APP_BASE_URL=https://privado.ejemplo.org
APP_NAME="Nombre del coro"
APP_SECRET=una-cadena-larga-y-aleatoria
ADMIN_EMAILS=director@ejemplo.org
DEV_AUTH=false
RESEND_API_KEY=re_xxxxxxxxxxxxxxxxx
MAIL_FROM="Nombre del coro <acceso@correo.ejemplo.org>"
DATA_DIR=/ruta/persistente/datos
MEDIA_DIR=/ruta/persistente/materiales
Si se utiliza Ghost se añaden su URL, la clave de la API de administración y la etiqueta que identifica a los cantantes:
GHOST_API_URL=https://www.ejemplo.org
GHOST_ADMIN_API_KEY=id:secreto
GHOST_ACCESS_LABEL=cantante
APP_SECRET, las claves de Ghost y Resend y cualquier credencial del servidor deben permanecer fuera de Git. El archivo .env ya está excluido del repositorio, pero cada instalación debe comprobarlo antes de publicar cambios.
Autenticación: Ghost es una opción, no una obligación
Ars Mvsica ya tenía un blog Ghost y sus miembros estaban registrados allí. Por eso, la implementación actual hace lo siguiente:
- las direcciones incluidas en
ADMIN_EMAILSentran como administradores; - los demás usuarios deben existir en Ghost Members;
- y deben tener una etiqueta concreta, en nuestro caso
cantante.
La consulta se realiza desde el servidor mediante la API Admin de Ghost. La clave nunca se envía al navegador.
Sin embargo, la aplicación sólo necesita resolver esta decisión:
Dado un email, ¿esta persona está denegada, es cantante o es administradora?
Por eso la documentación incluye una guía específica de adaptación, escrita para que pueda seguirla tanto un desarrollador como una IA.
Las alternativas propuestas son:
- Un archivo TXT, con una dirección autorizada por línea. Es la opción más elemental.
- Un CSV, con email, nombre, cuerda, rol y estado activo. Probablemente sea la solución más razonable para muchos coros pequeños.
- SQLite, si se quiere mantener todo en el mismo servidor y, más adelante, editar usuarios desde un panel.
- Supabase o PostgreSQL, cuando se necesita una base de datos externa o se prevé más crecimiento.
- Google, Microsoft, Auth0, Clerk u otro sistema OAuth, cuando el coro pertenece a una institución que ya dispone de identidad corporativa.
Hay que expresarlo con precisión: Ghost funciona hoy de serie; las demás opciones están diseñadas y documentadas como adaptaciones, pero todavía no son selectores instalables con un clic. La guía explica qué funciones cambiar, qué contrato devolver y qué comprobaciones de privacidad no deben debilitarse.
Además, si se quiere usar el aviso masivo de nuevos eventos, la fuente elegida debe ofrecer dos operaciones: autorizar un email concreto y obtener el listado de destinatarios activos. Una adaptación de Ghost a CSV, por ejemplo, debe sustituir ambas cosas.
Los enlaces mágicos pueden mantenerse con cualquier listado
Cambiar Ghost por un TXT o una base de datos no obliga a implantar contraseñas. Son dos responsabilidades distintas:
- la fuente de usuarios decide quién puede entrar y con qué rol;
- el enlace mágico demuestra que la persona controla ese email y crea su sesión.
El envío actual utiliza Resend. Para ponerlo en marcha hay que verificar un dominio o subdominio remitente, crear una clave de API y configurar RESEND_API_KEY y MAIL_FROM. Un desarrollador puede sustituir Resend por SMTP u otro proveedor, pero debe conservar la caducidad de los enlaces, su uso único y los mensajes de error.
Elegir el sistema de materiales
Para usar Google Drive, Dropbox o un servicio similar basta con seleccionar la modalidad externa y pegar el enlace. Es la configuración recomendada para empezar: reduce trabajo, evita gestionar espacio de almacenamiento y conserva los hábitos que el coro ya tenga.
Para activar Ensayo individual se elige Servidor privado, se crea una carpeta para el programa y se suben allí los PDF y MP3. La estructura recomendada es:
MEDIA_DIR/
rehearsal/
nombre-del-programa/
Autor - Obra.pdf
Autor - Obra - Soprano.mp3
Autor - Obra - Alto.mp3
Autor - Obra - Tenor.mp3
Autor - Obra - Bajo.mp3
Después, en el panel se indica el nombre de la carpeta y el listado de obras. Si el título visible y el nombre base de los archivos son distintos, se separan con una barra vertical:
O magnum mysterium | Victoria - O magnum mysterium
La aplicación no convierte audios ni genera grabaciones. Espera encontrar archivos PDF y MP3 ya preparados. A cambio, ofrece una experiencia de estudio directa y protege la descarga mediante la misma sesión del usuario.
Personalización visual y funcional
Desde el panel se puede cambiar el logotipo. El nombre del coro y el texto de entrada se encuentran al principio de public/app.js; los colores y la composición viven en public/styles.css.
Una personalización normal puede incluir:
- nombre y logotipo;
- texto de bienvenida;
- colores y tipografías;
- tipos de evento;
- nombres de las cuerdas;
- duración de sesiones y enlaces;
- proveedor de email;
- fuente de usuarios;
- y estructura de los materiales.
Si un coro utiliza otras cuerdas, necesita varios administradores o quiere conservar un histórico de programas, conviene indicarlo al comienzo. Son cambios razonables, pero afectan al modelo de datos o a la interfaz y deben diseñarse de forma consciente.
Instrucciones pensadas también para trabajar con una IA
Una de las decisiones deliberadas del proyecto ha sido escribir documentación que no presuponga que quien instala conoce su código. El archivo README.md explica la arquitectura y las variables principales. docs/AUTHENTICATION.md define el contrato de autorización, enumera los puntos que se pueden sustituir y señala las reglas que nunca deben romperse.
Al pedir ayuda a una IA, es mejor no limitarse a «instálame esto». Un encargo útil podría ser:
Quiero desplegaremilcar74/gestion-de-corospara mi coro. Usaréprivado.midominio.org, un VPS con Ubuntu y Resend. No tengo Ghost: quiero autorizar usuarios desde un CSV con email, nombre, cuerda, rol y estado activo. Adapta también el envío colectivo de nuevos eventos, conserva los enlaces mágicos y no permitas que un cantante vea respuestas ajenas. Antes de modificar nada, revisaREADME.mdydocs/AUTHENTICATION.mdy dime qué datos te faltan.
Ese mensaje proporciona alojamiento, dominio, email y autenticación, y recuerda explícitamente la frontera de privacidad.
Las preguntas que una IA o un desarrollador deberían hacer antes de empezar son:
- ¿Cuál es el dominio definitivo y quién controla su DNS?
- ¿Qué sistema operativo o plataforma ejecutará la aplicación?
- ¿Dónde persistirán
db.json, el registro de auditoría y los materiales? - ¿Quiénes son administradores y de dónde sale el censo de cantantes?
- ¿Cómo se enviarán los enlaces mágicos y los avisos colectivos?
- ¿Qué cuerdas y preferencias debe admitir el perfil?
- ¿Se usará carpeta externa o servidor privado?
- ¿Debe mantenerse la demostración pública o eliminarse?
- ¿Cómo se harán y restaurarán las copias de seguridad?
- ¿Qué pruebas demostrarán que un cantante nunca recibe datos de otro?
Copias de seguridad y crecimiento
La versión actual guarda la información en data/db.json, o en la carpeta indicada mediante DATA_DIR. Para un coro pequeño y un único administrador es una solución comprensible y suficiente. La copia de seguridad debe incluir ese archivo, el registro de auditoría si se quiere conservar y la carpeta de materiales cuando se aloje en el servidor.
Si aumentan el número de usuarios, los administradores o las escrituras simultáneas, el siguiente paso lógico es migrar a SQLite o PostgreSQL. El proyecto no pretende negar ese camino; simplemente empieza por la solución más pequeña que resuelve el problema real.
Antes de anunciar una instalación al coro completo conviene probar al menos estos casos:
- acceso permitido y acceso denegado;
- sesión de cantante y sesión de administrador;
- respuesta de asistencia y comentario;
- comprobación de que otro cantante no puede verla;
- creación, edición y borrado de eventos;
- envío de un aviso colectivo de prueba;
- apertura de materiales desde una sesión válida y rechazo sin sesión;
- reinicio de la aplicación sin pérdida de datos;
- y restauración de una copia de seguridad.
Qué es y qué no es este proyecto
Gestión de coros no es un ERP, no cobra cuotas, no gestiona contabilidad y no pretende reemplazar todas las herramientas que utiliza una agrupación. Tampoco obliga a abandonar Drive, el blog público ni las listas de reproducción existentes.
Es una capa privada y ligera que reúne el programa activo, el calendario, la asistencia y el estudio individual. Su valor está precisamente en que intenta hacer pocas cosas, pero hacerlas de acuerdo con la vida real de un coro.
El código está abierto para que otros directores, desarrolladores y comunidades lo prueben, lo adapten y propongan mejoras. Ojalá de ahí salgan autenticaciones más sencillas, mejores sistemas de instalación, históricos de programas y cualquier otra idea que resulte útil sin convertir la herramienta en algo pesado.
Nosotros ya hemos dejado de reconstruir ausencias entre mensajes y de explicar cada semana dónde están las partituras. Si esta pequeña solución le ahorra a otro coro una parte de ese trabajo, habrá cumplido de sobra su propósito.
