Guía Completa para Configurar y Optimizar Dify en tu Propio Servidor

Instalar Dify en un servidor propio permite crear chatbots, agentes y aplicaciones con inteligencia artificial sin depender completamente de una plataforma alojada por terceros. Sin embargo, pasar de una prueba local a una instancia disponible en Internet exige ocuparse de aspectos que el editor visual no resuelve por sí solo, como las contraseñas, los puertos, el cifrado HTTPS, las copias de seguridad y el consumo de recursos.

En esta guía veremos cómo instalar Dify con Docker en un VPS, modificar su configuración, proteger el acceso mediante un proxy inverso y preparar los datos persistentes para que una actualización o un fallo del servidor no destruya el proyecto.

Qué necesitas para instalar Dify en un VPS

Dify puede desplegarse en diferentes distribuciones Linux. Una opción adecuada es utilizar una versión de Ubuntu con soporte activo, como Ubuntu 24.04 LTS, aunque no es la única compatible.

La documentación oficial establece los siguientes requisitos básicos para el despliegue mediante Docker Compose:

• Un servidor Linux con al menos 2 núcleos de CPU y 4 GB de RAM.
• Docker Engine 19.03 o una versión posterior.
• Docker Compose 2.24.0 o posterior.
• Git, Curl y JQ para utilizar el comando recomendado de descarga.
• Espacio suficiente para Postgres, los documentos, los registros y la base vectorial.
• Un dominio si quieres publicar la instancia mediante HTTPS.

Cuatro gigabytes de memoria pueden ser suficientes para realizar pruebas, pero 8 GB proporcionan un margen mucho más razonable cuando se procesan documentos o se utilizan varios servicios al mismo tiempo. Los modelos contratados mediante API se ejecutan en la infraestructura del proveedor, pero Postgres, Redis, Weaviate, los workers y el resto de los componentes de Dify sí consumen recursos del VPS.

Antes de continuar, comprueba las versiones instaladas:

docker --version
docker compose version
git --version
curl --version
jq --version

Si quieres conectar posteriormente la plataforma con un modelo ejecutado en tu propio ordenador, puedes consultar cómo solucionar los problemas de conexión entre Dify y Ollama.

Descargar Dify y preparar el archivo de configuración

Para evitar desplegar accidentalmente una rama de desarrollo, la documentación actual recomienda clonar la versión publicada más reciente. El comando oficial obtiene primero la etiqueta correspondiente desde GitHub:

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

Después, entra en el directorio de Docker y crea el archivo de configuración a partir de la plantilla:

cd dify/docker
cp .env.example .env

El archivo .env contiene las variables principales del despliegue. Las versiones recientes de Dify también incluyen plantillas específicas dentro de docker/envs/ para determinados servicios y bases vectoriales.

Conviene conservar las modificaciones en estos archivos de entorno y evitar editar directamente docker-compose.yaml salvo que exista una necesidad concreta. De esta forma, será más sencillo comparar la configuración al actualizar Dify.

Cambiar las contraseñas y claves predeterminadas

No levantes una instancia pública sin revisar antes sus credenciales. Abre .env y localiza las variables relacionadas con Postgres, Redis, la clave secreta de la aplicación y cualquier otro servicio habilitado.

Las contraseñas deben ser largas, aleatorias y diferentes entre sí. En Linux puedes generar valores seguros con OpenSSL:

openssl rand -base64 48

Ejecuta el comando varias veces para obtener valores independientes. No publiques después el archivo .env en GitHub ni lo adjuntes a una incidencia, ya que puede contener claves capaces de dar acceso a la base de datos y a los proveedores de modelos.

También debes proteger la cuenta administradora creada durante la instalación. Dify permite gestionar aplicaciones, credenciales, conocimientos y extensiones desde su consola, por lo que dejar el panel expuesto con una contraseña débil puede comprometer toda la instancia.

Levantar los contenedores de Dify

Una vez guardada la configuración, inicia el conjunto de servicios:

docker compose up -d

Dify no se compone de un único contenedor. El despliegue actual incluye servicios para la API, la interfaz web, los workers, los plugins y diferentes tareas programadas, además de dependencias como Postgres, Redis, Nginx, Weaviate y los mecanismos de aislamiento.

Comprueba que han arrancado correctamente:

docker compose ps

Los servicios deben aparecer como Up o healthy. El contenedor init_permissions puede mostrarse como finalizado porque solo se ejecuta una vez para preparar los permisos del almacenamiento.

Si algún servicio entra en un ciclo de reinicios, examina sus registros:

docker compose logs --tail=100 nombre-del-servicio

Cuando el despliegue funcione, abre inicialmente:

http://IP_DEL_SERVIDOR/install

Desde esa página podrás crear la primera cuenta administradora. Después, el acceso habitual se realiza desde la dirección principal del servidor.

Cómo cambiar los puertos de Dify

El proxy Nginx incluido en el despliegue utiliza normalmente el puerto 80 para HTTP y el 443 para HTTPS. Estos puertos pueden modificarse desde .env mediante las siguientes variables:

EXPOSE_NGINX_PORT=8080
EXPOSE_NGINX_SSL_PORT=8443

En este ejemplo, Dify quedaría publicado en los puertos 8080 y 8443. Después de realizar el cambio, reinicia los contenedores:

docker compose down
docker compose up -d

Cambiar el puerto puede resolver un conflicto con otro servicio, pero no sustituye al cifrado, la autenticación ni el firewall. Un panel vulnerable no se vuelve seguro simplemente por utilizar una numeración menos habitual.

Si Dify va a quedar detrás de otro proxy inverso, lo más prudente es impedir que su puerto HTTP sea accesible directamente desde Internet. Dependiendo de la arquitectura, puedes limitar la publicación a la interfaz de loopback o bloquear el acceso externo mediante el firewall.

Publicar Dify mediante HTTPS

Para un servidor accesible desde Internet, utiliza un dominio y coloca delante un proxy inverso como Nginx, Caddy o Traefik. Este componente recibirá las conexiones HTTPS y las enviará al puerto interno donde escucha Dify.

El firewall debería permitir solamente los servicios necesarios. Una configuración básica suele abrir:

• El puerto utilizado por SSH, preferiblemente restringido por dirección IP cuando sea posible.
• El puerto 80 para validar o redirigir conexiones HTTP.
• El puerto 443 para servir Dify mediante HTTPS.

Revisa las reglas tanto para IPv4 como para IPv6. Un servidor puede parecer protegido en IPv4 y seguir exponiendo los mismos servicios mediante una dirección IPv6 pública.

Después de cambiar el dominio o la dirección pública, también puede ser necesario revisar variables como CONSOLE_API_URL, CONSOLE_WEB_URL, SERVICE_API_URL, APP_API_URL y APP_WEB_URL. Una configuración incoherente puede provocar errores de inicio de sesión, redirecciones incorrectas o bloqueos de CORS.

Configurar una base de datos vectorial

Dify utiliza una base de datos vectorial para almacenar los embeddings empleados por sus bases de conocimiento. El despliegue estándar utiliza Weaviate, pero la plataforma admite alternativas como Qdrant, Milvus, MyScale, PGVector, OpenSearch y otras.

La selección principal se realiza mediante la variable VECTOR_STORE:

VECTOR_STORE=weaviate

Para utilizar otro sistema no basta siempre con cambiar este valor. También hay que proporcionar sus credenciales, dirección, puerto, base de datos y demás parámetros. Las plantillas correspondientes se encuentran dentro de:

docker/envs/vectorstores/

Por ejemplo, puedes copiar la plantilla del proveedor elegido, eliminar la terminación .example y editar la copia con los datos reales de conexión.

No existe una base vectorial que sea universalmente superior. La mejor elección depende del tamaño de la colección, el tipo de filtros, la latencia, la facilidad de mantenimiento, el coste y la infraestructura disponible. Utilizar una opción externa también introduce una dependencia adicional y obliga a proteger sus credenciales.

Además, cambiar VECTOR_STORE no traslada automáticamente los índices ya creados. Dify conserva en cada base de conocimiento el tipo de almacenamiento utilizado, por lo que una migración exige seguir el procedimiento correspondiente y verificar que los documentos continúan recuperándose correctamente.

Si quieres comparar una plataforma especializada en RAG con este sistema, puedes consultar nuestra comparativa entre Dify y RAGFlow.

Crear una base de conocimiento y ajustar los fragmentos

Una vez configurado el almacenamiento vectorial, entra en la sección de conocimientos y crea una nueva base. Puedes importar documentos, dividirlos en fragmentos y generar sus embeddings mediante un modelo compatible.

El tamaño de los fragmentos y el solapamiento influyen directamente en la recuperación:

• Los fragmentos demasiado pequeños pueden perder el contexto necesario para responder.
• Los fragmentos excesivamente grandes aumentan el coste y pueden introducir información irrelevante.
• El solapamiento ayuda a conservar frases o ideas que quedan entre dos divisiones.
• El modelo de embeddings debe ser compatible con el idioma y el tipo de contenido utilizado.

No existe un tamaño perfecto para todos los documentos. Un manual técnico, una tabla de especificaciones y una colección de preguntas frecuentes requieren estrategias diferentes. La configuración debe comprobarse mediante preguntas reales y revisando qué fragmentos recupera Dify.

RAG puede reducir las respuestas inventadas, pero no las elimina. El modelo todavía puede interpretar mal el contexto, combinar fragmentos incompatibles o responder sin suficiente evidencia. Conviene indicarle que reconozca cuándo la documentación no contiene la respuesta.

Conectar servicios externos y herramientas

Dify permite ampliar los agentes mediante plugins, herramientas, solicitudes HTTP, servicios OpenAPI y servidores MCP. Estas integraciones permiten consultar aplicaciones externas, ejecutar acciones o incorporar datos durante un flujo.

Firecrawl, por ejemplo, puede utilizarse para extraer contenido web y entregarlo a un agente o flujo. Antes de rastrear una página debes comprobar sus condiciones de uso, las restricciones de acceso y la normativa aplicable. Además, el contenido recién obtenido no debe considerarse verdadero automáticamente: puede estar desactualizado, manipulado o diseñado para alterar el comportamiento del agente.

Cuando una herramienta puede realizar acciones, aplica siempre el menor nivel de permisos posible. Un agente que solo necesita consultar información no debería recibir una credencial capaz de modificar o eliminar datos.

¿Se puede conectar Dify con Home Assistant mediante MCP?

Sí, pero requiere distinguir correctamente las funciones de cada plataforma. MCP significa Model Context Protocol. Home Assistant puede actuar como servidor MCP para proporcionar herramientas relacionadas con las entidades que el usuario haya decidido exponer.

El servidor MCP de Home Assistant se publica actualmente en la ruta /api/mcp y utiliza Streamable HTTP. La autenticación puede realizarse mediante OAuth o, si el cliente lo admite, mediante un token de acceso de larga duración.

La compatibilidad dependerá de que la versión de Dify y el conector MCP instalado admitan el transporte y la autenticación utilizados por Home Assistant. No conviene seguir tutoriales antiguos que indiquen únicamente una dirección SSE sin comprobar la versión de ambos sistemas.

Por seguridad, expón solamente las entidades necesarias. Dar acceso general a cerraduras, alarmas, cámaras y otros dispositivos sensibles aumenta considerablemente las consecuencias de una instrucción mal interpretada o de una credencial robada.

Utilizar la API de una aplicación Dify

Cada aplicación publicada en Dify puede utilizarse mediante una API REST. La clave se genera desde la propia aplicación y debe almacenarse únicamente en el backend que realiza las llamadas.

En una instalación autohospedada, la URL pública depende del dominio y de la configuración del proxy. No debes utilizar automáticamente el puerto interno 5001 desde dispositivos externos ni asumir que el nombre del contenedor será siempre dify-api-1.

Los nombres de servicio y puertos internos solamente son apropiados cuando dos contenedores comparten una red Docker y la arquitectura ha sido configurada expresamente para ello. Para integraciones externas, utiliza la URL pública protegida mediante HTTPS.

La clave de una aplicación no debe incluirse en JavaScript público, aplicaciones móviles sin backend ni firmware distribuido a usuarios. Cualquiera que extraiga esa credencial podría consumir el servicio y generar costes.

Dify también se puede integrar con plataformas de automatización. En esta guía explicamos cómo conectar Dify con n8n para ejecutar procesos externos.

Realizar copias de seguridad de Dify

Los contenedores pueden volver a crearse, pero los datos guardados en sus volúmenes no. Antes de actualizar o modificar el despliegue, guarda como mínimo:

• El archivo .env.
• Los archivos personalizados situados en docker/envs/.
• El directorio volumes.
• Cualquier configuración adicional del proxy inverso.
• Los certificados y credenciales que no se encuentren dentro de los volúmenes.

El directorio de volúmenes contiene información persistente como la base de datos, los documentos y otros datos necesarios para reconstruir la instancia. La copia debe almacenarse fuera del propio VPS y probarse periódicamente. Una copia que nunca se ha restaurado no ofrece la certeza de que sea utilizable.

Cómo actualizar Dify sin perder la configuración

No conviene automatizar una actualización de producción limitándose a ejecutar git pull. Las instrucciones pueden cambiar entre versiones y algunas actualizaciones requieren migraciones o modificaciones adicionales.

Antes de actualizar:

1. Consulta las notas de la versión de destino.
2. Realiza una copia de .env, envs y volumes.
3. Compara tus archivos con las nuevas plantillas .env.example.
4. Descarga las nuevas imágenes de los contenedores.
5. Reinicia el despliegue y examina el estado y los registros.
6. Prueba el inicio de sesión, las aplicaciones, los plugins y la recuperación de documentos.

Después de la actualización, ejecuta:

docker compose ps
docker compose logs --tail=100

No borres inmediatamente las imágenes o copias anteriores. Consérvalas hasta haber comprobado que los flujos, las bases de conocimiento y las integraciones funcionan correctamente.

Una instalación propia también necesita mantenimiento

Autohospedar Dify ofrece un mayor control sobre la infraestructura, pero no significa que todos los datos permanezcan automáticamente en el servidor. Si conectas modelos de OpenAI, Anthropic, Google u otro proveedor remoto, los prompts y archivos necesarios para cada solicitud pueden seguir saliendo de tu infraestructura.

Antes de utilizar información sensible, revisa qué datos procesa cada proveedor, limita las credenciales, cifra las conexiones y evita almacenar más información de la necesaria. También tendrás que vigilar el espacio disponible, los registros, las actualizaciones, los certificados y el estado de los contenedores.

La mejor forma de empezar es desplegar una instancia pequeña, protegerla mediante HTTPS y crear una aplicación sencilla. Cuando esa base sea estable, podrás añadir conocimientos, plugins, automatizaciones y servidores MCP sin convertir el sistema en una colección difícil de mantener.