Instalar Dify en un VPS con Docker Compose

Qué es Dify y qué se dispone a ejecutar

Dify es una plataforma autoalojable para crear aplicaciones sobre modelos de lenguaje de gran tamaño. Ofrece una interfaz web para diseñar aplicaciones de chat, agentes y pipelines de recuperación, una API para llamarlos desde su propio código y un único lugar para gestionar prompts, datasets y claves de modelos. Es el tipo de herramienta que un equipo pequeño instala para que todos trabajen sobre una base privada compartida, en lugar de dispersar las claves de API entre scripts. Si conceptos como agente, llamada a una herramienta y pipeline de recuperación todavía no están claros, repasar esos conceptos desde cero primero hará que las pantallas del constructor de Dify parezcan controles conocidos y no una pared de interruptores sin etiquetas.

Ejecutarlo por su cuenta implica ejecutar muchos componentes. En octubre de 2026, la pila predeterminada documentada de Dify inicia 15 contenedores de ejecución continua y una tarea de una sola ejecución que establece los permisos de los archivos y termina. Siete son servicios propios de Dify: el servidor de API, un servidor websocket, un worker en segundo plano, un scheduler, el frontend web, un daemon de plugins y un backend de agentes. Los otros ocho son dependencias: una base de datos Postgres, una caché Redis, una base de datos vectorial Weaviate, un punto de entrada nginx, dos sandboxes de código y dos proxies SSRF. Docker Compose los conecta, pero sigue siendo una pila real, y el mínimo documentado de Dify es 4 GiB de RAM y dos núcleos de CPU. Si ese VPS también va a ejecutar otro servicio, dimensione el sistema a partir de valores medidos y no de los valores anunciados, porque los límites reales de RAM de PhotoPrism e Immich están muy por encima de sus mínimos publicados, y un servidor de fotos que comparta el equipo agotará primero la base de datos y el almacén vectorial de Dify. La contención de CPU afecta de la misma forma: una biblioteca de Jellyfin presentada como un videoclub de los años 90 apenas consume recursos mientras sólo se navega por las carátulas, pero en cuanto alguien inicia una transcodificación, las colas de workers de Dify quedan detrás de ella. La ventaja es que el número de contenedores de Dify es fijo, independientemente del número de aplicaciones que cree, lo que genera un coste más predecible que OpenBot, donde cada compañero de trabajo de IA obtiene su propio contenedor y su propio navegador y cada nueva incorporación vuelve a elevar el mínimo de memoria.

Dify contiene las claves de API de sus modelos y, a menudo, documentos privados que ha cargado para la recuperación. Por eso, trate el equipo donde se ejecuta como un sistema sensible desde el primer minuto. Esta guía instala Dify y después lo protege como protegería cualquier servicio que almacene secretos.

Requisitos previos

Necesita un VPS con Ubuntu 24.04, al menos 4 GiB de RAM y dos núcleos de CPU, Docker con el complemento Docker Compose instalado (Dify requiere Compose 2.24.0 o posterior) y un usuario con sudo o que pertenezca al grupo docker. El comando de clonación que aparece a continuación también usa git, curl y jq. Si Docker es nuevo para usted, los conceptos básicos de Docker Compose en un VPS explican la instalación y los comandos principales que presupone esta guía. También conviene tener un nombre de dominio que apunte al servidor, porque necesitará TLS delante de Dify en lugar de usar una dirección IP directa.

Paso 1: Obtenga Dify y sus archivos de Compose

Dify mantiene su configuración de Docker en el repositorio principal. Clone la versión más reciente, no la rama de desarrollo, y acceda al directorio docker:

git clone --branch "$(curl -s https://api.github.com/repos/langgenius/dify/releases/latest | jq -r .tag_name)" https://github.com/langgenius/dify.git
cd dify/docker
cp .env.example .env

Si el clonado falla con el error "Remote branch null", la consulta a la API de GitHub no devolvió ningún resultado. Elija una versión en la página de versiones y pásela manualmente a --branch.

El archivo .env contiene la configuración principal. Léalo antes de iniciar cualquier proceso. Al principio, preste atención a los valores que establecen contraseñas y secretos: SECRET_KEY, la contraseña de Postgres y la contraseña de Redis. SECRET_KEY se incluye vacío y, si lo deja así, Dify genera una clave y la guarda en su directorio de almacenamiento. Las contraseñas son diferentes: el archivo de ejemplo establece el mismo difyai123456 para Postgres y Redis, además de claves fijas y conocidas públicamente para el sandbox de código, el daemon de plugins y Weaviate. Dejar esos valores sin cambiar es la causa más habitual de que una instancia de Dify autohospedada termine comprometida. Si prefiere establecer su propia clave secreta, genere una:

openssl rand -base64 42

Pegue el resultado en SECRET_KEY y establezca un valor seguro y exclusivo para cada campo de contraseña y clave del archivo. La contraseña de Redis también aparece dentro de CELERY_BROKER_URL. Cámbiela allí también; de lo contrario, el worker no podrá conectarse a Redis.

Paso 2: Inícielo

Inicie la pila:

docker compose up -d

La primera ejecución descarga varias imágenes e inicializa la base de datos, así que espere un minuto. Compruebe que los contenedores estén en buen estado:

docker compose ps

Cada servicio de ejecución continua debe leer running; la tarea de permisos puntual termina cuando completa su trabajo. Dify sirve su interfaz web mediante un contenedor nginx incluido, en el puerto 80 de forma predeterminada. La primera vez que acceda a http://YOUR_SERVER/install, cree la cuenta de administrador. Hágalo inmediatamente, antes de que cualquier otra persona pueda acceder al puerto, porque mientras no exista esa cuenta, cualquiera que cargue la página puede registrarla y hacerse con el control de la instancia.

Paso 3: No lo exponga directamente. Coloque TLS y un firewall delante

Aquí es donde terminan la mayoría de las instalaciones rápidas y comienzan la mayoría de los incidentes. El propio nginx de Dify escucha en el puerto 80, sin cifrado, en todas las interfaces, y también publica el puerto 443. No quiere que sus credenciales de administrador ni sus claves de modelo viajen mediante HTTP sin cifrar, ni que los servicios internos sean accesibles desde el exterior.

Restrinja el servidor con un firewall de denegación predeterminada que permita sólo SSH y el tráfico web:

sudo ufw default deny incoming
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

Recuerde que un firewall que sólo cubre IPv4 puede dejar esos mismos puertos abiertos en IPv6: la brecha del firewall de IPv6 que afecta a tantos usuarios que alojan servicios por su cuenta. Confirme que ambas pilas estén filtradas. Tenga en cuenta también que los puertos que Docker publica se gestionan mediante las reglas de firewall propias de Docker, no mediante las de ufw, y que la pila predeterminada publica el puerto de depuración del daemon de plugins, 5003, en todas las interfaces. Establezca EXPOSE_PLUGIN_DEBUGGING_PORT en .env con el valor 127.0.0.1:5003, salvo que realmente necesite depurar plugins desde otra máquina.

Para TLS, la opción más limpia es enlazar el puerto web de Dify con loopback y ejecutar delante un reverse proxy con un certificado de Let's Encrypt, de modo que lo único expuesto en Internet sea el proxy mediante HTTPS. .env de Dify permite cambiar el puerto expuesto; configúrelo para que se enlace en 127.0.0.1 y dirija el proxy a esa dirección. Haga lo mismo con EXPOSE_NGINX_SSL_PORT, porque el nginx de Dify reclama el puerto 443 del host de forma predeterminada y su proxy lo necesita. Las ideas de refuerzo para agentes descritas en ejecutar un agente de IA de forma segura en un VPS también se aplican aquí: mantenga los componentes en loopback, exponga sólo lo que deba ser público y deje que una única puerta de entrada reforzada gestione TLS. Si la interfaz de una herramienta es sólo para usted y nunca necesita un certificado, omita el proxy y acceda mediante un túnel SSH, como en alojar por cuenta propia el escáner de seguridad open-kritt, que mantiene su panel enlazado con loopback y lo reenvía a su portátil en lugar de publicarlo. Si todo un equipo necesita Dify pero no Internet pública, una red superpuesta amplía esa idea más allá de un solo portátil: anunciar la subred privada del servidor en su tailnet permite que cada dispositivo autorizado acceda al builder mediante una dirección privada, mientras el firewall permanece cerrado a todo excepto SSH. Si administra este servidor mediante un agente de programación en lugar de hacerlo manualmente, determine cuánto puede hacer sin supervisión antes de entregarle las claves, porque el modo de permisos en el que deja Claude Code decide si se detiene para preguntar antes de reescribir .env o reiniciar la pila. Si termina con una sesión siguiendo los registros de los contenedores mientras otra edita la configuración del proxy, esas dos sesiones pueden pasarse texto entre sí en el mismo servidor, lo que evita copiar la salida entre terminales cada vez que reinicia la pila.

Paso 4: Manténgalo actualizado

Dify evoluciona rápidamente, y las actualizaciones incluyen correcciones de seguridad. Como clonó una etiqueta de versión, actualizarlo implica cambiar a la siguiente etiqueta en lugar de extraer una rama. Haga una copia de seguridad de la base de datos primero y, después, ejecute lo siguiente desde el directorio docker:

docker compose down
git fetch --tags
git checkout NEW_VERSION
docker compose pull
docker compose up -d

Las migraciones de la base de datos se ejecutan automáticamente durante el arranque. Algunas no se pueden revertir. Por eso la copia de seguridad se realiza primero. Lea las notas de la versión antes de cada actualización, no sólo antes de las principales. Dify indica que los pasos de actualización varían entre versiones. Por ejemplo, las notas de la versión 1.17.1, de septiembre de 2026, indican que quienes ejecuten el Weaviate incluido con datos existentes no deben actualizar directamente a esa versión. Deben pasar por cada versión menor.

Dify también cambia el esquema de .env entre versiones. Después de cambiar a una etiqueta nueva, compare .env.example con su .env y aplique sus cambios sobre la nueva versión. Una variable nueva que no haya definido puede impedir que un contenedor se inicie.

Paso 5: Haga copias de seguridad de lo que no puede regenerar

Hay dos elementos irremplazables en un servidor Dify: la base de datos Postgres, que contiene sus aplicaciones, usuarios y ajustes, y el volumen que almacena los documentos cargados y el índice vectorial. Ambos se encuentran en volúmenes de Docker dentro del directorio docker. Cree snapshots según un calendario y copie esos snapshots fuera del servidor. Esos snapshots contienen todas las claves de modelo y los documentos cargados en un solo archivo, por lo que debe cifrarlos antes de sacarlos del servidor, por la misma razón que una copia de seguridad de Vaultwarden resulta ser el punto débil de un servidor de contraseñas sólido. Una clave de API de un modelo se puede volver a emitir; la aplicación que tardó una semana en crear no. El mismo criterio se aplica a cualquier agente cuyo estado deba sobrevivir a la máquina donde se ejecuta: mantener KiroCrew en ejecución como contenedor permanente consiste en crear snapshots de la memoria y de las programaciones que, de otro modo, desaparecerían en el siguiente reinicio.

Cuando quiera que los agentes creados aquí accedan a algo más que sus propios conjuntos de datos y busquen en la web en tiempo real, dirigirlos a una instancia de SearXNG autohospedada mantiene el flujo de consultas en hardware bajo su control, aunque conviene informarse sobre la superficie de ataque de prompt injection que se abre antes de activarla. Para un agente más autónomo que ejecute código, consulte autohospedar Agent Zero, y crear su propio agente de IA en un VPS cubre los fundamentos en los que se basan todos ellos.

FAQ

¿Cuáles son los requisitos del sistema para alojar Dify por cuenta propia?

Dify documenta un mínimo de 4 GiB de RAM y dos núcleos de CPU, además de Docker Compose 2.24.0 o posterior. Ese mínimo refleja el tamaño de la pila predeterminada: 15 contenedores de ejecución prolongada y una tarea de inicialización única, a fecha de octubre de 2026. Reserve suficiente espacio en disco para los documentos cargados y el índice vectorial. Necesitará más memoria si hay otros servicios en el mismo servidor.

¿Es seguro exponer Dify directamente en el puerto 80?

No. El servidor web incluido con Dify escucha en HTTP sin cifrar y expone el inicio de sesión de administración y las claves de API de los modelos. Coloque un reverse proxy con un certificado de Let's Encrypt delante de Dify. Enlace el puerto propio de Dify a loopback y permita que sólo el proxy HTTPS sea accesible desde Internet. Aplique también un firewall con denegación predeterminada que cubra IPv4 e IPv6.

¿Cómo actualizo una instancia de Dify alojada por cuenta propia?

Haga una copia de seguridad de la base de datos. Después, desde el directorio docker, ejecute docker compose down, git fetch --tags, git checkout la nueva etiqueta de release, docker compose pull y docker compose up -d. Lea primero las notas de la release. Los pasos de actualización varían entre releases, las migraciones pueden ser irreversibles y Dify a veces añade nuevas variables .env. Si falta una de ellas, un contenedor puede no iniciarse.

¿Qué debo hacer primero después de instalar Dify?

Visite /install y cree inmediatamente la cuenta de administración. Hasta que exista esa cuenta, cualquiera que pueda acceder a la página puede reclamarla. Configúrela en cuanto los contenedores estén operativos y antes de abrir el firewall a Internet.