Tutoriales de VPS
Crear una base de conocimiento privada con AnythingLLM en un VPS (2026): Docker, OpenAI/Ollama, preguntas y respuestas sobre documentos con RAG y guía de despliegue con HTTPS
Este tutorial explica cómo autoalojar AnythingLLM en un VPS y crear una base de conocimiento de IA privada que permite subir PDF, Markdown y contenido web y responder preguntas sobre documentos con RAG. Cubre la elección de la configuración del VPS, el despliegue con Docker, el almacenamiento persistente, la conexión de modelos OpenAI y Ollama, HTTPS con Caddy, los permisos de los espacios de trabajo, la copia de seguridad y actualización, el refuerzo de seguridad y los fallos de conexión habituales.
Últimamente veo a mucha gente que quiere montar "preguntas y respuestas con IA sobre la base de conocimiento interna de la empresa", pero elige mal la herramienta en el primer paso.
Algunos simplemente lanzan los PDF a ChatGPT. Es realmente cómodo, pero los contratos, los datos de clientes y los SOP internos tienen que subirse a una plataforma de terceros. Otros despliegan Dify, que es muy completo, pero si solo quieren que unas pocas personas consulten documentos, el flujo les parece pesado. Otros instalan Open WebUI, que tiene una buena experiencia de chat, pero en la parte de base de conocimiento documental no es necesariamente la entrada más cómoda.
Si tu necesidad es muy concreta:
Subir un lote de documentos y luego dejar que la IA responda preguntas basándose en esos materiales.
AnythingLLM encaja bien.
No es solo una carcasa de chat, ni tampoco una plataforma compleja de desarrollo de aplicaciones de IA. Se parece más a un "backend privado de preguntas y respuestas sobre documentos": creas Workspaces, subes PDF, Markdown, TXT y contenido web, configuras modelos y recuperación vectorial, y luego puedes conversar en torno a esos materiales.
Este artículo lo aborda desde el autoalojamiento en VPS: cómo desplegar, qué tamaño de VPS necesitas, cómo elegir entre OpenAI y Ollama, qué datos debes respaldar obligatoriamente y qué trampas evitar.
No lo instales solo porque una herramienta de IA esté de moda.
Yo lo valoraría así:
| Necesidad | ¿Adecuado para AnythingLLM? | Herramienta más adecuada |
|---|---|---|
| Preguntas y respuestas sobre documentos privados | Adecuado | AnythingLLM |
| Base de conocimiento compartida entre varios usuarios | Adecuado | AnythingLLM Docker |
| Flujos de trabajo de IA complejos | Regular | Dify / n8n |
| Solo chatear con modelos locales | Regular | Open WebUI |
| Unificar varias API de modelos | No adecuado | One-API / New-API / LiteLLM |
| Atención al cliente incrustada en un sitio web | Posible | AnythingLLM Chat Widget |
En una frase: las fortalezas de AnythingLLM son los documentos, los Workspaces, el RAG y el acceso en equipo.
Si solo quieres pedirle a un modelo "ayúdame a escribir un texto", Open WebUI es más directo. Si quieres orquestar toda una aplicación de IA, Dify es más una plataforma. Si quieres meter materiales de la empresa, documentación de productos, tutoriales y plantillas de contratos y consultarlos, AnythingLLM se ajusta más a la necesidad.
Aquí hay que distinguir dos casos.
Esta opción ahorra más recursos del VPS. La inferencia del modelo no se ejecuta en tu VPS; el VPS solo se encarga de:
- El backend web de AnythingLLM
- La subida y el troceado de documentos
- La indexación vectorial
- El inicio de sesión de usuarios y los espacios de trabajo
- La comunicación con las API de LLM externas
Configuración recomendada:
| Uso | Configuración del VPS |
|---|---|
| Pruebas personales | 1 núcleo / 2GB / 20GB SSD |
| Equipo pequeño de 2-5 personas | 2 núcleos / 4GB / 40GB SSD |
| Muchos documentos, varios usuarios | 4 núcleos / 8GB / 80GB SSD |
Si solo te conectas a la API de OpenAI, no necesitas GPU.
Mucha gente, en cuanto oye "herramienta de IA", busca un VPS con GPU, pero no es necesario. Cuando usas modelos en la nube, lo que realmente cuesta dinero son las llamadas a la API, no la potencia del VPS.
Esto es completamente distinto.
Ollama con un modelo pequeño de 7B ya consume bastante memoria. También puede funcionar en CPU, pero no será rápido; sin GPU, la velocidad de generación puede ser tan lenta que sospeches que el servicio está roto.
Mi recomendación:
| Enfoque de modelo | Configuración recomendada |
|---|---|
| Solo AnythingLLM + modelos en la nube | 2 núcleos 4GB es suficientemente cómodo |
| AnythingLLM + modelo pequeño de Ollama | A partir de 4 núcleos 16GB |
| Querer ejecutar modelos locales más grandes | Servidor con GPU o una máquina local con tarjeta gráfica |
Así que no fuerces a un VPS pequeño de 1C1G a ejecutar modelos locales grandes. Que arranque no significa que sea usable; que responda no significa que la experiencia sea buena.
Este artículo usa como ejemplo un VPS con Ubuntu / Debian.
Primero inicia sesión por SSH:
ssh root@your_server_ip
Actualiza el sistema:
apt update && apt upgrade -y
Instala las herramientas básicas:
apt install -y ca-certificates curl gnupg ufw
Comprueba los recursos del sistema:
free -h
df -h
AnythingLLM escucha por defecto en el puerto 3001. Primero confirma que no está ocupado:
ss -tlnp | grep 3001
Si no hay salida, el puerto está libre.
Si el VPS aún no tiene Docker, puedes instalarlo desde el repositorio oficial.
Añade la clave GPG de Docker:
install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | gpg --dearmor -o /etc/apt/keyrings/docker.gpg
chmod a+r /etc/apt/keyrings/docker.gpg
Añade el repositorio de Docker:
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo $VERSION_CODENAME) stable" > /etc/apt/sources.list.d/docker.list
Instala Docker:
apt update
apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
Confirma la versión:
docker --version
docker compose version
El enfoque oficial de despliegue con Docker es muy directo: prepara un directorio persistente y móntalo en el /app/server/storage del contenedor.
Recomiendo poner los datos en /opt/anythingllm:
mkdir -p /opt/anythingllm
cd /opt/anythingllm
touch .env
Ejecuta el contenedor:
docker run -d \
--name anythingllm \
--restart unless-stopped \
-p 3001:3001 \
--cap-add SYS_ADMIN \
-v /opt/anythingllm:/app/server/storage \
-v /opt/anythingllm/.env:/app/server/.env \
-e STORAGE_DIR="/app/server/storage" \
mintplexlabs/anythingllm:latest
Comprueba el estado del contenedor:
docker ps --filter "name=anythingllm"
Consulta los registros:
docker logs anythingllm --tail=100
Accede desde el navegador:
http://your_server_ip:3001
La primera vez se pasa por el asistente de inicialización, se crea la cuenta de administrador y luego se eligen el LLM Provider, el Embedding Provider y la base de datos vectorial.
Si estás más acostumbrado a Compose, puedes escribirlo así.
Crea el directorio:
mkdir -p /opt/anythingllm
cd /opt/anythingllm
touch .env
Crea docker-compose.yml:
services:
anythingllm:
image: mintplexlabs/anythingllm:latest
container_name: anythingllm
restart: unless-stopped
ports:
- "127.0.0.1:3001:3001"
cap_add:
- SYS_ADMIN
environment:
STORAGE_DIR: /app/server/storage
JWT_SECRET: "replace-with-a-long-random-string-at-least-32-chars"
PASSWORDMINCHAR: "10"
DISABLE_TELEMETRY: "true"
volumes:
- /opt/anythingllm:/app/server/storage
- /opt/anythingllm/.env:/app/server/.env
Inicia:
docker compose up -d
Aquí he escrito el puerto como:
127.0.0.1:3001:3001
Esto significa que solo la máquina local puede acceder al 3001, sin exponerlo directamente a internet. Después se usa Caddy como proxy inverso hacia un dominio HTTPS.
Esto es más seguro que abrir 3001 a toda la red.
Supongamos que tu dominio es:
ai.example.com
Añade un registro A en el DNS:
ai.example.com -> your_server_ip
Instala Caddy:
apt install -y debian-keyring debian-archive-keyring apt-transport-https curl
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' > /etc/apt/sources.list.d/caddy-stable.list
apt update
apt install -y caddy
Edita el Caddyfile:
nano /etc/caddy/Caddyfile
Escribe:
ai.example.com {
reverse_proxy 127.0.0.1:3001
}
Comprueba la configuración:
caddy validate --config /etc/caddy/Caddyfile
Recarga:
systemctl reload caddy
Ahora accede a:
https://ai.example.com
Caddy solicita y renueva automáticamente los certificados HTTPS.
Si usas Caddy como proxy inverso, en internet solo hay que abrir SSH, 80 y 443.
ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable
ufw status
No expongas 3001 directamente a internet:
ufw deny 3001/tcp
Si antes tu Docker Compose ya se enlazó a 127.0.0.1:3001:3001, aunque el grupo de seguridad del proveedor de nube abra el 3001 por error, el acceso externo al puerto del contenedor no funcionará.
AnythingLLM es solo el frontend y la base de conocimiento; en sí mismo necesita conectarse a un modelo.
Esta opción sirve para la mayoría de usuarios de VPS.
Ventajas:
- Requisitos bajos de configuración del VPS
- Velocidad de respuesta estable
- No hay que gestionar modelos locales
- Es la opción más sencilla para despliegues de equipos pequeños
Desventajas:
- El contenido de los documentos se envía al proveedor de API correspondiente para su procesamiento
- Hay costes de API
- Depende de la disponibilidad de servicios externos
Si los materiales no son extremadamente sensibles, como documentación pública de productos, FAQ de atención al cliente, contenido de blog o documentos internos de procesos normales, esta opción es más realista.
Adecuada para usuarios que quieren mantener los datos en su propia máquina en la medida de lo posible.
Primero instala Ollama:
curl -fsSL https://ollama.com/install.sh | sh
Descarga un modelo pequeño para probar:
ollama pull llama3.1:8b
Prueba el endpoint:
curl http://127.0.0.1:11434/api/tags
Si AnythingLLM está en Docker, localhost dentro del contenedor se refiere al propio contenedor, no al host.
En Linux puedes añadir esto en Compose:
extra_hosts:
- "host.docker.internal:host-gateway"
Luego, en AnythingLLM, pon la dirección de Ollama como:
http://host.docker.internal:11434
Si usas Docker Run, tienes que añadir:
--add-host=host.docker.internal:host-gateway
Mucha gente tropieza aquí: rellenan http://localhost:11434 dentro del contenedor y les falla la conexión todo el tiempo.
Lo más fácil de confundir en AnythingLLM es esto.
En pocas palabras:
| Método | Escenario adecuado | Alcance |
|---|---|---|
| Attach file | Preguntar temporalmente sobre un archivo | Más adecuado para la conversación actual |
| Embed en el Workspace | Base de conocimiento a largo plazo | Se puede recuperar en el espacio de trabajo después |
Si solo quieres que la IA vea un PDF y responda unas preguntas, Attach es suficiente.
Si quieres hacer "preguntas y respuestas sobre las políticas de la empresa", "preguntas y respuestas sobre el manual de producto" o una "base de conocimiento de atención al cliente", deberías incrustar los documentos en el Workspace para que se conviertan en una base de conocimiento recuperable.
Mi consejo:
- Un Workspace por departamento
- Un Workspace por línea de producto
- No mezcles materiales sensibles con materiales públicos en el mismo Workspace
- Para archivos de los que no estés seguro de si los usarás a largo plazo, primero Attach, no te apresures a Embed
RAG no consiste en meter todos los archivos de golpe. Cuanto más claros sean los límites de los materiales, más fiables serán las respuestas.
La versión Docker de AnythingLLM admite multiusuario y gestión de permisos.
Pero el multiusuario no es "activarlo primero y ya veremos". Primero tienes que tener claro:
- Quién puede ver qué Workspace
- Qué documentos se pueden compartir
- Quién custodia la cuenta de administrador
- Cómo eliminar a usuarios que se van
- Si se permite un Chat Widget público
Si solo estás probando tú, primero ejecuta el flujo como usuario único.
Cuando confirmes que los espacios de trabajo, la clasificación de documentos y la configuración de modelos son estables, entonces plantéate el uso multiusuario. Abrir el acceso al equipo sin haber pensado bien el diseño de permisos suele acabar en desorden.
Lo que más miedo da en una base de conocimiento autoalojada no es una caída breve del servicio, sino perder los índices de documentos y la configuración.
Los datos clave de AnythingLLM están en el directorio de almacenamiento que montaste, por ejemplo:
/opt/anythingllm
Como mínimo hay que respaldar:
.env- La base de datos y la configuración del directorio storage
- Los documentos subidos
- Los datos relacionados con el índice vectorial
Primero puedes hacer un paquete comprimido local:
cd /opt
tar -czf anythingllm-backup-$(date +%F).tar.gz anythingllm
Luego sincronizar con rclone al almacenamiento de objetos:
rclone copy /opt/anythingllm-backup-$(date +%F).tar.gz r2:backup-bucket/anythingllm/
Hacer copias de seguridad sin restaurar es como no haber terminado.
Busca un momento de baja actividad para ensayarlo una vez:
docker compose down
mv /opt/anythingllm /opt/anythingllm-old
mkdir -p /opt/anythingllm
tar -xzf /opt/anythingllm-backup-2026-07-12.tar.gz -C /opt
docker compose up -d
Confirma que las cuentas, los Workspaces, los documentos y el chat siguen funcionando.
Actualizar un despliegue con Docker es sencillo, pero en producción no actualices a ciegas.
Entra en el directorio:
cd /opt/anythingllm
Primero haz copia de seguridad:
tar -czf /opt/anythingllm-before-upgrade-$(date +%F).tar.gz /opt/anythingllm
Descarga la nueva imagen:
docker compose pull
Reinicia:
docker compose up -d
Consulta los registros:
docker logs anythingllm --tail=100
Después de actualizar, revisa especialmente:
- Si puedes iniciar sesión
- Si los Workspaces siguen ahí
- Si los documentos se pueden recuperar
- Si el LLM Provider funciona
- Si el Embedding Provider funciona
- Si el HTTPS de Caddy funciona
Si detectas anomalías, no borres los datos primero. Conserva el directorio antiguo y la copia de seguridad, y luego decide si revertir.
Comprueba si el contenedor está en ejecución:
docker ps --filter "name=anythingllm"
Consulta los registros:
docker logs anythingllm --tail=100
Comprueba el puerto:
ss -tlnp | grep 3001
Si usas Caddy, sigue revisando:
systemctl status caddy --no-pager -l
journalctl -u caddy -n 100 --no-pager
Normalmente es que AnythingLLM no ha arrancado, o que el Caddyfile apunta mal.
Confirma que la máquina local puede acceder:
curl -I http://127.0.0.1:3001
Si la máquina local tampoco puede acceder, primero arregla Docker; si la máquina local sí puede acceder, entonces arregla Caddy.
Primero prueba en el host:
curl http://127.0.0.1:11434/api/tags
Si el host funciona pero el contenedor no, lo más probable es que la dirección esté mal escrita.
Cuando AnythingLLM en Docker accede al Ollama del host, normalmente no hay que escribir:
http://localhost:11434
Cambia a:
http://host.docker.internal:11434
Y asegúrate de que en Compose está:
extra_hosts:
- "host.docker.internal:host-gateway"
Normalmente no es un problema del servidor, sino del diseño de la base de conocimiento.
Revisa primero:
- Si los documentos son demasiado antiguos
- Si en el mismo Workspace se han mezclado materiales no relacionados
- Si la pregunta es demasiado amplia
- Si el Embedder está configurado correctamente
- Si tras el troceado de documentos se pueden recuperar fragmentos relevantes
No esperes que RAG lo entienda todo automáticamente. Si le das un montón de archivos desordenados, buscará respuestas en los archivos desordenados.
Consulta la memoria:
free -h
Consulta el OOM:
journalctl -k | grep -i "out of memory"
Si ejecutas AnythingLLM y Ollama a la vez, es normal que falte memoria.
A corto plazo puedes añadir swap:
fallocate -l 4G /swapfile
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile
echo '/swapfile none swap sw 0 0' >> /etc/fstab
Pero el swap solo sirve para emergencias; no puede convertir un VPS pequeño de 2GB en un servidor de IA.
Una vez que AnythingLLM está en internet, como mínimo haz estas cosas:
- Accede solo mediante dominio HTTPS
- No expongas directamente el puerto 3001
- Usa una contraseña de administrador fuerte
- No escribas las API Key en repositorios públicos
- Separa los materiales de distintos equipos en distintos Workspaces
- Haz copias de seguridad periódicas de
/opt/anythingllm - Desactiva a tiempo las cuentas de personas que se van
- Antes de subir materiales sensibles, confirma los requisitos de cumplimiento
Si solo lo usas tú, también puedes añadir una capa de Cloudflare Access o Tailscale para permitir el acceso solo a tus propios dispositivos.
Estas tres herramientas se preguntan a menudo juntas.
| Herramienta | Más adecuada para |
|---|---|
| AnythingLLM | Preguntas y respuestas sobre documentos, base de conocimiento privada, RAG para equipos pequeños |
| Dify | Aplicaciones de IA, flujos de trabajo, Agent, orquestación de servicios externos |
| Open WebUI | Interfaz de chat tipo ChatGPT, chat con modelos locales, entrada a varios modelos |
Mi elección es sencilla:
- Querer "subir documentos y luego hacer preguntas": AnythingLLM
- Querer "hacer una aplicación de IA para que la use otra gente": Dify
- Querer "dar a Ollama un buen frontend de chat": Open WebUI
Estas tres no se sustituyen completamente entre sí; son entradas distintas.
Si fuera para hacer preguntas y respuestas sobre documentos internos para un equipo pequeño de 3-5 personas, lo configuraría así:
- VPS: a partir de 2 núcleos 4GB
- Modelo: conectar primero con OpenAI / OpenRouter, sin prisa por ejecutar en local
- Despliegue: Docker Compose + Caddy HTTPS
- Puertos: abrir solo 80/443, no abrir 3001
- Documentos: crear Workspaces por departamento o línea de producto
- Copia de seguridad: respaldar
/opt/anythingllmal almacenamiento de objetos a diario - Permisos: probar primero como usuario único y activar el multiusuario cuando el flujo sea estable
Cuando de verdad confirmes que los materiales no pueden salir de la red, entonces plantéate opciones más pesadas como Ollama, embedding local y servidores con GPU.
El valor de AnythingLLM no es "haber instalado una herramienta de IA", sino convertir documentos dispersos en una base de conocimiento que se puede preguntar, consultar y compartir. El VPS es solo el soporte; lo que realmente hay que mantener a largo plazo son los límites de los materiales, los permisos y las copias de seguridad.