Aloje Kisuno por su cuenta

Qué necesita

Para Kisuno necesita una máquina Ubuntu con Docker Engine y Compose v2, un registro DNS que apunte a ella y una clave API de su pasarela de modelos. El stack funciona por completo en este único host, ya que la carga de cálculo de los modelos de lenguaje recae en el proveedor de inferencia.

Servidor y requisitos del sistema

El mínimo son 2 vCPU, 4 GB de RAM, 40 GB de disco y Ubuntu 22.04 LTS. Para el uso productivo se recomiendan 4 vCPU, 16 GB de RAM y 200 GB de disco en Ubuntu 24.04 LTS; el reparto según el tamaño del equipo figura en la tabla siguiente. El entorno aislado de código reforzado requiere además virtualización anidada.

Bajo carga crece prácticamente solo la memoria de la aplicación de chat, mientras que el uso de CPU se mantiene cercano a cero. Las imágenes ocupan una sola vez entre 5 y 6 GB y se comparten entre instancias de la misma máquina. Después crecen sobre todo los archivos subidos: el primer límite en la operación es el espacio en disco.

Qué no necesita

• Nada de Kubernetes. Docker Compose es la arquitectura soportada; no se incluye ningún chart de Helm.
• Ninguna GPU para la capa de aplicación. Solo necesita hardware GPU quien además quiera ejecutar modelos de lenguaje en local.
• Ninguna cuenta con nosotros. La instalación se realiza sin registro, sin clave de licencia y sin servidor de licencias.
• Ningún hyperscaler ni base de datos gestionada. Basta cualquier VM Ubuntu; base de datos e índice de búsqueda funcionan en el mismo stack.

Instalación en tres pasos

La instalación de Kisuno consta de dos scripts y una entrada en el archivo .env. En una máquina en la que Docker ya está en marcha, el primer paso no es necesario.

Paso 1: preparar el servidor

El repositorio de GitHub llegará en breve. Quien quiera empezar ya hoy solicita un acceso a la instancia gestionada a través del formulario. Los comandos muestran cómo es la instalación después: clonar el repositorio, cambiar al directorio distribution y ejecutar el script de preparación.

cd distribution
./setup-server.sh

El script es idempotente e instala Docker Engine junto con Compose v2 desde la fuente oficial de Docker, ya que el paquete de Ubuntu docker.io no incluye Compose v2. A ello se suman la rotación de registros, reglas de cortafuegos para los puertos 22, 80 y 443, swap, zona horaria y actualizaciones de seguridad automáticas. Después hay que volver a iniciar sesión una vez.

Paso 2: instalar el stack

./install.sh --profiles production

El instalador comprueba Docker y Compose v2, crea el archivo .env a partir de la plantilla, genera todos los secretos, crea los directorios de datos y la red del entorno aislado, descarga las imágenes e inicia el stack. El perfil production incluye el proxy inverso, que obtiene automáticamente el certificado TLS.

Paso 3: registrar el acceso al modelo

# .env
MODEL_API_KEY=<euer-api-key>

docker compose up -d

Sin clave el stack arranca igualmente, pero el chat informa de que falta una clave API. El acceso es de libre elección, porque Kisuno se comunica con cualquier pasarela compatible con OpenAI. En la instancia gestionada ofrecemos los modelos actuales de OpenAI (ChatGPT) y Anthropic (Claude); se ejecutan en el centro de datos de AWS en Fráncfort. AWS es una empresa estadounidense, por lo que el US CLOUD Act se aplica incluso con servidores en Fráncfort, y lo decimos abiertamente. Para clientes con altos requisitos de protección de datos están disponibles modelos abiertos de primer nivel como GLM, Kimi y DeepSeek, operados por empresas europeas en servidores en Europa; allí el US CLOUD Act no se aplica. En el self-hosting, usted elige por sí mismo cada proveedor de esta cadena y registra su propio endpoint.

De qué servicios se compone el stack

El stack se basa en un archivo docker-compose.yml; varios servicios están detrás de perfiles opcionales y solo arrancan si usted los activa. Cada servicio es un proyecto de código abierto conocido y puede inspeccionarse, sustituirse o desactivarse por separado.

La aplicación de chat se basa en LibreChat bajo licencia MIT y aporta la interfaz, las cuentas, las conversaciones, la subida de archivos y la conexión con los modelos. Kisuno mantiene esta parte cerca del upstream para que las actualizaciones de seguridad del proyecto sigan siendo adoptables.

MongoDB almacena conversaciones, cuentas, roles y ajustes, como contenedor dentro del mismo stack y en su disco. No existe ningún servicio de base de datos externo hacia el que pudieran fluir contenidos.

Meilisearch proporciona la búsqueda de texto completo en las propias conversaciones. El índice se encuentra en local y puede reconstruirse; la telemetría de Meilisearch viene desactivada de fábrica.

La API de RAG con pgvector es opcional y se añade mediante el perfil filesearch. La API de RAG genera los embeddings de los archivos que los usuarios suben al chat y devuelve al modelo los pasajes pertinentes al responder.

La pasarela MCP se sitúa entre la aplicación de chat y cada sistema conectado y decide en cada llamada a una herramienta si está permitida. La evaluación sigue este orden: usuario individual, rol, grupo, valor predeterminado del servidor. Cada llamada queda registrada y, si falla la comprobación, el acceso se deniega.

El panel de administración es la interfaz para usuarios, roles, grupos, reglas de acceso, registro de auditoría y presupuesto. Forma parte del stack, escucha solo en local y desde el exterior únicamente es accesible a través del proxy inverso.

El entorno aislado de código ejecuta el código generado por el modelo, de modo que una solicitud se convierta en un archivo real descargable. Se despliega al lado como stack de Compose propio y se conecta mediante una red Docker propia. Hay dos backends a elegir: uno ligero como opción predeterminada y otro reforzado basado en una microVM, que requiere virtualización anidada en el host. Un proxy de salida con lista de autorización está en curso.

SearXNG proporciona la búsqueda web desde su propio stack, sin cuenta en ningún servicio de búsqueda. Dicho con franqueza: SearXNG transmite los términos de búsqueda a buscadores externos, sin comunicar la identidad del usuario. Las conversaciones y los archivos no salen de la máquina.

Caddy termina el TLS, obtiene los certificados automáticamente en cuanto el registro DNS apunta a la máquina y es el único servicio en los puertos 80 y 443. Para la operación detrás de un WAF o con una autoridad de certificación interna se incluyen variantes.

Tres modelos de operación, una sola arquitectura

Hay tres modelos de operación y una única arquitectura: operado por usted, en su nube, opcionalmente a través de su proveedor de IT, o gestionado por nosotros. El stack es el mismo en los tres casos. Solo cambia quién tiene root, quién administra las claves y quién ejecuta actualizaciones y copias de seguridad.

Operado por usted

Usted opera la máquina, mantiene root, administra sus claves y realiza por su cuenta actualizaciones y copias de seguridad. El software no cuesta nada; una suscripción de soporte es opcional. Este modelo es la referencia: lo que un administrador externo consigue levantar con dos comandos sostiene también los demás modelos.

En su nube

Kisuno funciona en cualquier VM Ubuntu, tanto en el propio centro de datos como en un proveedor de nube suizo o europeo. No existe vinculación con ningún hyperscaler. Quien aloja como proveedor de IT para sus clientes utiliza la misma arquitectura: un stack por cliente.

Gestionado por nosotros

Nos encargamos de la instalación, las actualizaciones, las copias de seguridad y la supervisión, y operamos la instancia en centros de datos certificados según ISO 27001 de Green en Lupfig, Suiza. Los certificados corresponden a Green, no a Kisuno; la certificación ISO 27001 propia de Kisuno está en curso.

Varias instancias en una máquina

El límite entre inquilinos es el stack de Compose, no la VM: cada instancia tiene su propia base de datos, su propio índice de búsqueda, sus propios archivos subidos, sus propios secretos, su propia red Docker y su propio entorno aislado de código. Por eso, para equipos pequeños, de tres a cinco instancias pueden compartir la misma VM.

Pueden compartirse las imágenes de Docker y un proxy inverso común. Nunca se comparten la base de datos, los archivos subidos, los secretos, la red del entorno aislado y la clave del proveedor de modelos: una clave compartida hace imposible atribuir el consumo por inquilino, y una red de entorno aislado compartida elimina la separación justo donde se ejecuta código ajeno.

Cómo funcionan las actualizaciones y qué cuenta en la operación

Las actualizaciones son reproducibles porque la imagen de la aplicación está fijada a un digest en lugar de a una etiqueta móvil y los demás servicios funcionan con versiones fijas. Una publicación de Kisuno es, por tanto, una combinación probada de imagen de aplicación y servicios, y dos instancias en la misma máquina pueden funcionar con versiones distintas.

git pull
./backup.sh backup
./install.sh --migrate

La opción --migrate deja intacto el archivo .env y reconstruye los servicios propios. Antes de cada actualización corresponde una copia de seguridad y, después, una breve prueba funcional. La vuelta atrás se realiza mediante la versión anterior del archivo Compose.

En la operación diaria hay dos aspectos importantes: la rotación de registros que configura setup-server.sh y el espacio en disco, con una alerta a partir del 70 por ciento de ocupación. Las preguntas recurrentes sobre operación, actualizaciones y copias de seguridad se responden en las preguntas frecuentes.

Un script para copia de seguridad, restauración y traslado

Un único script cubre la copia de seguridad, la restauración y el traslado de servidor: backup.sh genera un archivo comprimido a partir del volcado de la base de datos, del archivo .env y de los archivos subidos, y también lo restaura. Un traslado consiste, pues, en una copia de seguridad en el servidor antiguo, la copia del archivo y la restauración en el nuevo.

./backup.sh backup            # Archiv erzeugen
./backup.sh list              # vorhandene Archive
./backup.sh restore <archiv>  # ersetzt die Datenbank, fragt vorher nach

El archivo contiene secretos y conversaciones y se guarda con permisos de archivo restrictivos. Nunca debe acabar en un repositorio ni, sin cifrar, en una nube ajena. El índice de búsqueda no se incluye en la copia, porque puede reconstruirse a partir de la base de datos.

El error más caro en un traslado es dejar que se regeneren las claves de cifrado en lugar de tomarlas del antiguo archivo .env. Después, todas las credenciales almacenadas en la base de datos resultan ilegibles. Con los valores heredados, el traslado sigue siendo una ventana de mantenimiento de 15 a 30 minutos.

Dos reglas de la práctica: replicar el destino de la copia de seguridad fuera de la máquina y probar la restauración al menos una vez.

Licencia: qué significa MIT en la práctica

Kisuno se publicará bajo licencia MIT en breve; la aplicación de chat subyacente LibreChat ya lo está hoy. El autoalojamiento es gratuito, desde un solo usuario y sin registrarse con nosotros. Qué significa esto en detalle y por qué es la diferencia decisiva en la comparación con otras plataformas:

• Sin límite de puestos. Que trabajen 3 o 300 personas en la instancia no cambia nada en la licencia.
• Sin marca obligatoria. Nombre, logotipo y colores son configuración, también para el uso comercial.
• Sin restricción de funciones. Gestión de permisos, registro de auditoría, presupuestos y conexiones a sistemas proceden de la misma fuente abierta.
• Código fuente abierto. La base LibreChat ya es hoy de consulta pública; stack, scripts y servicios se publicarán bajo licencia MIT en breve y entonces podrán consultarse, bifurcarse y verificarse, en lugar de descansar sobre una promesa.

Comercialmente sostenemos el modelo con la operación y el acompañamiento, no con las licencias. Por eso también está abierto el camino de vuelta del funcionamiento gestionado al autoalojado: la misma arquitectura, el mismo archivo.

Preguntas frecuentes sobre el autoalojamiento