Tutoriales de VPS
Desplegar flujos de trabajo de IA visuales con Flowise en un VPS (2026): guía de despliegue con Docker, LangChain, OpenAI/Ollama y HTTPS
Este tutorial explica cómo autoalojar Flowise en un VPS y construir una plataforma de flujos de trabajo de IA visuales y orquestación con LangChain. Cubre la elección de especificaciones del VPS, el despliegue con Docker Compose, el almacenamiento persistente, la autenticación de inicio de sesión, la integración de modelos OpenAI/Ollama, HTTPS con Caddy, copias de seguridad y actualizaciones, refuerzo de seguridad y cómo elegir entre Flowise, Dify y n8n.

He visto a mucha gente que empieza queriendo hacer flujos de trabajo de IA y acaba con cada vez más herramientas instaladas.
Para preguntas y respuestas simples se usa Open WebUI, para preguntas y respuestas sobre documentos se usa AnythingLLM, para aplicaciones complejas se usa Dify, para automatización se usa n8n. Cada herramienta resuelve una parte del problema, pero si lo que realmente quieres hacer es:
Encadenar LLM, prompts, bases de datos vectoriales, recuperación, llamadas a herramientas y nodos de API en una única cadena visual.
Entonces Flowise merece una mirada aparte.
Se parece más a un editor visual de LangChain. No empiezas escribiendo un montón de código Python/TypeScript, sino que arrastras nodos en el navegador: Chat Model, Prompt Template, Retriever, Vector Store, Tool, Chain, y luego los conectas y pruebas.
Este artículo lo aborda desde el autoalojamiento en VPS: qué especificaciones pueden ejecutarlo, cómo desplegar con Docker, cómo añadir HTTPS y autenticación de inicio de sesión, cómo hacer copias de seguridad de los datos, cuándo elegir Flowise y cuándo no forzarlo.
Flowise no es "otra envoltura web de ChatGPT". Sirve para orquestar cadenas de IA.
| Necesidad | ¿Encaja Flowise? | Herramienta más adecuada |
|---|---|---|
| Crear flujos de trabajo LLM con arrastrar y soltar | Sí | Flowise |
| Aprender flujos de LangChain / RAG | Sí | Flowise |
| Crear rápidamente un prototipo de API de IA | Sí | Flowise |
| Crear un backend completo de aplicación de IA | Regular | Dify |
| Automatización multiplataforma | Regular | n8n |
| Solo chatear | No mucho | Open WebUI |
| Solo preguntas y respuestas sobre una base de conocimiento documental | No necesariamente | AnythingLLM |
Así lo entiendo yo:
- Dify es más una plataforma de aplicaciones de IA
- n8n es más una plataforma de flujos de trabajo de automatización
- Flowise es más una herramienta para construir cadenas de LLM
Si quieres entender "cómo una pregunta y respuesta RAG encadena realmente documentos, base de datos vectorial, prompt y modelo", los nodos visuales de Flowise lo hacen muy intuitivo.
Flowise en sí no es pesado. Lo que realmente consume recursos son la base de datos, la base de datos vectorial, los modelos locales y las solicitudes concurrentes que conectes.
Si solo ejecutas Flowise + API de modelos en la nube:
| Uso | Especificaciones del VPS |
|---|---|
| Pruebas personales | 1 núcleo / 2GB / 20GB SSD |
| Uso personal a largo plazo | 2 núcleos / 4GB / 40GB SSD |
| Uso compartido de un equipo pequeño | 4 núcleos / 8GB / 80GB SSD |
Si además quieres ejecutar Qdrant, PostgreSQL, Redis y Ollama en la misma máquina, no compres la configuración mínima.
Mi recomendación:
- Solo conectar OpenAI / Claude / DeepSeek / OpenRouter: 2C4G es suficiente
- Flowise + Qdrant + PostgreSQL: 4C8G es más estable
- Flowise + modelos locales Ollama: 16GB de RAM es un punto de partida más realista
No ejecutes un montón de herramientas de IA en una máquina pequeña de 1C1G. Poder abrir el panel es una cosa; ejecutar flujos de trabajo de verdad es otra.
Este artículo usa un VPS con Ubuntu / Debian como ejemplo.
Primero inicia sesión por SSH:
ssh root@your_server_ip
Actualiza el sistema:
apt update && apt upgrade -y
Instala las herramientas básicas:
apt install -y ca-certificates curl gnupg ufw
Comprueba los recursos:
free -h
df -h
Flowise se ejecuta por defecto en el puerto 3000. Primero comprueba si está ocupado:
ss -tlnp | grep 3000
Si esta máquina ya tiene Perplexica, Grafana o algún proyecto frontend ocupando el 3000, tendrás que cambiar el puerto o usar un proxy inverso para distinguir por dominio.
Si la máquina aún no tiene Docker instalado, puedes seguir estos pasos.
install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | gpg --dearmor -o /etc/apt/keyrings/docker.gpg
chmod a+r /etc/apt/keyrings/docker.gpg
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo $VERSION_CODENAME) stable" > /etc/apt/sources.list.d/docker.list
apt update
apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
Confirma la instalación:
docker --version
docker compose version
Si solo quieres ponerlo en marcha para probar primero, puedes usar Docker Run.
docker run -d \
--name flowise \
--restart unless-stopped \
-p 127.0.0.1:3000:3000 \
-v /opt/flowise:/root/.flowise \
-e PORT=3000 \
-e FLOWISE_USERNAME=admin \
-e FLOWISE_PASSWORD='replace-with-a-strong-password' \
flowiseai/flowise:latest
Dos cosas a tener en cuenta:
- Vinculo el puerto a
127.0.0.1para no exponerlo directamente a internet /opt/flowisese monta en/root/.flowisepara evitar la pérdida de datos al recrear el contenedor
Ver el contenedor:
docker ps --filter "name=flowise"
Ver los registros:
docker logs flowise --tail=100
Probar en local:
curl -I http://127.0.0.1:3000
Si es accesible en local, después usa Caddy para HTTPS.
Para uso a largo plazo recomiendo más Compose. El directorio es claro y las actualizaciones y copias de seguridad son más sencillas.
Crear el directorio:
mkdir -p /opt/flowise
cd /opt/flowise
Crear .env:
cat > .env << 'EOF'
PORT=3000
FLOWISE_USERNAME=admin
FLOWISE_PASSWORD=replace-with-a-strong-password
DATABASE_PATH=/root/.flowise
SECRETKEY_PATH=/root/.flowise
LOG_PATH=/root/.flowise/logs
BLOB_STORAGE_PATH=/root/.flowise/storage
DISABLE_FLOWISE_TELEMETRY=true
EOF
Asegúrate de cambiar la contraseña aquí; no uses el valor de ejemplo.
Crear docker-compose.yml:
services:
flowise:
image: flowiseai/flowise:latest
container_name: flowise
restart: unless-stopped
ports:
- "127.0.0.1:3000:3000"
environment:
- PORT=${PORT}
- FLOWISE_USERNAME=${FLOWISE_USERNAME}
- FLOWISE_PASSWORD=${FLOWISE_PASSWORD}
- DATABASE_PATH=${DATABASE_PATH}
- SECRETKEY_PATH=${SECRETKEY_PATH}
- LOG_PATH=${LOG_PATH}
- BLOB_STORAGE_PATH=${BLOB_STORAGE_PATH}
- DISABLE_FLOWISE_TELEMETRY=${DISABLE_FLOWISE_TELEMETRY}
volumes:
- /opt/flowise/data:/root/.flowise
entrypoint: /bin/sh -c "sleep 3; flowise start"
Iniciar:
docker compose up -d
Comprobar:
docker compose ps
docker logs flowise --tail=100
Esta configuración ya es suficiente para pruebas personales y de equipos pequeños.
Supongamos que tu dominio es:
flowise.example.com
Añade un registro A en el DNS:
flowise.example.com -> your_server_ip
Instala Caddy:
apt install -y debian-keyring debian-archive-keyring apt-transport-https curl
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' > /etc/apt/sources.list.d/caddy-stable.list
apt update
apt install -y caddy
Edita la configuración:
nano /etc/caddy/Caddyfile
Escribe:
flowise.example.com {
reverse_proxy 127.0.0.1:3000
}
Comprueba y recarga:
caddy validate --config /etc/caddy/Caddyfile
systemctl reload caddy
Ahora visita:
https://flowise.example.com
Verás la página de inicio de sesión de Flowise.
Si usas Caddy como proxy inverso, abre solo SSH, 80 y 443.
ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable
ufw status
No abras el 3000:
ufw deny 3000/tcp
La configuración de Compose anterior ya vincula el 3000 a 127.0.0.1; este paso añade otra capa de protección.
Si el panel de Flowise queda expuesto sin protección a internet, el riesgo es alto.
Porque puede contener:
- Claves API de OpenAI / DeepSeek
- Información de conexión de la base de datos vectorial
- Información de conexión de la base de datos
- Interfaces de llamadas a herramientas internas
- Los endpoints de API de los flujos de trabajo que hayas creado
Como mínimo, configura:
FLOWISE_USERNAME=admin
FLOWISE_PASSWORD=replace-with-a-strong-password
Si lo usas dentro de una empresa, también puedes añadir Cloudflare Access, Tailscale o una VPN para permitir el acceso al panel solo a usuarios concretos.
Una vez desplegado, no empieces con un Agent complejo.
Empieza con la cadena mínima:
- Añade un nodo Chat Model
- Elige OpenAI / OpenRouter / DeepSeek / Ollama
- Añade un Prompt Template
- Conéctalo a un LLM Chain
- Abre Chat para probar
Una pregunta de prueba mínima podría ser:
用三句话解释 VPS、Docker 和反向代理的关系。
Si esto no funciona, no toques todavía RAG, Tool ni Agent.
Los problemas habituales suelen ser:
- Clave API incorrecta
- Nombre del modelo incorrecto
- El VPS no puede acceder a la API del modelo
- Nodos mal conectados
- No volver a probar después de guardar
La ventaja de Flowise es que tiene bastantes nodos de modelos, así que puedes elegir según tu situación.
Si usas OpenAI, normalmente necesitas preparar:
OPENAI_API_KEY=sk-xxxx
Si usas OpenRouter, puedes elegir la forma compatible con OpenAI; lo importante es la Base URL y el nombre del modelo.
Si usas DeepSeek, también puedes conectarlo de forma compatible con OpenAI.
Aquí no pongas las claves API en documentos públicos, ni hagas commit de .env en un repositorio Git.
Recomiendo rellenarlas en la gestión de Credential de Flowise, en lugar de codificarlas en cada nodo. Así es más cómodo cuando cambies la clave más adelante.
Si quieres que los modelos se ejecuten en tu propio VPS, puedes conectar Ollama.
Instalar Ollama:
curl -fsSL https://ollama.com/install.sh | sh
Descargar un modelo:
ollama pull qwen2.5:7b
Probar:
curl http://127.0.0.1:11434/api/tags
Si Flowise está en Docker y necesita acceder al Ollama del host, no puedes escribir directamente localhost.
Añade en Compose:
extra_hosts:
- "host.docker.internal:host-gateway"
Luego, en el nodo Ollama de Flowise, rellena:
http://host.docker.internal:11434
Si rellenas http://localhost:11434, el contenedor de Flowise buscará el 11434 dentro de su propio contenedor, y normalmente fallará la conexión.
Por defecto Flowise puede guardar los datos como archivos locales, lo cual es suficiente para pruebas personales.
Pero si planeas un uso multiusuario a largo plazo, o quieres copias de seguridad más ordenadas, puedes considerar PostgreSQL.
Una regla sencilla:
| Escenario | Elección de base de datos |
|---|---|
| Pruebas personales, pocos Flows | Archivos locales por defecto |
| Uso a largo plazo de un equipo pequeño | PostgreSQL es más estable |
| Varias instancias, alta concurrencia | PostgreSQL + Redis + una arquitectura más completa |
No lleves la arquitectura al máximo desde el principio. Flowise ya tiene muchos nodos y configuraciones; estabilizar el flujo principal es más importante que acumular servicios de base de datos.
Como mínimo, haz copia de seguridad de este directorio:
/opt/flowise/data
Incluye tus Flows, Credentials, registros, archivos de almacenamiento y otros datos críticos.
Empaqueta en local:
mkdir -p /opt/backups
tar -czf /opt/backups/flowise-data-$(date +%F).tar.gz /opt/flowise
Sincroniza con el almacenamiento de objetos:
rclone copy /opt/backups/flowise-data-$(date +%F).tar.gz r2:backup-bucket/flowise/
Si usas PostgreSQL, haz también una copia de seguridad adicional de la base de datos:
pg_dump "$DATABASE_URL" | gzip > /opt/backups/flowise-db-$(date +%F).sql.gz
No hagas copia de seguridad solo del archivo Compose. Lo que realmente vale son los Flows y Credentials que has creado.
Actualizar un despliegue con Compose es sencillo:
cd /opt/flowise
docker compose pull
docker compose up -d
Haz copia de seguridad antes de actualizar:
tar -czf /opt/backups/flowise-before-upgrade-$(date +%F).tar.gz /opt/flowise
Comprueba después de actualizar:
docker compose ps
docker logs flowise --tail=100
curl -I http://127.0.0.1:3000
Luego ejecuta realmente un Flow en la web para confirmar que los nodos, las Credentials y los endpoints de API funcionan correctamente.
Primero mira el contenedor:
docker ps --filter "name=flowise"
docker logs flowise --tail=100
Luego mira el puerto local:
curl -I http://127.0.0.1:3000
Si no funciona en local, arregla el contenedor de Flowise. Si funciona en local pero no por el dominio, revisa Caddy:
caddy validate --config /etc/caddy/Caddyfile
journalctl -u caddy -n 100 --no-pager
Confirma el usuario y la contraseña en .env:
cd /opt/flowise
grep FLOWISE_ .env
Reinicia después de cambiarlos:
docker compose up -d
Si el navegador tiene el estado antiguo en caché, prueba una vez en una ventana de incógnito.
Primero confirma la clave API y el nombre del modelo.
Si es OpenAI / OpenRouter:
curl -I https://api.openai.com
Si es Ollama:
curl http://127.0.0.1:11434/api/tags
Para acceder al Ollama del host desde dentro del contenedor, usa:
http://host.docker.internal:11434
Lo más probable es que no se haya montado el directorio persistente.
Comprueba si el Compose tiene:
volumes:
- /opt/flowise/data:/root/.flowise
Comprueba el directorio del host:
ls -lah /opt/flowise/data
Si antes ejecutaste el contenedor sin montarlo, los datos pueden haberse perdido ya al eliminar el contenedor.
Primero mira los recursos del VPS:
htop
free -h
docker stats
Luego mira qué paso es el lento:
- La API del modelo es lenta
- La recuperación de la base de datos vectorial es lenta
- Los fragmentos de documentos son demasiado grandes
- El modelo local de Ollama es demasiado grande
- Las llamadas a herramientas HTTP externas son lentas
Que Flowise vaya lento no significa necesariamente que Flowise en sí sea lento; muchas veces es un nodo concreto el que va lento.
Estas tres herramientas se comparan a menudo.
| Herramienta | Más adecuada para |
|---|---|
| Flowise | Cadenas LLM visuales, LangChain, prototipos RAG |
| Dify | Plataforma de aplicaciones de IA, publicación externa, base de conocimiento y flujos de trabajo |
| n8n | Tareas de automatización, Webhooks, integración con sistemas de terceros |
Mi recomendación:
- Quieres aprender y depurar cadenas LLM: Flowise
- Quieres crear una aplicación de IA completa para que la usen otros: Dify
- Quieres integrar la IA en procesos de negocio: n8n
Por ejemplo, si quieres hacer "el usuario envía un formulario -> consultar el CRM -> llamar al modelo para resumir -> enviar a Slack", n8n es más adecuado.
Si quieres hacer "recuperación de documentos -> Prompt -> respuesta del modelo -> observar la salida de cada nodo", Flowise es más intuitivo.
Si quieres hacer "un producto de IA con inicio de sesión, base de conocimiento, API y publicación de aplicaciones", Dify es más completo.
Si yo mismo ejecutara Flowise en un VPS, lo configuraría así:
- VPS: 2 núcleos y 4GB como punto de partida
- Despliegue: Docker Compose
- Puerto: vincular solo a 127.0.0.1:3000
- HTTPS: proxy inverso Caddy
- Inicio de sesión: configurar obligatoriamente FLOWISE_USERNAME / FLOWISE_PASSWORD
- Modelos: conectar primero OpenRouter / DeepSeek / OpenAI
- Modelos locales: conectar Ollama cuando el flujo sea estable
- Copias de seguridad: hacer copia de
/opt/flowisea diario - Uso de equipo a largo plazo: entonces considerar PostgreSQL
El valor de Flowise no está en "haber instalado una herramienta de IA", sino en que divide la cadena LLM en nodos que puedes ver y ajustar. Para quienes aprenden RAG, crean prototipos de IA y solucionan problemas de prompts y llamadas a herramientas, es más rápido que escribir código directamente y más claro que una interfaz de solo chat.
Pero no es un backend universal. Permisos, productización, gestión de usuarios y publicación de aplicaciones complejas pueden encajar mejor en Dify. Antes de elegir una herramienta, piensa con claridad: ¿quieres "construir cadenas" o "crear un producto"?