Alojar Ollama en un VPS: guía operativa avanzada

Desplegar Ollama lleva unos minutos. Mantenerlo funcionando de forma fiable a lo largo del tiempo exige bastante más atención. En producción, tres puntos concentran la mayor parte de los problemas: la gestión de los modelos (cuál cargar, cuál retirar para liberar disco), la superficie de ataque de la API (sin autenticación por defecto en el puerto 11434) y el consumo de memoria (un modelo mal dimensionado satura la RAM y hace que el núcleo mate el proceso). Esta guía parte de la base de que el contenedor ollama ya está en marcha y se centra en esos tres ejes, más la integración con las herramientas de su stack.

El tamaño de un modelo se expresa en miles de millones de parámetros (B) y determina la RAM necesaria. Un modelo 1B/3B cabe en 2 o 3 GB y sirve para tareas sencillas (clasificación, resumen corto) en un VPS modesto. Un 7B/8B pide de 5 a 6 GB en Q4: es la relación calidad/recursos más habitual. Un 13B necesita de 9 a 10 GB, y un 70B supera los 40 GB — reservado a VPS de mucha memoria o a configuraciones con GPU. Para cada tamaño, la cuantización ajusta el compromiso calidad/velocidad: Q4_K_M ofrece un buen equilibrio entre calidad y velocidad en CPU, mientras que Q8 conserva más precisión a cambio de duplicar la RAM. Antes de hacer pull de un modelo, compruebe el espacio libre con df -h y la RAM disponible con free -h.

Por defecto, Ollama escucha en 127.0.0.1:11434 sin autenticación. Para exponerlo a sus herramientas (Open WebUI, n8n, un script remoto), coloque nginx por delante con un token Bearer. El bloque de configuración siguiente delega el acceso a un token secreto definido en la variable $api_token, comprueba la cabecera Authorization y hace de proxy hacia Ollama. El CORS está configurado para aceptar las peticiones de su interfaz sin exponer la API a todos los orígenes.

En /etc/nginx/sites-available/ollama:

map $http_authorization $api_token_valid {
    default 0;
    "Bearer VOTRE_TOKEN_SECRET" 1;
}
server {
    listen 443 ssl;
    server_name api-ia.votre-domaine.com;
    ssl_certificate /etc/letsencrypt/live/api-ia.votre-domaine.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/api-ia.votre-domaine.com/privkey.pem;
    location / {
        if ($api_token_valid = 0) { return 401; }
        proxy_pass http://127.0.0.1:11434;
        proxy_set_header Host $host;
        add_header Access-Control-Allow-Origin "https://ui.votre-domaine.com";
    }
}

Active la configuración con ln -s /etc/nginx/sites-available/ollama /etc/nginx/sites-enabled/ y después nginx -t && systemctl reload nginx.

Cuatro situaciones se repiten con regularidad en producción.

Modelo demasiado lento. ¿La generación no pasa de 2-3 tokens por segundo en CPU con un 7B? Compruebe que OLLAMA_NUM_THREADS no esté a 1 (valor por defecto si no se define en algunas imágenes). Compruebe también que solo hay un modelo cargado (OLLAMA_MAX_LOADED_MODELS=1): dos modelos simultáneos se disputan los núcleos y el ancho de banda de memoria.

VRAM insuficiente (GPU). Si el registro de Docker muestra CUDA out of memory o ROCm error, el modelo no cabe en la VRAM. Pase al tag q4_K_M o reduzca OLLAMA_CONTEXT_SIZE. Ollama cambia a CPU si la VRAM es insuficiente, pero sin indicarlo con claridad: compare las velocidades de generación para detectarlo.

Conexión a la API rechazada. ¿curl: (7) Failed to connect desde el exterior aunque el servicio esté escuchando? El cortafuegos bloquea el puerto 11434, o nginx no está arrancado. Compruébelo con ss -tlnp | grep 11434 (debe mostrar 127.0.0.1, no 0.0.0.0) y systemctl status nginx.

Signal killed / OOM. El núcleo mata el proceso (OOM killer). La RAM del VPS es insuficiente para el modelo seleccionado. Vuelva a un tamaño inferior o active un swap de 4 a 8 GB como colchón: fallocate -l 4G /swapfile && chmod 600 /swapfile && mkswap /swapfile && swapon /swapfile. El swap ralentiza la generación, pero evita las paradas bruscas.

Ollama es un backend: adquiere todo su valor cuando otros servicios se conectan a él. Tres herramientas se integran de forma natural en el mismo VPS.

Open WebUI ofrece una interfaz de conversación comparable a ChatGPT, conectada a la API local de Ollama. En su fichero de entorno, defina OLLAMA_BASE_URL=http://ollama:11434 (si los dos contenedores comparten una red Docker) o OLLAMA_BASE_URL=http://127.0.0.1:11434 si Open WebUI se ejecuta en el mismo host. Open WebUI gestiona la selección del modelo, el historial de las conversaciones y la administración de los usuarios. Atención: el acoplamiento Ollama ↔ Open WebUI expone una superficie de ataque adicional que hay que vigilar — véase la sección CVE-2026-45672 más abajo.

LangFlow es un constructor visual de pipelines LLM. Añada un nodo Ollama en su flow, indique http://127.0.0.1:11434 como base URL y seleccione el modelo en la lista desplegable. LangFlow llama directamente al endpoint /api/generate sin autenticación interna: colóquelo en la red privada del VPS, no expuesto públicamente.

n8n permite disparar llamadas a Ollama desde un flujo de automatización. Utilice el nodo HTTP Request apuntando a http://127.0.0.1:11434/api/chat con un cuerpo JSON que contenga model y messages. Desde n8n puede encadenar una llamada a Ollama con una etapa de recuperación de datos, de envío de correo o de webhook saliente sin escribir código.

Publicada el 21 de mayo de 2026 (GHSA-482j-2pq6-q5w4), esta vulnerabilidad afecta a todas las versiones de Open WebUI anteriores a la 0.8.12. Puntuación CVSS: 8.8 (alta).

Mecánica del ataque. Un usuario autenticado puede ejecutar código Python arbitrario a través del endpoint /api/v1/utils/code/execute, incluso si el administrador ha desactivado la ejecución de código en los ajustes (ENABLE_CODE_EXECUTION=false). La protección se declara en la configuración, pero nunca se verifica del lado de la API: cualquier cuenta verificada en la instancia puede lanzar la ejecución.

Impacto. El atacante accede al backend Jupyter subyacente y puede leer ficheros arbitrarios en el VPS, robar secretos (claves de API, token de Ollama, variables de entorno) o establecer persistencia. La confidencialidad, la integridad y la disponibilidad del servidor quedan comprometidas.

Por qué es crítico en un acoplamiento Ollama ↔ Open WebUI. Ollama y Open WebUI se ejecutan a menudo en el mismo VPS, a veces en la misma red Docker, con secretos compartidos (clave de API de OpenAI de respaldo, token Bearer de la API de Ollama). Un acceso RCE en Open WebUI da por tanto un acceso directo a la API de Ollama y a los modelos en memoria, sin pasar por el reverse proxy.

Corrección. Actualice Open WebUI a la versión 0.8.12 o superior. Esta versión aplica la comprobación de ENABLE_CODE_EXECUTION en el propio endpoint de la API, allí donde siempre debió estar.

Comprobar su versión. Desde el contenedor: docker exec open-webui cat /app/package.json | grep '"version"'. Si la salida es inferior a 0.8.12, la actualización es urgente: docker pull ghcr.io/open-webui/open-webui:main && docker stop open-webui && docker rm open-webui y después relance con los mismos parámetros de entorno.