Cómo alojar Flowise en un VPS

Flowise manipula datos sensibles: claves API de OpenAI/Anthropic, documentos internos vectorizados, historiales de conversación y la lógica de negocio de sus agentes. En la versión cloud compartida, esos elementos transitan por una infraestructura que usted no controla. En un VPS dedicado, el lienzo de Flowise, la base de datos y los embeddings permanecen en su servidor. Usted mantiene el control de las versiones (los flujos evolucionan rápido entre releases), de los conectores activados y de la facturación de los modelos, ya que conecta sus propias claves. Un VPS también le permite exponer los flujos como API REST para integrarlos en sus propias aplicaciones, sin cuota impuesta por un proveedor.

Otra razón práctica: los planes Flowise Cloud limitan el número de flujos activos, las ejecuciones mensuales y el acceso a los nodos avanzados. En su VPS ninguna de estas limitaciones aplica — usted define los recursos asignados.

Flowise en sí mismo es ligero, pero el uso real depende de los embeddings y de las bases vectoriales. Cuente con un mínimo de 2 vCPU y 2 GB de RAM para pruebas, y con 4 vCPU / 4 a 8 GB de RAM si indexa documentos voluminosos o ejecuta varios flujos concurrentes. Prevea 20 GB de disco para los contenedores, los almacenes vectoriales y posibles modelos locales.

En cuanto al software: Docker y Docker Compose instalados, un dominio o subdominio (p. ej. flowise.su-dominio.com) apuntando a la IP del VPS, y el puerto 443 abierto. Si planea usar un LLM local con Ollama, aumente la RAM a 8 GB como mínimo (16 GB para modelos de 7B+ en cuantización de 4 bits). Las claves API de los proveedores de LLM que piense usar deben prepararse de antemano.

Para flujos RAG eficientes sin costo de API externa, conecte Flowise a un contenedor Ollama que se ejecute en el mismo VPS a través de la red Docker interna (http://ollama:11434). Así combina embeddings y generación en local: ningún dato sale del servidor, y la latencia baja porque todo transita por la red privada del host.

En su docker-compose.yml, añada el servicio Ollama en la misma red Docker que Flowise:

services:
  ollama:
    image: ollama/ollama
    volumes:
      - ollama_data:/root/.ollama
    networks:
      - flowise_net

  flowise:
    image: flowiseai/flowise
    networks:
      - flowise_net
    ...

En Flowise, al añadir un nodo Ollama (Chat Model o Embeddings), introduzca http://ollama:11434 como base URL. Descargue un modelo desde el contenedor: docker exec -it <id_ollama> ollama pull llama3.2. Para embeddings, nomic-embed-text es un buen punto de partida con 4 GB de RAM.

Flowise expone unas veinte variables de configuración. Las más útiles en producción:

FLOWISE_USERNAME y FLOWISE_PASSWORD — autenticación de la interfaz de administración. Obligatorias en cuanto se abre el puerto público.

FLOWISE_SECRETKEY_OVERWRITE — clave de cifrado de las credenciales almacenadas en la base de datos. Si cambia este valor tras el primer arranque, las credenciales existentes se vuelven ilegibles.

DATABASE_TYPE — por defecto sqlite. Para mayor carga o un despliegue redundante, cambie a postgres e introduzca DATABASE_HOST, DATABASE_PORT, DATABASE_USER, DATABASE_PASSWORD, DATABASE_NAME.

CORS_ORIGINS — lista de orígenes autorizados a llamar a la API de predicción desde un navegador. Ejemplo: https://su-app.com. Sin esta variable las llamadas CORS desde otro origen quedarán bloqueadas.

BLOB_STORAGE_PATH — ruta de almacenamiento de los archivos subidos (documentos RAG). Por defecto en ~/.flowise/storage; monte un volumen dedicado si indexa grandes conjuntos de datos.

LOG_LEVEL — valores: error, warn, info, verbose, debug. En producción, warn es suficiente para mantener los registros manejables.

Flowise publica actualizaciones periódicas que añaden nodos y corrigen comportamientos de flujo. La actualización es no destructiva si sus datos están en un volumen con nombre.

docker compose pull
docker compose up -d

Flowise migra automáticamente la base de datos SQLite al arrancar. Antes de cada actualización, exporte sus flujos importantes mediante el botón Export del lienzo (archivo JSON) — es la red de seguridad más sencilla.

Si usa PostgreSQL, compruebe las notas de la versión antes de descargar la imagen: algunas versiones introducen migraciones de esquema irreversibles. Conserve una copia de seguridad de la base de datos (pg_dump) antes de actualizar.

El lienzo no se carga o los nodos desaparecen. Verifique que su reverse proxy propague correctamente los WebSockets. Con nginx deben estar presentes las cabeceras Upgrade y Connection. Con Caddy se configuran automáticamente.

Error: FLOWISE_SECRETKEY_OVERWRITE is required. Esta variable no era obligatoria en versiones anteriores pero lo es ahora. Añádala al compose y reinicie — las credenciales ya introducidas siguen siendo válidas siempre que el valor coincida con el usado al almacenarlas.

El almacén vectorial pierde sus documentos tras el reinicio. Compruebe que la ruta del volumen Docker coincide con BLOB_STORAGE_PATH y DATABASE_PATH. Un bind-mount mal configurado guarda los datos en una carpeta efímera del contenedor.

Las llamadas a Ollama fallan con ECONNREFUSED. El servicio Ollama debe estar en la misma red Docker que Flowise. Si Ollama se ejecuta fuera de Compose (servicio systemd, por ejemplo), use la IP de la pasarela Docker (172.17.0.1:11434) en lugar de localhost.

Las credenciales de OpenAI/Anthropic se rechazan tras la migración. Si FLOWISE_SECRETKEY_OVERWRITE cambió entre dos despliegues, los secretos cifrados con la clave anterior no pueden descifrarse. Elimine y vuelva a introducir las credenciales en la interfaz.