Cómo autoalojar Octop con Docker Compose y TLS

Qué es Octop y por qué alojarlo por cuenta propia

Octop es un asistente de IA autoalojado para un hogar o un equipo pequeño. La razón para autoalojar Octop en lugar de usar una interfaz de chat básica es que mantiene separados a los usuarios. Open WebUI proporciona una interfaz de navegador delante de un modelo. Octop añade cuentas con un rol de administrador, un espacio de trabajo privado y un conjunto de credenciales para cada usuario, además de una biblioteca de agentes especializados que cada usuario puede seleccionar según la tarea. Esa es la diferencia que permite que un solo VPS preste servicio a cinco personas en lugar de a una.

El proyecto se encuentra en github.com/TencentCloud/Octop. Es un único proceso que proporciona un panel web, una interfaz de línea de comandos, canales de chat (Feishu, DingTalk, QQ, Discord, WeCom) y tareas programadas. Todo funciona con una única base de datos SQLite en ~/.octop/. Todo lo que sigue se basa en la etiqueta v0.9.19, publicada el 5 de agosto de 2026. Si todavía está decidiendo entre plataformas, la comparativa de alternativas a Open WebUI que puede ejecutar en un VPS cubre un abanico más amplio.

Conviene aclarar un punto antes de dedicarle una tarde. Octop es software anterior a la versión 1.0, publicado desde la organización de GitHub de un proveedor, con unas 900 estrellas en agosto de 2026. El proyecto evoluciona rápido, como reflejan los números de versión, y nada de esto garantiza una ruta de actualización estable. Fije una etiqueta, lea el registro de cambios y conserve copias de seguridad.

Qué necesita antes de empezar

• Un VPS con Ubuntu 24.04, Docker Engine y el complemento Compose. ¿Es la primera vez que usa Compose? Empiece por Conceptos básicos de Docker Compose para un VPS.
• git, porque va a obtener una etiqueta de versión en lugar de descargar una imagen.
• Un nombre de dominio que apunte al VPS, porque necesita TLS (seguridad de la capa de transporte) delante del servicio.
• Un backend de modelo compatible con la API de OpenAI: un Ollama local, una puerta de enlace autogestionada o una clave de pago.

Octop consume pocos recursos. Es un proceso de Python y un archivo de SQLite. El consumo principal corresponde al backend del modelo. Si planea ejecutar el modelo en el mismo servidor, dimensione el servidor para el modelo.

Por qué no recomendamos el instalador con curl

El README comienza con una instalación en una sola línea:

curl -fsSL https://finnie-1258344699.cos.ap-guangzhou.myqcloud.com/octop/install.sh | bash

No lo recomendamos en un servidor que deba mantenerse seguro por una razón concreta: ese script no está en el repositorio. Se sirve desde un bucket de Tencent Cloud Object Storage. Ningún git tag ni commit cubre su contenido, por lo que no puede comparar el script actual con el de la semana pasada ni existe un historial que explique un cambio. Mañana, el bucket puede servir bytes diferentes y el proyecto no registraría nada. Pasar directamente el resultado a bash también implica que la máquina ejecuta el script antes de que haya leído una sola línea.

Además, el instalador escribe directamente en el host, no en un contenedor. Usa uv para descargar Python 3.12 y crear un entorno que el gestor de paquetes no conoce, por lo que eliminarlo después requiere trabajo manual.

Hay dos opciones mejores. Descargue el script, léalo y ejecútelo después. Sólo le llevará treinta segundos: curl -fsSL <url> -o install.sh, después less install.sh y, por último, bash install.sh. O use Docker, que es el resto de esta guía. El paquete de PyPI (pip install octop) es, al menos, un artefacto versionado que puede fijar a una release.

Implementar Octop con Docker Compose, fijado en v0.9.19

No hay ninguna imagen publicada para descargar a fecha de agosto de 2026. El archivo Compose incluido crea la imagen desde el repositorio, por lo que fijar una versión significa cambiar a una etiqueta de git. Es un paso adicional respecto a la mayoría de los proyectos autohospedados, ya que algo como un espacio de trabajo AFFiNE autohospedado fija una etiqueta de imagen publicada y nunca crea nada en su VPS. La rutina de clonación, cambio de etiqueta y creación que se muestra a continuación es la misma que explica la guía de implementación de openGym, así que, si ya la ha configurado una vez, su estructura le resultará familiar.

git clone https://github.com/TencentCloud/Octop.git
cd Octop
git checkout v0.9.19

Este es el servicio que define el archivo, reducido a las partes relevantes:

services:
  octop:
    build:
      context: ..
      dockerfile: docker/Dockerfile
    image: octop:latest
    container_name: octop
    restart: unless-stopped
    ports:
      - "${OCTOP_PORT:-8088}:${OCTOP_PORT:-8088}"
    volumes:
      - ${OCTOP_DATA:-~/.octop}:/data/.octop
    environment:
      - HOME=/data
      - OCTOP_BIND_HOST=0.0.0.0
      - OCTOP_PORT=${OCTOP_PORT:-8088}
      - OCTOP_DEFAULT_PASSWORD=${OCTOP_DEFAULT_PASSWORD:-octop}
      - OCTOP_ADMIN_USERNAME=${OCTOP_ADMIN_USERNAME:-admin}
      - OPENAI_API_KEY=${OPENAI_API_KEY:-}

Observe el bloque build:. image: octop:latest es el nombre de la imagen que crea usted, no una referencia a un registro, por lo que latest aquí significa lo que haya compilado más recientemente. Establezca la ruta de datos de forma explícita en lugar de dejarla en manos de un valor predeterminado y asigne una contraseña real a la cuenta de administración antes del primer arranque. Escriba esto en docker/.env:

OCTOP_PORT=8088
OCTOP_ADMIN_USERNAME=admin
OCTOP_DEFAULT_PASSWORD=<a long random password>
OCTOP_DATA=/srv/octop-data

Hay un detalle problemático que merece más atención que el resto del archivo. Compose lee docker/.env únicamente para interpolar los marcadores ${...} en el YAML. Una clave que añada a ese archivo no llega al contenedor a menos que también aparezca bajo environment: en el archivo Compose. Añadir OCTOP_ACCESS_TOKEN_TTL sólo a .env no hace absolutamente nada y no produce ningún mensaje. La alternativa es escribir las mismas claves en ~/.octop/env, dentro del directorio de datos montado, que Octop carga durante el arranque. La guía sobre archivos de entorno y secretos en Docker Compose explica por qué estos dos mecanismos no son equivalentes.

Créela e iníciela:

docker compose -f docker/docker-compose.yml up -d --build
docker compose -f docker/docker-compose.yml ps
curl http://127.0.0.1:8088/api/health

Una instancia en buen estado responde a la comprobación de estado con {"status":"ok","version":"..."}. Si obtiene cualquier otra respuesta, lea docker compose -f docker/docker-compose.yml logs -f octop antes de abrir el navegador.

Ahora asigne a la imagen que acaba de crear un nombre significativo, porque el siguiente --build sobrescribirá octop:latest y no tendrá forma de distinguir ambas imágenes:

docker image tag octop:latest octop:0.9.19

El primer arranque ejecuta octop init y escribe las credenciales iniciales en el volumen de datos:

docker exec -it octop cat /data/.octop/credential.txt

Los valores predeterminados son admin / octop y se aplican sólo durante la inicialización inicial. Este es el motivo de una pregunta muy frecuente: cambiar OCTOP_DEFAULT_PASSWORD después de que el contenedor se haya iniciado una vez no cambia nada, porque la cuenta ya existe. Cambie la contraseña desde el panel de control.

No publiques el puerto 8088

La línea ports: anterior enlaza todas las interfaces de la VPS. En cuanto se inicia el contenedor, el panel queda expuesto en Internet mediante texto sin cifrar y con una contraseña predeterminada. El valor predeterminado de OCTOP_BIND_HOST en Octop es 127.0.0.1; el archivo Compose lo sobrescribe con 0.0.0.0 porque el proceso debe aceptar tráfico desde fuera de su propio espacio de nombres de red. Esa sobrescritura es correcta. El puerto publicado es lo que te expone.

Edita la línea ports: en docker/docker-compose.yml para que la asignación sólo escuche en loopback:

    ports:
      - "127.0.0.1:${OCTOP_PORT:-8088}:${OCTOP_PORT:-8088}"

No intentes corregirlo con un archivo de sobrescritura simple. Compose concatena las listas ports de varios archivos en lugar de reemplazarlas, por lo que terminas publicando ambas asignaciones y la segunda no puede enlazarse. Si quieres mantener intacto el archivo original, usa la etiqueta !override en la secuencia. Es la forma documentada de reemplazarla en lugar de añadirla. La explicación de cómo Compose combina varios archivos cubre el resto de esas reglas de combinación.

Enlazar con loopback también resuelve un problema que de otro modo tendrías con el firewall. Docker escribe sus reglas de puertos publicados en la tabla nat antes de las cadenas que administra ufw, por lo que ufw deny 8088 no detiene un puerto de contenedor publicado. Un puerto enlazado a 127.0.0.1 nunca es accesible desde el exterior, independientemente de lo que indique ufw. Por eso es la corrección adecuada y no una alternativa secundaria.

Configurar TLS delante de la aplicación con un reverse proxy

Caddy es la opción más sencilla, porque solicita el certificado mediante ACME (automatic certificate management environment) por su cuenta y permite WebSockets sin configuración adicional:

octop.example.com {
    reverse_proxy 127.0.0.1:8088
}

nginx requiere más atención, porque Octop transmite el chat mediante un WebSocket:

server {
    listen 443 ssl;
    server_name octop.example.com;

    ssl_certificate     /etc/letsencrypt/live/octop.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/octop.example.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:8088;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_buffering off;
        proxy_read_timeout 3600s;
    }
}

Cada línea cumple una función. El chat usa WS /agents/{id}/chat/ws, por lo que, sin proxy_http_version 1.1 y las dos cabeceras de actualización, nginx responde al intento de actualización con 400 Bad Request: el panel se carga con normalidad, pero todos los mensajes que envías quedan bloqueados para siempre sin mostrar ningún error en la página. proxy_buffering off es importante porque el endpoint de reanudación human-in-the-loop devuelve text/event-stream, y los SSE (server-sent events) retenidos en un búfer del proxy llegan juntos al final en lugar de transmitirse progresivamente. proxy_read_timeout cubre las ejecuciones largas de herramientas, porque el valor predeterminado de 60 segundos interrumpe el agente a mitad de la tarea y registra upstream timed out (110: Connection timed out).

Cómo funciona la autenticación JWT detrás del proxy

Octop se autentica con un token bearer, no con una cookie. POST /api/auth/login devuelve {access_token, role, user, ...} y las solicitudes posteriores incluyen Authorization: Bearer <access_token>. Para un reverse proxy, esto es una ventaja: no hay ningún dominio de cookie, ninguna marca Secure ni ninguna regla SameSite que configurar incorrectamente, por lo que una sesión que funciona en http://127.0.0.1:8088 se comporta igual en https://octop.example.com.

Conviene conocer dos consecuencias antes de ponerlo a disposición de usuarios reales.

El WebSocket transporta el token en la URL. El endpoint es WS /agents/{id}/chat/ws?token=<jwt>, porque JavaScript del navegador no puede establecer una cabecera Authorization durante el handshake de WebSocket. TLS protege ese token durante el tránsito. No lo protege de sus propios registros: nginx escribe por defecto la línea de solicitud completa, incluida la cadena de consulta, en access_log, por lo que un token válido de un usuario real termina en un archivo de texto plano del servidor. Registre la ruta sin los argumentos. $uri es la ruta normalizada con la cadena de consulta ya eliminada, así que incluya esto en el bloque http y haga referencia a él desde el servidor:

log_format octop_noargs '$remote_addr [$time_local] '
                        '"$request_method $uri $server_protocol" '
                        '$status $body_bytes_sent';
access_log /var/log/nginx/octop.log octop_noargs;

No hay cierre de sesión por sesión. OCTOP_ACCESS_TOKEN_TTL usa 86400 de forma predeterminada, por lo que un token sigue siendo válido durante 24 horas después del inicio de sesión. La única forma documentada de invalidar uno es octop admin rotate-jwt-secret, que rota la clave de firma almacenada en ~/.octop/secrets/jwt_secret e invalida de inmediato todos los tokens pendientes, para todos los usuarios. Por tanto, cuando alguien abandona el equipo, el orden es: eliminar el usuario, rotar el secreto y pedir a los usuarios restantes que vuelvan a iniciar sesión. Si esto resulta excesivo, reduzca la duración y recuerde añadir la variable a la lista environment:, además de .env:

OCTOP_ACCESS_TOKEN_TTL=28800

La protección contra fuerza bruta está integrada: OCTOP_LOGIN_MAX_ATTEMPTS permite 5 fallos de forma predeterminada y OCTOP_LOGIN_LOCKOUT_SECONDS tiene un valor de 900, por lo que un usuario bloqueado sólo tiene que esperar quince minutos en lugar de asumir que la instalación está dañada. Octop tiene su propio almacén de usuarios y no ofrece compatibilidad documentada con OIDC en v0.9.19. Si necesita inicio de sesión único real, coloque delante un proxy de autenticación. Para eso sirve un servidor Authentik autohospedado.

Configurar Octop con un backend de modelos

Los proveedores se configuran por agente en el panel, y octop provider list muestra la configuración actual. Octop incluye ajustes predefinidos para API compatibles con OpenAI, DashScope (Qwen) y Ollama. Las credenciales se almacenan en la tabla providers de su propia base de datos SQLite. Esta elección determina el coste y qué datos salen del servidor.

Un modelo local con Ollama. No sale ningún dato del servidor y el coste se traslada a la RAM en lugar de los tokens. El detalle de integración que suele causar problemas es el siguiente: un contenedor no puede acceder al Ollama del host mediante 127.0.0.1:11434, porque esa dirección corresponde al loopback del propio contenedor. Añada una entrada de gateway del host al servicio:

    extra_hosts:
      - "host.docker.internal:host-gateway"

Después, configure la URL base del proveedor como http://host.docker.internal:11434/v1, que es la ruta compatible con OpenAI de Ollama. Introduzca cualquier cadena no vacía en el campo de la clave API, porque Ollama la ignora, pero los clientes de OpenAI no envían una clave vacía. Ollama también debe escuchar fuera del loopback para que esto funcione. Esto implica configurar OLLAMA_HOST=0.0.0.0:11434 en su unidad de systemd. Esta es la parte de riesgo: Ollama no tiene autenticación, por lo que un puerto 11434 abierto en una IP pública se convierte en un servidor de modelos disponible para quien lo encuentre primero mediante un escaneo. Permita sólo el rango privado de Docker, sudo ufw allow from 172.16.0.0/12 to any port 11434 proto tcp, y deniegue el resto. Ejecutar Ollama en un VPS explica cómo dimensionar el modelo, y la comparación entre Ollama y vLLM explica cuándo Ollama deja de ser el servidor adecuado.

Hay otra advertencia sobre los modelos locales, porque parece un error de Octop, pero no lo es. Los agentes funcionan mediante llamadas a herramientas, y el prompt del sistema, las definiciones de las herramientas y el historial forman un prompt grande. Ollama sirve los modelos con una ventana de contexto predeterminada y relativamente pequeña, por lo que el principio del prompt, donde se encuentran las definiciones de las herramientas, queda fuera de la ventana. El modelo deja de llamar a las herramientas o inventa herramientas que no existen. Aumente num_ctx a 16k o 32k y elija un modelo que sea realmente bueno para las llamadas a funciones. Una respuesta que se detiene a mitad de una frase es el problema contrario y depende de otra configuración, num_predict. Por tanto, si las respuestas llegan truncadas, conviene comprobar dónde se configura num_predict y qué indica done_reason antes de atribuir el problema al agente. Si prefiere empezar con un candidato concreto en lugar de una lista corta, Nemotron 3.5 Lightning merece una prueba. Ese artículo indica la etiqueta exacta que debe descargar, la RAM necesaria y si el rendimiento en modo CPU es suficiente.

Un gateway autohospedado. Coloque un gateway LiteLLM autohospedado entre Octop y el resto de servicios. Obtendrá una URL base única, una clave independiente por usuario, límites de gasto y un único registro. También podrá cambiar el modelo situado detrás del gateway sin editar nada en Octop.

Una API de pago. Ofrece la mejor calidad, con una contrapartida clara: el contenido de las conversaciones sale del servidor y llega al proveedor, que es precisamente una de las razones principales para autohospedar el servicio. La clave se introduce en docker/.env como OPENAI_API_KEY, y el archivo Compose ya la transmite.

Independientemente de la opción elegida, el archivo Compose también incluye OCTOP_LANGFUSE_ENABLED, LANGFUSE_PUBLIC_KEY, LANGFUSE_SECRET_KEY y LANGFUSE_BASE_URL. Así puede enviar trazas a su propia instancia de Langfuse y comprobar qué hacen realmente los agentes en lugar de intentar deducirlo desde la ventana de chat.

Usuarios, roles y biblioteca compartida de agentes

La cuenta de administración creada durante el primer arranque crea y gestiona las demás cuentas. Cada usuario tiene sus propios agentes, espacio de trabajo y credenciales. El token que conserva el navegador mantiene ese aislamiento. Además, existe un conjunto compartido de habilidades y subagentes que cualquiera puede usar. Esta es la función que hace que valga la pena ejecutar Octop para una familia: una persona crea un buen agente de investigación una sola vez y nadie más tiene que volver a crearlo.

Tenga cuidado con las herramientas. Octop anuncia la aprobación de herramientas y las protecciones para comandos de shell, y ambas funciones son reales. Sin embargo, un agente que ejecuta comandos de shell los ejecuta dentro del contenedor de Octop, con el volumen de datos montado. Las protecciones limitan lo que puede hacer un prompt descuidado. No constituyen un límite de aislamiento. Por tanto, mantenga activada la aprobación de herramientas para cualquier persona a la que no entregaría acceso a un shell. Si compara esta opción con otras alternativas, el análisis comparativo de agentes de IA autoalojados explica cómo gestiona cada una esta función.

Actualizar un proyecto que publica versiones con esta frecuencia

[
  {
    "version": "v0.9.16",
    "days_since_previous_release": 2
  },
  {
    "version": "v0.9.17",
    "days_since_previous_release": 3
  },
  {
    "version": "v0.9.18",
    "days_since_previous_release": 1
  },
  {
    "version": "v0.9.19",
    "days_since_previous_release": 3
  }
]

Estas son las fechas de las etiquetas del repositorio, contabilizadas el 7 de agosto de 2026. 4 versiones etiquetadas se publicaron en nueve días, con un intervalo mínimo de 1 día, y v0.9.19 llegó 3 días después de la etiqueta anterior. Esta frecuencia es una buena señal sobre el proyecto y un mal motivo para ejecutar latest. Lea los cambios antes de aplicarlos:

cd Octop
git fetch --tags
git tag --sort=-creatordate | head
NEW_TAG=$(git tag --sort=-creatordate | head -1)
git log --oneline "v0.9.19..$NEW_TAG"

Haga siempre una copia de seguridad antes, porque las migraciones de la base de datos se ejecutan durante el arranque y una migración fallida en un proyecto anterior a 1.0 es un problema que tendrá que resolver:

docker compose -f docker/docker-compose.yml stop
sudo tar czf octop-backup-$(date +%F).tgz -C /srv octop-data
docker compose -f docker/docker-compose.yml start

Después, cambie a la nueva etiqueta y vuelva a compilar con docker compose -f docker/docker-compose.yml up -d --build. Si algo falla, cambiar a la etiqueta anterior y volver a compilar restaura el código, pero sólo el archivo tar restaura la base de datos.

Ese archivo tar contiene octop.db, config.json, el secreto de firma de JWT y credential.txt, por lo que es tan sensible como el propio servidor. Manténgalo con el modo 600 y conserve una copia fuera del equipo. Para instalaciones más grandes, el proyecto también publica docker/docker-compose.postgres.yml, que ejecuta PostgreSQL con pgvector en lugar de SQLite.

Modos de fallo y mensajes que verá

La comprobación de estado nunca responde. curl http://127.0.0.1:8088/api/health se bloquea o rechaza la conexión. Lea docker compose -f docker/docker-compose.yml logs -f octop. Un contenedor que termina durante la primera inicialización normalmente no puede escribir en el directorio de datos, así que compruebe el propietario de lo que haya configurado en OCTOP_DATA.

El panel se carga, pero el chat se bloquea. La página no muestra ningún error y nunca llega una respuesta. Abra la consola del navegador y busque una conexión fallida a wss://octop.example.com/agents/.../chat/ws. El proxy no está reenviando la actualización de la conexión. Añada las cabeceras proxy_http_version 1.1, Upgrade y Connection.

La respuesta completa aparece de una vez, varios segundos tarde. La transmisión funciona, pero el almacenamiento en búfer está activado. Configure proxy_buffering off.

bind: address already in use. Ya hay otro proceso usando 8088. sudo ss -tlnp | grep 8088 identifica el proceso. Esto también ocurre si añadió una segunda entrada ports en un archivo de sustitución en lugar de editar la original.

Se rechaza la contraseña correcta. Cinco intentos incorrectos activan un bloqueo de 900 segundos. Espere a que termine en lugar de reinstalar.

La nueva contraseña de .env no tuvo efecto. Esas credenciales sólo se aplican durante la primera inicialización. Cámbiela en el panel.

El agente responde, pero nunca ejecuta una herramienta. Casi siempre se debe a un problema del modelo local: la ventana de contexto es demasiado pequeña para las definiciones de las herramientas o el modelo no gestiona bien las llamadas a funciones. Aumente num_ctx y pruebe un modelo diseñado para usar herramientas.

FAQ

¿Es Octop un reemplazo de Open WebUI?

Sólo si necesita lo que añade. Open WebUI es una interfaz de chat delante de un modelo y cumple bien esa función para una persona o un hogar donde existe confianza. Octop añade cuentas con un rol de administrador, espacios de trabajo y credenciales por usuario, y una biblioteca seleccionable de agentes especializados. Así, varias personas pueden compartir un servidor sin compartir un mismo historial. Si una sola cuenta es suficiente para usted, Open WebUI es la opción más sencilla y mucho más madura.

¿Por qué no debería usar el script de instalación de Octop con curl?

El script se sirve desde un bucket de Tencent Cloud Object Storage y no desde el repositorio, por lo que no está cubierto por ninguna etiqueta ni confirmación de git. No puede comparar lo que hace hoy con lo que hacía la semana pasada, y al canalizarlo hacia bash se ejecuta antes de que pueda leerlo. Además, se instala en el host con su propio entorno de Python 3.12, fuera del gestor de paquetes. Descárguelo y léalo primero, o haga el despliegue con Docker Compose desde una etiqueta que haya comprobado.

¿Puede Octop usar un modelo local en lugar de una API de pago?

Sí. Octop admite API compatibles con OpenAI e incluye un ajuste predefinido para Ollama. Por tanto, apuntarlo a http://host.docker.internal:11434/v1 funciona después de añadir extra_hosts: ["host.docker.internal:host-gateway"] al contenedor y establecer OLLAMA_HOST=0.0.0.0:11434 en el host. Filtre el puerto 11434 para que sólo sea accesible desde el rango de direcciones de Docker, porque Ollama no incluye autenticación propia. Espere tener que aumentar num_ctx de Ollama a 16k o más, ya que los prompts de los agentes con definiciones de herramientas superan el tamaño de contexto predeterminado y el modelo deja de llamar a las herramientas.

¿Necesito un proxy inverso o puedo abrir el puerto 8088?

Necesita el proxy. El archivo Compose incluido con Octop publica 8088 en todas las interfaces y no usa TLS, por lo que las contraseñas y los tokens bearer atravesarían Internet en texto claro. Cambie el puerto publicado a 127.0.0.1:8088:8088 y coloque Caddy o nginx delante con un certificado. Con nginx, reenvíe las cabeceras de actualización de WebSocket y establezca proxy_buffering off. De lo contrario, la página se cargará, pero el chat no responderá y no mostrará ningún error.

¿Octop está listo para producción?

Está en una versión anterior a 1.0 y publica varias versiones etiquetadas por semana en agosto de 2026. Trátelo como un proyecto prometedor, no como un producto consolidado. Puede funcionar para una familia o un equipo interno pequeño si fija una etiqueta exacta, revisa el registro de commits antes de cada actualización y hace una copia de seguridad del volumen de datos antes de cada reconstrucción. No lo ejecute en latest ni almacene todavía datos de clientes en él.