El hosting de Koha es la infraestructura donde corre la instancia: el servidor, la base de datos, el motor de búsqueda, los respaldos y las actualizaciones. Koha no cobra licencia, pero sí necesita un servidor encendido las 24 horas y alguien que lo mantenga. La decisión real no es «nube o servidor propio», sino quién asume la operación: un proveedor que responde por disponibilidad y respaldos, o el área de tecnología de la institución.
Esta es la pregunta que más se repite en las cotizaciones que recibimos: con hosting o sin hosting. A continuación están los dos escenarios comparados, los requisitos mínimos de servidor por tamaño de colección y la lista de lo que hay que exigirle a cualquier proveedor.
Qué incluye realmente el hosting de Koha
Cuando una propuesta dice «hosting incluido», eso debería cubrir siete cosas. Si alguna falta, el costo simplemente se traslada al equipo interno de la universidad.
- Servidor y sistema operativo: la máquina virtual, su dimensionamiento y los parches de seguridad del sistema.
- La pila de Koha: Perl y sus dependencias, MariaDB o MySQL, el servidor web y el motor de indexación (Zebra o Elasticsearch).
- Dominio y certificado TLS: el OPAC público y la interfaz del personal deben servirse por HTTPS con renovación automática del certificado.
- Respaldos: copia de la base de datos y de los archivos de configuración, con retención definida y, sobre todo, con pruebas de restauración.
- Monitoreo: alertas de caída, de disco lleno y de procesos de indexación detenidos.
- Actualizaciones: aplicación de versiones de mantenimiento y planificación de los saltos de versión mayor.
- Correo saliente: Koha envía avisos de vencimiento, reservas disponibles y recuperación de contraseña; si el correo no está bien configurado, esa funcionalidad no existe en la práctica.
El correo saliente es el punto que más se subestima. Un servidor recién levantado casi siempre termina en la carpeta de spam del dominio institucional hasta que se configuran los registros de autenticación del remitente.
Nube gestionada o servidor propio: tabla de decisión
Ninguno de los dos modelos es mejor en abstracto. Depende de si la institución tiene un equipo de infraestructura con capacidad real de atender el servicio y de cuán estrictas sean sus políticas de datos.
| Criterio | Nube gestionada | Servidor propio |
|---|---|---|
| Costo | Cuota mensual o anual previsible, sin inversión inicial en hardware | Inversión inicial en equipo más energía, refrigeración y horas del personal de TI |
| Mantenimiento | Lo asume el proveedor: parches, servicios, indexación, disco | Lo asume la institución; requiere alguien con conocimiento de Linux y de Koha |
| Actualizaciones | Planificadas por el proveedor, con ambiente de pruebas previo | Suelen postergarse; es la causa habitual de instancias con versiones de varios años |
| Respaldos | Automáticos y fuera del mismo servidor, con retención pactada | Dependen de la política interna; con frecuencia se guardan en la misma máquina |
| Disponibilidad | Centro de datos con energía y conectividad redundantes | Sujeta a la red y a la energía del campus; los cortes afectan el OPAC público |
| Seguridad | Endurecimiento del servidor, TLS y parches de seguridad como parte del servicio | Control total, pero también responsabilidad total sobre cortafuegos y parches |
| Control de los datos | Los datos viven en infraestructura de un tercero; exige contrato y cláusula de portabilidad | Los datos no salen de la institución; es el argumento decisivo en políticas estrictas |
| Soporte | Un solo responsable para el sistema y la infraestructura | Responsabilidad repartida entre TI y el proveedor del software, con riesgo de zonas grises |
Hay un punto intermedio que funciona bien en universidades con políticas de datos estrictas: el servidor es de la institución —físico o en su propia nube— y la administración de Koha la hace el proveedor por acceso remoto. Los datos nunca salen del perímetro institucional y la operación queda a cargo de quien conoce el sistema. Es el modelo que usamos cuando el área de tecnología exige que la máquina esté bajo su control.
Requisitos mínimos de servidor según el tamaño de la colección
Koha es una aplicación Perl sobre MariaDB o MySQL con un motor de indexación aparte. Eso significa que se dimensionan dos consumidores de memoria, no uno. Estos son los tamaños que funcionan en operación real, no los mínimos absolutos de instalación:
| Colección | vCPU | RAM | Disco SSD | Motor de búsqueda |
|---|---|---|---|---|
| Hasta 20.000 registros, 1 sede | 2 | 4 GB | 40 GB | Zebra |
| 20.000 a 80.000 registros, 2 o 3 sedes | 2 a 4 | 8 GB | 80 GB | Zebra |
| 80.000 a 300.000 registros | 4 | 8 a 16 GB | 160 GB | Zebra o Elasticsearch |
| Más de 300.000 registros o alta concurrencia | 4 a 8 | 16 a 32 GB | 250 GB o más | Elasticsearch, preferiblemente en su propio nodo |
Dos aclaraciones sobre el disco. La base de datos de un catálogo universitario típico ocupa pocos gigabytes; lo que consume espacio son los índices, los respaldos acumulados y los archivos adjuntos como portadas o PDF. Y conviene que el disco sea SSD: la reindexación completa de un catálogo grande sobre disco mecánico puede pasar de minutos a horas.
Zebra o Elasticsearch
Koha trae Zebra como motor de búsqueda por defecto y funciona perfectamente para la inmensa mayoría de las bibliotecas universitarias de la región. Elasticsearch es la alternativa: mejora el manejo de facetas, la relevancia y la búsqueda tolerante a errores de escritura, pero sube el piso de hardware de forma notable, porque es un servicio Java que conviene dimensionar con al menos 8 GB de memoria para sí mismo, además de lo que ya consumen Koha y la base de datos.
La recomendación práctica: si la colección está por debajo de los 100.000 registros y nadie se ha quejado de la búsqueda, quédate con Zebra. Elasticsearch se justifica cuando hay un catálogo grande, mucha consulta simultánea o requisitos de facetado que Zebra no cubre. El cambio de motor se hace en cualquier momento ajustando la configuración y reindexando; no es una decisión irreversible, pero tampoco es gratis.
Respaldos, disponibilidad y SLA
Un respaldo que nunca se ha restaurado no es un respaldo. Estos son los parámetros que conviene dejar escritos en el contrato:
- Frecuencia: copia diaria de la base de datos como mínimo; en bibliotecas con circulación intensa, copia diaria más respaldo incremental.
- Retención: entre 15 y 30 días es lo razonable para una biblioteca; más allá, el costo de almacenamiento crece sin aportar valor.
- Ubicación: fuera del servidor de producción. Un respaldo guardado en el mismo disco no protege de nada.
- Prueba de restauración: al menos una vez al año, documentada.
- RTO y RPO: cuánto tiempo puede estar caído el servicio y cuántas horas de datos se pueden perder en el peor caso. Son las dos cifras que de verdad importan.
- Disponibilidad comprometida: un 99,5 % mensual equivale a unas 3,6 horas de indisponibilidad al mes; un 99,9 %, a unos 43 minutos. Conviene escoger el nivel según si el OPAC es crítico en época de exámenes.
- Ventanas de mantenimiento: acordadas fuera del horario académico y avisadas con antelación.
Dominio, TLS y acceso
El OPAC debería vivir en un subdominio de la universidad —del tipo catalogo.universidad.edu— y no en un dominio del proveedor. Es una decisión de marca y de continuidad: si algún día cambias de proveedor, el enlace que está impreso en las guías de clase y enlazado desde la web institucional sigue funcionando. Técnicamente solo requiere que la institución apunte un registro DNS al servidor.
El certificado TLS debe renovarse solo. La interfaz del personal conviene publicarla en un subdominio distinto del OPAC y, cuando la política de seguridad lo permita, restringirla por red o por VPN. Si la universidad usa directorio corporativo, Koha se integra con LDAP y Active Directory, y también con CAS, SAML y proveedores OpenID Connect, lo que evita mantener un segundo juego de contraseñas.
Qué preguntarle a un proveedor de hosting de Koha
- ¿Qué versión de Koha instalas y cada cuánto aplicas las versiones de mantenimiento?
- ¿El servidor es exclusivo para mi instancia o es compartido con otras bibliotecas?
- ¿Cuál es la frecuencia, la retención y la ubicación de los respaldos, y cuándo fue la última prueba de restauración?
- ¿Qué disponibilidad mensual comprometes y qué pasa si no se cumple?
- ¿Cuál es el tiempo de respuesta para un incidente crítico —el OPAC caído— frente a una solicitud normal?
- Si decido irme, ¿me entregas el volcado completo de la base de datos y los archivos de configuración, en qué plazo y con qué costo?
- ¿El dominio y el certificado quedan a nombre de la institución?
- ¿El soporte incluye preguntas de uso del sistema o solo incidentes de infraestructura?
La sexta pregunta es la más importante y la que menos se hace. Koha es software libre y tus datos son tuyos: cualquier proveedor serio debe poder entregarte una copia íntegra sin discusión. Si esa respuesta es ambigua, estás frente al mismo bloqueo de proveedor que motivó salir de un sistema propietario, tal como se explica en Koha frente a un sistema propietario.
Cuándo conviene cada modelo
Elige nube gestionada si el equipo de tecnología no tiene disponibilidad para atender un servicio adicional, si la biblioteca necesita el OPAC en línea de forma continua, si quieres un costo previsible o si vienes de una instancia que nunca se actualizó porque no hubo quién la mantuviera —un escenario que tratamos en cómo actualizar Koha sin perder datos.
Elige servidor propio si la política institucional exige que los datos permanezcan dentro del campus, si ya existe infraestructura virtualizada con respaldos formales y personal de Linux, o si Koha debe integrarse con sistemas internos que no están expuestos hacia afuera.
En ambos casos el software es exactamente el mismo y la migración entre modelos es viable, porque se reduce a mover una base de datos y unos archivos de configuración. Si estás planificando el proyecto completo, revisa también cuánto cuesta implementar Koha en una universidad. Nuestro servicio de Koha se cotiza con hosting y sin hosting, precisamente porque la respuesta correcta depende de la institución.