---
title: "Ollama con Docker Compose: Guía de Configuración con Open WebUI (2026)"
description: "Aprende la configuración de Ollama con Docker Compose y Open WebUI: archivos compose para CPU, GPU NVIDIA y AMD, etiquetas Traefik, descarga y actualización de modelos para una IA local privada."
date: 2026-10-11
categories: ["ai"]
tags: ["ollama","open-webui","local-llm"]
---

import Button from "@components/widgets/Button.astro";
import Notice from "@components/widgets/Notice.astro";
import ListCheck from "@components/widgets/ListCheck.astro";
import Accordion from "@components/widgets/Accordion.astro";
import Tabs from "@components/widgets/Tabs.astro";
import Tab from "@components/widgets/Tab.astro";
import YouTubeEmbed from "@components/widgets/YouTubeEmbed.astro";
import { Picture } from "astro:assets";
import imag1 from "@assets/images/24/08/openwebui-pull-model.png";
import imag2 from "@assets/images/24/08/openweb-ui-use.png";

Correr Ollama con Docker Compose es la forma más limpia de self-hostear un stack de IA local: dos contenedores, un archivo, y tus datos nunca salen de tu máquina. Esta guía empareja Ollama (v0.40.3 a octubre de 2026) con Open WebUI (v0.12.0) detrás de Traefik, con archivos Compose listos para usar en montajes de CPU, GPU NVIDIA y AMD ROCm.

Obtienes tres variantes de hardware del mismo stack, un paso de verificación tras cada etapa, una ruta de rollback para las actualizaciones, y notas honestas sobre el hardware que necesitas. Solo CPU está bien para trastear. Si quieres usar a diario modelos más grandes, planea una máquina con GPU o un mini PC.

## ¿Qué es Ollama?

[Ollama](https://ollama.com/) es la herramienta a la que la mayoría de la gente acude cuando quiere correr grandes modelos de lenguaje en su propio hardware. Descarga y sirve modelos detrás de una pequeña API REST, y mantiene los archivos de modelos en disco en vez de en la nube de otro. Los modelos de la librería vienen pre-cuantizados, así que no hay paso de cuantización en la ruta de descarga. A octubre de 2026 la versión actual es v0.40.3.

- Los modelos corren en tu máquina, así que los prompts y documentos se quedan privados.
- `ollama pull`, `ollama list` y `ollama rm` cubren la gestión diaria de modelos.
- Todo lo que hace la CLI está también en la API REST en `http://localhost:11434`, que es con lo que habla Open WebUI.
- Corre en Linux, macOS y Windows, con imágenes Docker oficiales (`ollama/ollama`, ~3,8 GB, ~185M pulls en Docker Hub).
- El soporte GPU cubre NVIDIA CUDA y AMD ROCm, más un runtime Vulkan empaquetado para tarjetas sin soporte oficial de ROCm.

El proyecto sigue moviéndose rápido. v0.30 reconstruyó el motor sobre una nueva capa de compatibilidad llama.cpp, y desde v0.32 la CLI `ollama` puede dejarte dentro de un agente de codificación interactivo, con `ollama launch` conduciendo agentes externos. Para un despliegue Docker nada de eso cambia el archivo compose, pero es una buena señal de que la capa base no está estancada.

## ¿Qué es Open WebUI?

Ollama es feliz en la línea de comandos. La mayoría de la gente no. [Open WebUI](https://openwebui.com/) es la interfaz de navegador que pongo delante: una app de chat que habla con Ollama y con otros proveedores (OpenAI, Anthropic, cualquier cosa compatible con OpenAI) desde una pantalla. A octubre de 2026 la versión actual es v0.12.0.

- Apúntala a Ollama local y APIs remotas lado a lado, y activa o desactiva cada conexión.
- El espacio de chat tiene historial de conversaciones, plantillas de prompt, exportación y cambio de modelo por mensaje.
- Usuarios y auth cubren cuentas locales, OAuth y roles de admin. La primera cuenta creada se convierte en la admin.
- Desde v0.9 hay una app de escritorio empaquetada para Mac/Windows/Linux si quieres salir del navegador.
- Desde v0.10 puedes compartir chats y conocimiento por usuario o grupo.
- El rediseño del panel de admin de v0.11 es por lo que capturas y menús más viejos en otras guías ahora se ven mal.
- Desde v0.12 hay voz en tiempo real sobre un backend OpenAI Realtime, más integraciones personales de MCP/tool-server detrás del interruptor de admin `ENABLE_DIRECT_INTEGRATIONS` (apagado por defecto).

Un detalle que importa aquí: Open WebUI guarda todo (usuarios, chats, ajustes) en una base de datos SQLite dentro de su volumen de datos. Ese volumen es lo que haces backup. Los blobs de modelos de Ollama son desechables; `webui.db` no.

## Cómo montar Ollama y Open WebUI con Docker Compose

Lo que estamos construyendo: un archivo Compose con dos servicios. Open WebUI obtiene etiquetas Traefik para ser accesible en tu dominio por HTTPS. Ollama se queda interno. Ningún contenedor publica un puerto al host, así que nada queda expuesto a internet excepto Traefik en el 443.

![Arquitectura de Ollama y Open WebUI en Docker Compose: navegador a Traefik en traefik-net al contenedor Open WebUI en el puerto interno 8080, que llama al contenedor Ollama en el puerto interno 11434; ningún contenedor de app publica puertos](@assets/images/24/08/ollama-open-webui-architecture.svg)

> Si te interesa ver algunas apps self-hosted open source gratuitas y chulas puedes mirar la [sección self-hosted de toolhunt.net](https://toolhunt.net/sh/).

<YouTubeEmbed
  url="https://www.youtube.com/embed/FHTYrMtLkmQ"
  label="How to Set Up Ollama with Open WebUI using Docker Compose"
/>

### 1. Prerequisitos

Antes de empezar, esto debe existir ya en el host:

<ListCheck>
<ul>
<li>Host Linux con Docker Engine y Docker Compose v2 (`docker compose version` imprime algo). ¿Nuevo en Docker? Ten abierta la <a href="/docker-commands/">chuleta de comandos esenciales de Docker</a>.</li>
<li>Traefik corriendo como reverse proxy y conectado a una red externa llamada `traefik-net`. Mira <a href="/traefik-proxy-docker/">Traefik como reverse proxy en Docker</a> y <a href="/traefik-wildcard-certificate/">certificado wildcard de Traefik con Cloudflare</a> si eso no está montado aún.</li>
<li>Registro DNS A para tu hostname elegido (los ejemplos de abajo usan `openwebui.domain.com`) apuntando al servidor.</li>
<li>~20 GB de disco libre para la imagen base más un modelo de tamaño medio. La imagen `ollama/ollama:latest` es ~3,8 GB (`:rocm` es ~1,4 GB) y los blobs de modelos en `./ollama-local` ocupan varios GB cada uno.</li>
<li>GPU y stack de drivers si planeas usar una: driver NVIDIA >= 550 (>= 570 para tarjetas más viejas) o AMD ROCm v7 (`amdgpu-install`).</li>
<li>Opcional: <a href="/es/instalar-dockge/">Dockge</a> si prefieres desplegar el archivo Compose desde una UI.</li>
</ul>
</ListCheck>

Comprobación de realidad de hardware, porque aquí es donde la mayoría de proyectos de IA local se atascan. Un VPS solo-CPU es para trastear. Una máquina de 8 vCPU / 16 GB sin GPU se arrastrará en cualquier cosa más allá de los modelos pequeños. Si quieres uso diario responsive, consigue una máquina con GPU, o córralo en casa en un mini PC: las elecciones de <a href="/best-mini-pc-home-server/">mini PC como home server</a> y la <a href="/best-mini-pc-local-llm/">guía de mini PC para LLMs locales</a> (para hardware que pueda alojar un modelo 70B) cubren ambas eso. Para hardware alquilado uso [Hetzner](https://go.bitdoze.com/hetzner) y [Hostinger](https://go.bitdoze.com/hostinger-vps); para hardware de casa, un mini PC compacto como el [ASUS DC510](https://go.bitdoze.com/asus-dc510) es el formato adecuado.

<Notice type="warning" title="Presupuesta disco antes de bajar modelos">
Un modelo de tamaño medio más la imagen base comerán ~15-20 GB. No hagas backup de los blobs de modelos; siempre puedes volver a bajarlos. Sí haz backup de `./open-webui-local`, que contiene `webui.db`. Si el disco se llena, Docker se pone raro rápido: mira cómo <a href="/clean-docker-overlay2-dir/">recuperar espacio de disco de Docker con seguridad</a>.
</Notice>

_Los precios de VPS saltaron en bloque en 2026. Si estás replanteándote una máquina alquilada, mira [qué cambió y cuándo gana un mini PC](/vps-price-increases/)._

### 2. Docker Compose

Un archivo compose, tres variantes de hardware. Elige la que coincida con tu máquina. Unos ajustes aplican a las tres:

- `restart: unless-stopped` en **ambos** servicios. Los snippets oficiales a veces lo saltan en Ollama; añádelo a menos que disfrutes re-ejecutando `docker compose up` tras cada reinicio del host.
- `OLLAMA_BASE_URL: http://ollama:11434` en el servicio Open WebUI. Esta es la variable de backend único.

<Notice type="info" title="OLLAMA_BASE_URL vs OLLAMA_BASE_URLS">
`OLLAMA_BASE_URL` apunta Open WebUI a una instancia de Ollama. `OLLAMA_BASE_URLS` es la variable multi-backend separada por punto y coma y balanceada, y toma precedencia cuando ambas están puestas. Con un solo contenedor, usa `OLLAMA_BASE_URL`.
</Notice>

<Notice type="warning" title="Genera WEBUI_SECRET_KEY">
Genera una clave real antes del primer arranque: `openssl rand -hex 32`. Firma cookies de sesión y tokens internos. Rotarla después de que existan usuarios desconecta a todos. Si prefieres mantenerla fuera del YAML por completo, <a href="/docker-compose-secrets/">gestiona `WEBUI_SECRET_KEY` con secretos de Docker Compose</a> o un archivo env en disco con permisos estrictos.
</Notice>

Si estás detrás de un proxy corporativo, pon `HTTPS_PROXY` solo en el servicio ollama. Los docs de Ollama advierten explícitamente que `HTTP_PROXY` puede romper las descargas de modelos.

#### Solo CPU

```yml
services:
  open-webui:
    image: ghcr.io/open-webui/open-webui:main   # pin ghcr.io/open-webui/open-webui:v0.12.0 for shared/prod
    container_name: openwebui
    hostname: openwebui
    restart: unless-stopped
    networks:
      - traefik-net
    volumes:
      - ./open-webui-local:/app/backend/data
    environment:
      OLLAMA_BASE_URL: http://ollama:11434
      WEBUI_SECRET_KEY: change-me-openssl-rand-hex-32
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.openwebui.rule=Host(`openwebui.domain.com`)"
      - "traefik.http.routers.openwebui.entrypoints=https"
      - "traefik.http.services.openwebui.loadbalancer.server.port=8080"

  ollama:
    image: ollama/ollama:latest                 # or pin ollama/ollama:0.40.3
    container_name: ollama
    hostname: ollama
    restart: unless-stopped
    volumes:
      - ./ollama-local:/root/.ollama
    environment:
      OLLAMA_CONTEXT_LENGTH: "8192"             # small-RAM box; server default is VRAM-tiered (4k/32k/256k)

networks:
  traefik-net:
    external: true
```

Lo que hacen las etiquetas Traefik:

- `traefik.enable=true`: deja a Traefik enrutar a este contenedor.
- ``traefik.http.routers.openwebui.rule=Host(`openwebui.domain.com`)``: coincide el tráfico para ese hostname. Reemplaza con tu propio nombre DNS.
- `traefik.http.routers.openwebui.entrypoints=https`: lo sirve solo en el entrypoint HTTPS.
- `traefik.http.services.openwebui.loadbalancer.server.port=8080`: Open WebUI escucha en 8080 dentro del contenedor. Esto sigue siendo correcto en v0.12.

Sin sección `ports:` en ningún sitio. Es deliberado. Ollama solo es accesible como `http://ollama:11434` desde dentro de `traefik-net`.

Sobre `OLLAMA_CONTEXT_LENGTH`: Ollama elige un contexto por defecto según la VRAM disponible (4k bajo 24 GiB, 32k para 24-48 GiB, 256k por encima). Poner 8192 es un suelo sensato para máquinas pequeñas y mantiene el uso de memoria predecible.

<Notice type="warning" title="La trampa de num_ctx">
Open WebUI tiene su propio ajuste `num_ctx` por modelo y sobrescribe `OLLAMA_CONTEXT_LENGTH`. Puede pre-rellenar un valor diminuto como 2048, que aparece como respuestas en blanco o cortadas sin error obvio en ningún sitio. Si las respuestas mueren tras unos párrafos, abre los ajustes del modelo en Open WebUI y sube `num_ctx` antes de empezar a depurar la GPU.
</Notice>

#### Docker Compose con GPU NVIDIA

Primero instala el NVIDIA Container Toolkit. Es lo que permite a los contenedores ver la GPU en absoluto. Sin él, `--gpus` y el bloque `deploy` de abajo no hacen nada.

<Tabs>
<Tab name="Debian/Ubuntu (apt)">

```sh
curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg \
 && curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | \
sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | \
sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list
sudo apt-get update
sudo apt-get install -y nvidia-container-toolkit

# Configure NVIDIA Container Toolkit
sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker
```

</Tab>
<Tab name="RHEL/Rocky (dnf/yum)">

```sh
curl -s -L https://nvidia.github.io/libnvidia-container/stable/rpm/nvidia-container-toolkit.repo | \
  sudo tee /etc/yum.repos.d/nvidia-container-toolkit.repo
sudo yum install -y nvidia-container-toolkit

# Configure NVIDIA Container Toolkit
sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker
```

</Tab>
</Tabs>

Haz un smoke-test de la integración GPU antes de tocar Compose. Este es el paso de verificación 1; si falla, nada de lo que viene después funcionará.

```sh
docker run --rm --gpus all nvidia/cuda:12.4.1-base-ubuntu22.04 nvidia-smi
```

Quieres la tabla habitual de GPU (versión de driver, versión de CUDA, lista de dispositivos). Si obtienes "could not select device driver", el toolkit no está configurado con Docker o falta el driver.

Suelo de soporte a octubre de 2026: compute capability NVIDIA 5.0+ (Maxwell y más nuevo), driver >= 550. Las tarjetas más viejas en el rango 5.0-6.2 necesitan driver >= 570. Las tarjetas RTX 50xx (compute capability 12.0) están soportadas.

El archivo Compose es el de CPU más este bloque en el servicio ollama:

```yml
  ollama:
    image: ollama/ollama:latest
    container_name: ollama
    hostname: ollama
    restart: unless-stopped
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              capabilities: ["gpu"]
              count: all
    networks:
      - traefik-net
    volumes:
      - ./ollama-local:/root/.ollama
```

Esto entrega cada GPU visible al contenedor Ollama. En una máquina multi-GPU, fija dispositivos específicos con `CUDA_VISIBLE_DEVICES` (los UUIDs de `nvidia-smi -L` son el identificador fiable). En hardware Jetson, pasa `JETSON_JETPACK=5` (o `=6`) al contenedor en su lugar.

La aceleración GPU frente a CPU es una diferencia grande en la mayoría de modelos. Las cifras exactas dependen del modelo y la cuantización, así que ejecuta `ollama ps` en tu propio hardware antes de fiarte de cualquier cifra que leas online. Solo CPU es para trastear, no para uso diario.

Una aclaración que merece quedar por escrito: `ghcr.io/open-webui/open-webui:cuda` solo acelera los modelos locales propios de Open WebUI (embeddings, reranking, Whisper). Los modelos servidos por Ollama usan la GPU solo si el contenedor **ollama** tiene acceso a GPU. El bloque `deploy` de arriba es lo que importa.

Modo de fallo conocido: tras un ciclo de suspensión/reanudación de Linux, Ollama cae silenciosamente a CPU. La corrección es `sudo rmmod nvidia_uvm && sudo modprobe nvidia_uvm`, luego reinicia el contenedor ollama.

#### Docker Compose con GPU AMD

Dos caminos aquí, y el correcto depende de si tu tarjeta está en la lista oficial de soporte ROCm de AMD.

<Tabs>
<Tab name="ROCm (tarjetas soportadas)">

Prerequisito del host: el driver AMD ROCm v7 (`amdgpu-install`). Las tarjetas soportadas a octubre de 2026 incluyen RX 9070 XT / 9070 / 9060 XT, 7900 XTX/XT/GRE, la serie 7800/7700/7600, Radeon AI PRO R9700/R9600D, Ryzen AI Max+ 395 / Max 390 / 385 y chips móviles Ryzen AI 9 HX, más Instinct MI350X/MI300X/MI250/MI210/MI100.

Usa la imagen `:rocm` **y** pasa los nodos de dispositivo. Cambiar solo el tag no funciona:

```yml
  ollama:
    image: ollama/ollama:rocm
    container_name: ollama
    hostname: ollama
    restart: unless-stopped
    devices:
      - /dev/kfd
      - /dev/dri
    networks:
      - traefik-net
    volumes:
      - ./ollama-local:/root/.ollama
```

La imagen `:rocm` también es más pequeña que la principal (~1,4 GB vs ~3,8 GB), ya que no empaqueta cada runtime.

</Tab>
<Tab name="Fallback Vulkan (todo lo demás)">

Las tarjetas sin soporte oficial de ROCm a menudo pueden correr en GPU igualmente. La imagen estándar `ollama/ollama` trae un runtime Vulkan que se auto-activa cuando los nodos de dispositivo GPU son visibles:

```yml
  ollama:
    image: ollama/ollama:latest
    container_name: ollama
    hostname: ollama
    restart: unless-stopped
    devices:
      - /dev/kfd
      - /dev/dri
    networks:
      - traefik-net
    volumes:
      - ./ollama-local:/root/.ollama
```

Controles: `OLLAMA_VULKAN=0` lo desactiva, `GGML_VK_VISIBLE_DEVICES` selecciona qué tarjetas usar. El rendimiento está por debajo de ROCm en tarjetas soportadas, pero gana a CPU.

</Tab>
</Tabs>

<Notice type="info" title="Cómo saber en qué camino estás">
Arranca el stack y ejecuta `docker exec -it ollama ollama ps` con un modelo cargado. `PROCESSOR` leyendo `100% GPU` significa que estás en GPU independientemente de Vulkan o ROCm. Solo CPU lee `100% CPU`. Luego revisa los logs del contenedor con `docker compose logs ollama` para ver el nombre del runtime que cargó.
</Notice>

### 3. Arranca el archivo Docker Compose

```sh
docker compose up -d
```

Luego confirma que ambos contenedores están arriba:

```sh
docker compose ps
docker compose logs -f --tail=50
```

Quieres `openwebui` y `ollama` en estado `Up`. El primer arranque de Open WebUI tarda 30-60 segundos mientras crea `webui.db`; estás listo cuando la página de login se renderiza en el navegador. Puedes desplegar el mismo archivo desde Dockge si prefieres una UI; mira la [guía de instalación de Dockge](/es/instalar-dockge/).

Si `compose ps` sale con un error de red, comprueba que la red externa existe: `docker network ls | grep traefik`.

### 4. Accede a Open WebUI y crea la cuenta de admin

Abre el dominio que pusiste en la etiqueta Traefik (el ejemplo usa `openwebui.domain.com`). Se te pedirá crear un usuario y contraseña. La **primera cuenta creada se convierte en la admin**, así que no des esta URL a nadie más antes de haberte registrado.

Una vez que la cuenta existe, cierra la puerta: pon los registros a cerrado añadiendo esto al entorno del servicio open-webui y recreando el contenedor.

```yml
    environment:
      ENABLE_SIGNUP: false
```

```sh
docker compose up -d --force-recreate
```

Esa recreación importa solo en el primer arranque. Mira la trampa de abajo.

<Notice type="warning" title="ENABLE_SIGNUP se persiste en la base de datos">
`ENABLE_SIGNUP` es un ConfigVar. En el primer arranque su valor se escribe en `webui.db`, y desde entonces el valor de la base de datos gana sobre la variable de entorno. Si lo pones después y "no pasa nada", es por esto. La corrección fiable es alternarlo en **Admin -> Settings**. Alternativas: pon `ENABLE_PERSISTENT_CONFIG=False` para que las variables de entorno sigan ganando, o actualiza la fila directamente:

```sh
docker exec -it openwebui sqlite3 /app/backend/data/webui.db "UPDATE config SET data = json_set(data, '$.ENABLE_SIGNUP', json('false'));"
```
</Notice>

Opción más limpia para un operador en solitario: salta el baile de registro por completo. Pon `WEBUI_ADMIN_EMAIL` y `WEBUI_ADMIN_PASSWORD` en el servicio open-webui antes del primer arranque. Open WebUI crea la cuenta de admin sin cabeza al arrancar y desactiva el registro por ti. Sin segunda recreación.

### 5. Descargar un modelo

Con la cuenta de admin en su sitio, baja un modelo. El menú se movió en el rediseño de admin de v0.11, así que las guías viejas te mandarán a la pantalla equivocada.

Ruta actual (v0.12): **Settings -> Admin -> Connections**, encuentra tu instancia bajo **Manage Ollama API Connections**, haz clic en **Manage** (el icono de descarga), y descarga modelos desde ahí. El mismo diálogo tiene un botón **Update All Models** y **Create a model** si quieres una variante con un prompt de sistema fijo.

Ruta más rápida: escribe el nombre del modelo directamente en el **selector de modelo** arriba del chat y acepta el prompt de descarga.

<Picture formats={["webp"]} fallbackFormat="webp" src={imag1} alt="Diálogo Manage de Open WebUI descargando un modelo de Ollama desde Ollama.com" />

Alternativa CLI, que es lo que uso en servidores:

```sh
docker exec -it ollama ollama pull qwen3:0.6b
docker exec -it ollama ollama list
```

Ollama también baja GGUF directamente desde Hugging Face con el patrón `hf.co/{username}/{repository}:{quantization}`, por ejemplo `hf.co/ggml-org/gemma-3-270m-it-GGUF:Q8_0`. Útil cuando un modelo aún no está en la librería de Ollama.

Una vez que un modelo responde en el chat, el stack está sirviendo. Si quieres apuntar un agente de codificación a él a continuación, puedes [correr el agente de codificación OpenClaw contra tus modelos Ollama locales](/es/openclaw-ollama-modelos-locales/).

<Picture formats={["webp"]} fallbackFormat="webp" src={imag2} alt="Ventana de chat de Open WebUI respondiendo a un prompt de un modelo Ollama corriendo en local" />

### 6. Modelos Ollama recomendados

Elegir un modelo es mayormente una cuestión de VRAM/RAM. Los tamaños de descarga siguen el número de parámetros y la cuantización; lo que importa en runtime es si los pesos más la caché KV caben en memoria. Unas elecciones a octubre de 2026, con el nivel de hardware al que pertenecen:

<ListCheck>
<ul>
<li>Lo más pequeño que funciona en CPU con 2-4 GB de RAM: `qwen3:0.6b` o `gemma3:1b` para chat, `llama3.2` para máquinas diminutas. Estas son las únicas opciones sensatas en un VPS CPU.</li>
<li>Uso diario con 12-24 GB de VRAM/RAM: `gpt-oss` o `gemma4` como modelos de propósito general. Revisa la página de librería de cada modelo por tamaño y tags de cuantización actuales antes de bajar.</li>
<li>Codificación: `qwen3-coder`. Apúntale un agente de IDE u OpenClaw sobre la API local.</li>
<li>Visión: `qwen3-vl` cuando necesites entrada de imagen.</li>
<li>Nivel de razonamiento, GPU recomendada: `deepseek-v4.1-flash` para velocidad, `deepseek-v4-pro` cuando quieras profundidad.</li>
<li>Terreno medio eficiente: `nemotron-3.5-lightning`, un MoE de 30B que pega por encima de su coste de memoria.</li>
</ul>
</ListCheck>

Dos notas prácticas. Primero, prefiere siempre una cuantización más pequeña de un buen modelo sobre un modelo grande que haga swap a disco; el swap destruye la latencia. Segundo, verifica los nombres de tag exactos en [ollama.com/library](https://ollama.com/library) antes de scriptar pulls; los tags cambian y prefiero que compruebes a que confíes en una lista que envejece. Para una comparación más larga de pesos abiertos, mira [nuestra comparación de los mejores LLMs open source](/es/mejores-llms-opensource-alternativa-claude/).

### 7. Verifica el montaje

Esta es la sección que la mayoría de tutoriales se saltan. Cinco minutos aquí ahorran una tarde de adivinanzas.

```sh
# GPU in use? (PROCESSOR should read 100% GPU; note the CONTEXT column)
docker exec -it ollama ollama ps

# API up inside the compose network?
docker exec -it ollama curl -s http://localhost:11434/api/version

# Same check from the Open WebUI container
docker exec -it openwebui curl -s http://ollama:11434/api/version
```

Si falta `curl` dentro de un contenedor, el fallback es `docker compose logs ollama` y buscar la línea "listening on".

<ListCheck>
<ul>
<li>`/api/version` devuelve un blob JSON con un string de versión</li>
<li>`ollama ps` muestra `100% GPU` (o `100% CPU` si eso es lo que esperas)</li>
<li>La columna `CONTEXT` no es un valor sorpresa como 2048</li>
<li>Un modelo responde en el chat de Open WebUI</li>
<li>El registro está cerrado (navega a la URL de registro en una ventana privada)</li>
</ul>
</ListCheck>

De extremo a extremo, también puedes [exponer tus modelos a cualquier app a través de un gateway compatible con OpenAI con LiteLLM en Docker Compose](/es/litellm-docker-instalacion/) y apuntar otras herramientas al gateway en vez de a Ollama directamente.

### 8. Cómo actualizar Ollama y Open WebUI

Ambos proyectos publican a menudo. La actualización en sí son dos comandos; el backup es la parte que la gente se salta y lamenta.

<Notice type="warning" title="Haz backup antes de hacer pull">
Las migraciones de schema de BD de Open WebUI mueven la base de datos solo hacia adelante. Desde v0.9 los docs son explícitos en que las actualizaciones rodantes a través de cambios de schema no están soportadas. Una mala actualización sin backup es un `webui.db` irrecuperable.
</Notice>

```sh
# backup first
tar czf webui-backup-$(date +%F).tgz ./open-webui-local

# pull new images and recreate
docker compose pull && docker compose up -d

# then hard-refresh the browser (Ctrl+F5) so cached UI assets do not lie to you
```

Tras actualizar, vuelve a `/api/version` y comprueba el string de versión en los logs. Haz lo mismo para Open WebUI en **Admin -> Settings -> About**.

Estrategia de tags:

Para un homelab o un solo usuario, mantén `:main` / `:latest` y haz pull manualmente cuando te apetezca. Lee las notas de versión primero. Para uso compartido o producción, fija los tags (`ghcr.io/open-webui/open-webui:v0.12.0`, `ollama/ollama:0.40.3` en el archivo Compose) y súbelos deliberadamente. Nunca apuntes un volumen de datos real a `:dev`. Una migración de base de datos dev puede dejar el volumen ilegible para builds de release; los docs dicen usar un volumen separado por completo.

Rollback: descomprime el backup sobre `./open-webui-local`, vuelve a poner los tags fijados anteriores en el archivo Compose, `docker compose up -d`, luego hard-refresh. Los blobs de modelos en `./ollama-local` no necesitan backup; bórralos y vuélvelos a bajar si algo se corrompe. Esa también es la razón por la que el tar de backup se queda pequeño.

### 9. Resolución de fallos comunes

<Notice type="error" title="Empieza por los logs">
`docker compose logs -f --tail=100 openwebui ollama` resuelve más de estos que cualquier adivinanza. Arregla el primer error, no la última línea.
</Notice>

<Accordion label="ENABLE_SIGNUP: false es ignorado" group="faq">
El valor es un ConfigVar persistido en `webui.db` en el primer arranque, y la base de datos gana sobre el entorno desde entonces. Cámbialo en Admin -> Settings (recomendado), pon `ENABLE_PERSISTENT_CONFIG=False` para que las variables de entorno vuelvan a ganar, o ejecuta el one-liner `sqlite3` `UPDATE config` del paso 4. Poner la variable antes del primer arranque sí funciona; cambiarla después no hace nada silenciosamente.
</Accordion>

<Accordion label="GPU invisible tras suspender/reanudar (NVIDIA)" group="faq">
Síntoma: `ollama ps` lee `100% CPU` tras dormir el host. El módulo `nvidia_uvm` está atascado. Ejecuta `sudo rmmod nvidia_uvm && sudo modprobe nvidia_uvm`, luego `docker compose restart ollama`. Comprueba `docker run --rm --gpus all nvidia/cuda:12.4.1-base-ubuntu22.04 nvidia-smi` después.
</Accordion>

<Accordion label="Tarjeta AMD no está en la lista de soporte ROCm" group="faq">
No fuerces la imagen `:rocm`. Corre la imagen estándar `ollama/ollama:latest` con `devices: [/dev/kfd, /dev/dri]` y deja que el runtime Vulkan empaquetado se active. Confirma con `docker exec -it ollama ollama ps` (`100% GPU`). `OLLAMA_VULKAN=0` desactiva Vulkan si se porta mal; `GGML_VK_VISIBLE_DEVICES` selecciona tarjetas.
</Accordion>

<Accordion label="Respuestas en blanco o truncadas" group="faq">
Casi siempre es longitud de contexto. El `num_ctx` por modelo de Open WebUI sobrescribe `OLLAMA_CONTEXT_LENGTH` y puede pre-rellenar 2048, lo que mata de hambre los prompts largos y corta las respuestas sin error. Abre los ajustes del modelo en Open WebUI, sube `num_ctx`, y reintenta. Para cargas de agentes y codificación quieres >= 64k si el hardware lo permite.
</Accordion>

<Accordion label="El contenedor no arranca: network not found" group="faq">
`network traefik-net declared as external, but could not be found` significa que el nombre de la red externa no coincide con tu stack de Traefik. Ejecuta `docker network ls | grep traefik`, arregla el bloque `networks:` o crea la red, y comprueba que estás en el directorio de proyecto compose correcto. Confirma también que nada más ya ocupa el nombre: `docker compose ps` desde otras carpetas en el mismo host.
</Accordion>

Unas preguntas más cortas que surgen:

<Accordion label="¿Puedo correr esto sin Traefik?" group="faq">
Sí. Añade `ports: - "3000:8080"` al servicio open-webui y borra las etiquetas Traefik. Bien para una máquina solo-LAN. En un VPS público entonces tú te encargas de TLS y el control de acceso; yo no expondría el puerto 3000 a internet sin ambos.
</Accordion>

<Accordion label="¿Cuánto disco necesita un modelo?" group="faq">
La imagen base es ~3,8 GB (`:rocm` es ~1,4 GB). Un modelo 7B a una cuantización común son 4-5 GB en disco; la clase 30B corre 15-25 GB; la clase 70B es 35 GB+. Presupuesta ~20 GB libres para la imagen más un modelo de tamaño medio. El volumen `ollama-local` es donde aterrizan.
</Accordion>

<Accordion label="¿Soportan las imágenes ARM?" group="faq">
Sí, tanto `ollama/ollama` como `ghcr.io/open-webui/open-webui` publican manifiestos multi-arch. Las placas ARM y Apple Silicon corren este stack; solo calibra el tamaño del modelo a la RAM y mantén honestas las expectativas de inferencia por CPU.
</Accordion>

## Conclusiones

Ese es todo el montaje: Ollama y Open WebUI en Docker Compose, dos contenedores detrás de Traefik, con variantes CPU, NVIDIA y AMD del mismo archivo. Tus prompts, chats y tráfico de modelos se quedan en hardware que controlas. El paso de verificación y el hábito de backup-antes-de-actualizar son las dos cosas que hacen este stack aburrido de correr en vez de frágil.

Máquina GPU para uso diario, VPS CPU para trastear. No te saltes `ollama ps` tras el primer arranque y no te saltes el tar de `webui.db` antes de las actualizaciones.

Para más cosas que correr al lado, mira [los mejores 100+ contenedores Docker para home server](/es/contenedores-docker-servidor-casa/) y [otro espacio de trabajo IA que puedes self-hostear con Docker](/buzz-block-docker-setup/). Para el catálogo más amplio de IA local y agentes en GitHub, mira [top AI GitHub repos](/top-ai-github-repos/).

<Button text="Mejores mini PCs para LLMs locales" link="/best-mini-pc-local-llm/" variant="solid" color="blue" size="md" icon="arrow-right" />
<Button text="100+ contenedores Docker para home server" link="/es/contenedores-docker-servidor-casa/" variant="outline" color="blue" size="md" />