Desplegar la plataforma de aplicaciones de IA Dify en un VPS (2026): guía para crear una base de conocimiento RAG privada, flujos de trabajo y agentes

No te apresures a desplegar. Dify es bastante más pesado que n8n y más complejo que una interfaz de chat normal. Estos escenarios son los que realmente merecen la pena:

Si solo quieres conversar tú mismo con los modelos, Open WebUI es más ligero. Si solo quieres conectar Telegram, Webhooks, hojas de cálculo y correo, n8n es más adecuado.

Pero si quieres "subir un montón de materiales y luego hacer que la IA responda preguntas según los materiales", Dify resulta muy cómodo.

La afirmación habitual sobre el requisito mínimo oficial de Dify es 2 núcleos y 4 GB, pero en el uso real, 4 GB es el mínimo, no la línea cómoda.

El Docker Compose predeterminado de Dify levanta un grupo de servicios: API, Worker, Web, PostgreSQL, Redis, base de datos vectorial, Sandbox, Nginx, servicios relacionados con plugins, etc. No es una pequeña herramienta de un solo contenedor.

Mi recomendación es elegir así:

A mucha gente le va mal no porque la CPU sea insuficiente, sino porque la memoria no basta. Dify puede consumir normalmente solo 2-4 GB, pero durante la división de documentos, el Embedding y la indexación puede dispararse de repente. No fuerces instancias pequeñas de 1C1G o 1C2G; al final lo más probable es que el OOM Killer mate al worker.

Si el presupuesto es limitado, mejor elige 2C4G + Swap que torturarte con una máquina de 1 GB.

A continuación se usa como ejemplo un VPS con Ubuntu/Debian.

Primero actualiza el sistema:

apt update && apt upgrade -y

Instala Docker:

curl -fsSL https://get.docker.com | bash
systemctl enable --now docker

Instala el plugin de Compose:

docker compose version

Si no se muestra ninguna versión, instálalo:

apt install -y docker-compose-plugin

En una máquina con 4 GB de memoria se recomienda activar Swap primero:

fallocate -l 4G /swapfile
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile

echo '/swapfile none swap sw 0 0' >> /etc/fstab

Confirma:

free -h

Swap no es una maravilla de rendimiento, pero puede evitar que el sistema mate directamente a Dify al indexar documentos.

Dify recomienda oficialmente iniciar desde la configuración de Docker del repositorio. El proceso es aproximadamente:

cd /opt

git clone https://github.com/langgenius/dify.git
cd dify/docker

cp .env.example .env

Luego modifica primero .env. Como mínimo, presta atención a esto:

vim .env

Comprobaciones sugeridas:

• SECRET_KEY: no uses el valor predeterminado;
• CONSOLE_WEB_URL: dirección del panel;
• APP_WEB_URL: dirección que usan los usuarios para acceder a la aplicación;
• FILES_URL: dirección de acceso a archivos;
• Contraseña de la base de datos: no uses la contraseña débil predeterminada;
• Concurrencia del Worker: no la pongas demasiado alta en máquinas con poca memoria.

Inicia:

docker compose up -d

Ver contenedores:

docker compose ps

Ver registros:

docker compose logs -f api

El primer arranque será bastante lento, sobre todo al descargar imágenes e inicializar la base de datos. No pulses Ctrl+C solo porque no pasa nada durante un minuto.

En producción, no dejes que los usuarios accedan directamente a puertos aleatorios. Se recomienda usar Nginx o Caddy como proxy inverso hacia el servicio Web de Dify.

Si ya tienes Nginx, puedes escribir una configuración básica así:

server {
    listen 80;
    server_name dify.example.com;

    client_max_body_size 100m;

    location / {
        proxy_pass http://127.0.0.1:80;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Si usas el contenedor Nginx integrado de Dify, ten cuidado de que los puertos no entren en conflicto con el Nginx del host en 80/443. Muchos fallos de despliegue se deben a que dos Nginx quieren escuchar en el 80.

La forma más sencilla es:

• Los servicios internos de Dify solo escuchan en puertos locales;
• El Nginx del host gestiona HTTPS de forma unificada;
• Si subes documentos, aumenta client_max_body_size.

Los certificados pueden usar Certbot:

apt install -y certbot python3-certbot-nginx
certbot --nginx -d dify.example.com

El principal atractivo de Dify es la base de conocimiento. Un flujo mínimo utilizable es:

1. Crear una base de conocimiento en el panel;
2. Subir PDF, Markdown, TXT o contenido web;
3. Configurar el método de segmentación;
4. Elegir un modelo de Embedding;
5. Esperar a que termine la indexación;
6. Crear una aplicación de chat y asociar la base de conocimiento;
7. Probar si las preguntas logran coincidir con el contenido de los documentos.

Para documentos en chino se recomienda no hacer segmentos demasiado largos. Puedes empezar con esta configuración:

Si tus documentos son descripciones de producto, tutoriales o FAQ, los segmentos pueden ser más cortos; si son informes largos, artículos académicos o contratos, los segmentos pueden ser algo más largos, pero presta atención a la continuidad del contexto.

Muchas personas sienten que RAG "no es preciso" la primera vez que lo usan. La causa normalmente no es que el modelo sea malo, sino que la segmentación de documentos es demasiado gruesa, no se incluyen los títulos, el modelo de Embedding no es adecuado para chino o el umbral de recuperación está demasiado estricto.

Dify admite varios proveedores de modelos. Opciones habituales:

Si el VPS solo tiene 4 GB u 8 GB, no recomiendo ejecutar modelos grandes en la misma máquina desde el principio. Conecta primero API externas, haz que Dify funcione de forma estable y luego considera Ollama.

Si ya tienes la pasarela de API de IA del artículo anterior, puedes apuntar el proveedor de modelos de Dify a tu propia pasarela New-API / One-API, de modo que modelos, Keys y estadísticas de uso se gestionen de forma unificada.

Con 4 GB puede funcionar, pero hay que contenerse un poco.

Acciones sugeridas:

# 看内存
free -h

# 看容器资源
docker stats

Luego controla la concurrencia del Worker en .env o en la configuración de Compose. Los campos pueden cambiar entre versiones; antes de desplegar, consulta la documentación oficial actual y .env.example. El principio es: en una máquina pequeña, no dejes que el worker procese demasiadas tareas a la vez.

Además:

• No subas miles de páginas de documentos de una vez;
• Prueba la indexación primero en pequeños lotes;
• Usa API externas para el Embedding en lo posible, no fuerces modelos grandes en la misma máquina;
• Limpia periódicamente documentos y aplicaciones que no uses;
• Haz copias de seguridad de PostgreSQL, no solo de los archivos de Docker Compose.

Lo más importante en Dify es la base de datos, los archivos subidos y la configuración.

Como mínimo hay que hacer copia de seguridad de:

• Datos de PostgreSQL;
• Volúmenes de Docker;
• .env;
• Directorio de archivos subidos;
• Configuración de plugins o extensiones personalizadas.

Una idea sencilla para la copia de seguridad de PostgreSQL:

mkdir -p /opt/backups/dify

# 容器名以 docker compose ps 实际输出为准
docker exec -t docker-db-1 pg_dump -U postgres dify \
  > /opt/backups/dify/dify-$(date +%F).sql

Luego usa rclone para sincronizar con almacenamiento de objetos u otro servidor. Las copias de seguridad guardadas solo en el mismo VPS no tienen sentido; si el disco falla, desaparecen todas juntas.

Esta también es una forma de uso muy práctica.

Dify se encarga del "pensamiento de la IA":

• Leer la base de conocimiento;
• Generar respuestas;
• Determinar la intención del usuario;
• Procesar prompts complejos.

n8n se encarga de la "ejecución de acciones":

• Escuchar formularios, Webhooks y correo;
• Llamar a la API de Dify;
• Escribir los resultados de vuelta en Notion, Feishu, WeCom o bases de datos;
• Ejecutar tareas programadas.

Por ejemplo: un cliente envía un problema posventa, n8n recibe el Webhook, envía la pregunta a Dify, Dify consulta la base de conocimiento de producto y genera una respuesta, y n8n envía el resultado al grupo de atención al cliente. Esta combinación funciona mejor que usar n8n solo o Dify solo.

Si solo quieres probar Dify, un VPS 2C4G puede servir, pero activa Swap obligatoriamente y no subas demasiados documentos de una vez.

Si piensas usarlo a largo plazo, sobre todo para un equipo o clientes, ir directamente a 4C8G te ahorrará muchos quebraderos de cabeza. Dify no es el tipo de herramienta que funcione cómodamente en una instancia pequeña de 512 MB; se parece más a un backend completo de aplicaciones de IA.

Yo lo implementaría así:

1. Empezar las pruebas con 2C4G, usar 8 GB para el entorno a largo plazo;
2. Desplegar la versión oficial con Docker Compose;
3. Usar Nginx/Caddy para HTTPS;
4. Hacer funcionar primero los modelos por API externa;
5. Subir documentos en pequeños lotes para probar RAG;
6. Ajustar segmentación, Embedding y Top K;
7. Hacer copia de seguridad diaria de PostgreSQL y los volúmenes;
8. Si ya tienes n8n, usar n8n para llamar a la API de Dify y automatizar.

El verdadero valor de Dify no es "otro sitio de chat con IA más", sino permitirte conectar tus propios documentos, procesos de negocio y modelos. Para los usuarios de VPS, es uno de los proyectos de IA autoalojados que más merece la pena explorar en 2026.