Как установить и настроить Flowise на VPS

MAATRIX

Flowise собирает чат-бота или RAG-ассистента мышью на холсте и сразу отдаёт под него HTTP-API — за это его и любят. Но установка Flowise на VPS в 2026 году начинается не с docker run, а с трезвого разговора: проект ушёл в архив, патчей безопасности больше не будет, а прошлые дыры в нём были такого калибра, что открытый наружу порт означал чужой шелл. Ниже — рабочая установка с фиксированной версией, секретами, HTTPS и стримингом, и честный список того, на что вы подписываетесь.

Flowise в августе 2026: что вы ставите и на каких условиях

Flowise — визуальный конструктор LLM-приложений на Node.js. Монорепозиторий из трёх пакетов: packages/server (Express + TypeORM), packages/ui (React-холст) и packages/components — те самые узлы: модели, ретриверы, инструменты, парсеры. Вы соединяете узлы, сохраняете поток, и Flowise публикует его как эндпоинт POST /api/v1/prediction/{chatflowId} плюс embed-виджет для сайта. Слушает по умолчанию порт 3000.

Теперь неприятное, и это ключевой факт для всех, кто гуглит «flowise установка» сегодня. 29 июля 2026 года команда объявила о сворачивании проекта и заморозила код. 13 августа репозиторий FlowiseAI/Flowise переведён в public archive: код виден, но issues и pull request'ы заблокированы. 31 августа закончилась официальная поддержка, пакеты в npm и образы на Docker Hub помечены deprecated. Саму FlowiseAI купила Workday ещё в августе 2025 — это финал той истории. Последний релиз: flowise@3.1.3 от 25 июня 2026.

Хорошая новость: код остаётся на GitHub под Apache 2.0, его можно форкать, патчить и держать в проде сколько угодно. Плохая — три следствия, которые надо принять до заказа сервера.

• Обновлений безопасности не будет. Найдут дыру — чинить вам или сообществу форков.
• История уязвимостей у Flowise серьёзная. CVE-2024-31621: обход авторизации в версиях до 1.6.6, проверка пути была регистрозависимой, и запрос к /API/V1/ заглавными буквами проскакивал мимо аутентификации прямо в админские эндпоинты. CVE-2025-26319 с оценкой 9.8 по CVSS: загрузка произвольных файлов без авторизации через /api/v1/attachments — эндпоинт был в белом списке, а chatflowId и chatId не проверялись. Через такое на сервер кладут что угодно, включая чужой ключ в authorized_keys.
• Версию придётся зафиксировать. Тег latest в архивном проекте — лотерея, а не удобство.

Вывод один: Flowise на публичном IP без прокси и фаервола не выставляют — ни на час, ни «пока тестирую». Если нужен инструмент, который будут чинить, посмотрите Dify против Flowise или n8n — оба живы. Если у вас уже есть готовые потоки или вы сознательно берёте Apache-2.0-код себе в форк, читайте дальше.

Что решить до установки: Node, база и где лежат ключи

Версия Node. В package.json поле engines у Flowise — >=18.15.0 <19.0.0 || ^20. Официально поддержаны только Node 18.15+ из ветки 18 и вся ветка 20. Node 22 в диапазон не входит, установка на нём падает ещё до скачивания; по этому поводу висел незакрытый issue #4450. Ставим Node 20 LTS и не выдумываем.

Где живут данные. Всё состояние Flowise лежит в одном каталоге — по умолчанию ~/.flowise, в контейнере /root/.flowise.

Ключ шифрования — самое важное решение. Все credentials (ключи OpenAI, токены, пароли к базам), введённые в интерфейсе, лежат в БД зашифрованными. Если FLOWISE_SECRETKEY_OVERWRITE не задан, Flowise генерирует ключ сам и кладёт файлом в SECRETKEY_PATH. Потеряли том — потеряли все credentials безвозвратно: строки в базе останутся, расшифровать их нечем, и каждый поток начнёт падать на попытке достать ключ модели. Задайте FLOWISE_SECRETKEY_OVERWRITE до первого запуска и положите его в менеджер паролей.

SQLite или Postgres. По умолчанию SQLite, и для одного-двух человек с десятком потоков этого хватает. Postgres (DATABASE_TYPE=postgres) нужен в трёх случаях: команда с несколькими воркспейсами, режим очереди с отдельными воркерами, консистентный бэкап без остановки сервиса. Переключиться потом можно, но потоки придётся экспортировать и импортировать руками.

Память. Flowise — оркестратор: он не считает модель, а собирает промпт, дёргает чужой API и ждёт ответа. Процесс Node с загруженным набором узлов — это несколько сотен мегабайт RSS, документация проекта называет минимумом 2 ГБ на инстанс. Отдельная история — сборка из исходников: там V8 упирается в лимит кучи, и на машине с 2 ГБ она не проходит. Расчёт памяти под соседние сервисы — в статье сколько RAM нужно для Ollama.

Установка в Docker: полный compose и первый вход

Работаем на Ubuntu 24.04. Фаервол — наружу только SSH и HTTP(S), порт 3000 не открываем вообще:

ufw allow 22/tcp && ufw allow 80,443/tcp && ufw --force enable
curl -fsSL https://get.docker.com | sh
docker compose version

В Flowise 3.x четыре независимых JWT-секрета плюс ключ шифрования credentials, и все пять надо задать явно:

mkdir -p /opt/flowise/data && cd /opt/flowise
umask 077
{
  echo "FLOWISE_SECRETKEY_OVERWRITE=$(openssl rand -hex 32)"
  for v in JWT_AUTH_TOKEN_SECRET JWT_REFRESH_TOKEN_SECRET \
           EXPRESS_SESSION_SECRET TOKEN_HASH_SECRET; do
    echo "$v=$(openssl rand -hex 32)"
  done
} > /opt/flowise/.env

Зачем буквально: без заданных секретов контейнер в новых версиях падает при старте с TypeError: JwtStrategy requires a secret or key, а в сборках, где вместо падения подставляются значения по умолчанию, вы получаете предсказуемый секрет подписи токенов — то есть возможность подделать сессию администратора. Оба варианта плохие.

Теперь docker-compose.yml. Обратите внимание на закреплённый тег версии и порт, проброшенный только на loopback:

services:
  flowise:
    image: flowiseai/flowise:3.1.3
    container_name: flowise
    restart: unless-stopped
    ports:
      - "127.0.0.1:3000:3000"
    env_file: .env
    environment:
      - PORT=3000
      - DATABASE_PATH=/root/.flowise
      - SECRETKEY_PATH=/root/.flowise
      - APIKEY_PATH=/root/.flowise
      - LOG_PATH=/root/.flowise/logs
      - BLOB_STORAGE_PATH=/root/.flowise/storage
      - LOG_LEVEL=info
      - NUMBER_OF_PROXIES=1
      - CORS_ORIGINS=https://flowise.example.com
      - IFRAME_ORIGINS=https://example.com
      - FLOWISE_FILE_SIZE_LIMIT=50mb
      - DISABLE_FLOWISE_TELEMETRY=true
    volumes:
      - ./data:/root/.flowise

docker compose up -d
docker compose logs -f flowise
curl -s http://127.0.0.1:3000/api/v1/ping   # pong

Эндпоинт /api/v1/ping авторизации не требует и отвечает pong — им же удобно проверять живость из мониторинга. Молчит — смотрите логи, до интерфейса дело не дошло.

Первый вход. Начиная с 3.0.1 у Flowise нормальная система аккаунтов: Passport.js, пароль в базе через bcrypt, JWT в httpOnly-куках — access-токен на 60 минут, refresh на 90 дней. Старая пара FLOWISE_USERNAME / FLOWISE_PASSWORD объявлена устаревшей: входа она больше не даёт, а служит подтверждением прав при миграции со старой установки. При первом открытии вы попадаете на экран Setup Account, где создаётся администратор, организация и воркспейс. Кто увидит этот экран раньше вас, тот и станет владельцем инстанса, — сначала фаервол и прокси, только потом браузер.

Установка через npm и systemd, когда Docker не подходит

Иногда Docker нежелателен — например, машина занята панелью, которая сама рулит контейнерами. Тогда ставим глобально из npm.

curl -fsSL https://deb.nodesource.com/setup_20.x | bash -
apt install -y nodejs build-essential python3
node -v            # v20.x
npm install -g flowise@3.1.3

build-essential и python3 нужны не для красоты: часть зависимостей содержит нативные модули, которые собираются node-gyp прямо при установке. Без компилятора получите простыню, в которой настоящая причина — gyp ERR! stack Error: not found: make.

Если поставить Node посвежее, установка отвалится сразу:

npm ERR! code EBADENGINE
npm ERR! engine Unsupported engine
npm ERR! notsup Not compatible with your version of node/npm: flowise@3.1.3
npm ERR! notsup Required: {"node":">=18.15.0 <19.0.0 || ^20"}
npm ERR! notsup Actual:   {"npm":"10.8.2","node":"v22.14.0"}

В свежих npm та же ошибка печатается с префиксом npm error вместо npm ERR!. Лечение — поставить Node 20, а не пробивать проверку через --force или yarn --ignore-engines: движок проверяется не зря, часть зависимостей на 22-й ветке действительно ломается.

Второй классический сбой — нехватка памяти при установке на маленьком VPS: FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory. Лечится двумя строчками — swap на время установки и явный лимит кучи:

fallocate -l 4G /swapfile && chmod 600 /swapfile && mkswap /swapfile && swapon /swapfile
NODE_OPTIONS=--max-old-space-size=4096 npm install -g flowise@3.1.3

Дальше юнит systemd: отдельный пользователь, отдельный env-файл, автозапуск.

[Unit]
Description=Flowise
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=flowise
Group=flowise
WorkingDirectory=/opt/flowise
EnvironmentFile=/etc/flowise/flowise.env
Environment=NODE_OPTIONS=--max-old-space-size=2048
ExecStart=/usr/bin/flowise start
Restart=on-failure
RestartSec=10

[Install]
WantedBy=multi-user.target

useradd -r -s /usr/sbin/nologin -d /opt/flowise flowise
chown root:flowise /etc/flowise/flowise.env && chmod 640 /etc/flowise/flowise.env
systemctl enable --now flowise && journalctl -u flowise -f

Грабля с правами тут стандартная: если env-файл лежит 600 root:root, а сервис работает от flowise, юнит не стартует и пишет в журнал Failed to load environment files: Permission denied. И не забудьте PORT=3000 вместе с FLOWISE_HOST=127.0.0.1 в env-файле, иначе процесс сядет на все интерфейсы.

Домен, HTTPS и Nginx: где именно ломается стриминг

Направьте A-запись flowise.example.com на IP сервера и получите сертификат: apt install -y nginx certbot python3-certbot-nginx, затем certbot --nginx -d flowise.example.com.

Дальше правим location — и здесь большинство инструкций врут, давая конфиг обычного HTTP-приложения. Flowise стримит ответы модели через socket.io, и на дефолтном прокси-конфиге ответы появляются не по токенам, а разом через двадцать секунд, либо вываливаются с transport close.

location / {
    proxy_pass http://127.0.0.1:3000;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    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;

    proxy_buffering off;
    proxy_cache off;
    proxy_read_timeout 600s;
    proxy_send_timeout 600s;
}

Что чинит каждая строка:

• proxy_http_version 1.1 с заголовками Upgrade/Connection — без них WebSocket-апгрейд не проходит, socket.io откатывается на long-polling, и стриминг превращается в один большой ответ в конце.
• proxy_buffering off — Nginx по умолчанию копит ответ в буфер. Для SSE это означает «ничего не происходит, потом всё сразу».
• proxy_read_timeout 600s — дефолт Nginx 60 секунд, а socket.io держит соединение с pingInterval + pingTimeout порядка 45 секунд. Запас крошечный, и длинный запрос к модели рвётся посреди ответа.
• client_max_body_size 60m в блоке server — обязательно вместе с FLOWISE_FILE_SIZE_LIMIT. У Flowise дефолт 50mb, у Nginx — 1 МБ. Загрузка PDF в базу знаний упрётся сначала в прокси и вернёт 413 Request Entity Too Large, причём в логах Flowise не будет ничего: запрос до него не дошёл.

Отдельно — NUMBER_OF_PROXIES=1. Flowise использует express-rate-limit, а тот отказывается доверять заголовку X-Forwarded-For, если не сказать, сколько прокси стоит перед приложением. Забыли — в логах появится ValidationError: The 'X-Forwarded-For' header is set but the Express 'trust proxy' setting is false, а лимиты начнут считаться по адресу самого Nginx, то есть на всех сразу.

И два параметра, которые в дефолте стоят в * и которые надо сузить руками: CORS_ORIGINS (кто может дёргать API из браузера) и IFRAME_ORIGINS (где разрешено встраивать виджет). Оставленная звёздочка означает, что ваш поток с вашими ключами моделей можно вставить на любой чужой сайт.

Ключи моделей, API потока и рост нагрузки

Модели подключаются через раздел Credentials: вводите ключ OpenAI, Anthropic, Google или адрес локальной Ollama, и он становится доступен всем узлам. Здесь всплывает то, что с самим Flowise не связано: провайдеры смотрят на исходящий IP сервера. С российского адреса OpenAI отвечает 403 unsupported_country_region_territory, Google для Gemini — User location is not supported for the API use. Ключ рабочий, а поток не работает, и перегенерация ключа не помогает — помогает сервер в подходящей локации.

Опубликованный поток вызывается снаружи так:

curl -X POST https://flowise.example.com/api/v1/prediction/<chatflowId> \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $FLOWISE_API_KEY" \
  -d '{"question":"Какие у вас условия возврата?","streaming":false}'

API-ключ создаётся в интерфейсе и хранится в api.json (или в базе, если выставить APIKEY_STORAGE_TYPE=db). Без ключа эндпоинт открыт всем, кто узнал chatflowId, — а он светится в коде embed-виджета на вашем сайте. Считайте выдачу ключа обязательным шагом, а не опцией.

Когда потоков много и они ходят друг в друга, одного процесса перестаёт хватать: длинная цепочка блокирует event loop, соседние запросы ждут. На этот случай есть режим очереди — сервер складывает задания в Redis, а выполняют их отдельные воркеры.

MODE=queue
QUEUE_NAME=flowise-queue
REDIS_URL=redis://redis:6379
WORKER_CONCURRENCY=5
REMOVE_ON_AGE=24
REMOVE_ON_COUNT=1000

Честное предупреждение: очередь тянет за собой Redis, Postgres и минимум два процесса Flowise вместо одного. Это плюс два-три гигабайта памяти и заметно более сложный бэкап. На одного-двух пользователей она не нужна.

Бэкап. Копировать надо три вещи: базу, ключ шифрования и каталог storage. При SQLite — только с остановленным контейнером, иначе снимете файл посреди записи:

cd /opt/flowise && docker compose stop flowise
tar czf /root/flowise-$(date +%F).tar.gz data .env
docker compose start flowise

Проверьте восстановление на чистой машине хотя бы раз. Типичная ошибка — забэкапить database.sqlite без .env с FLOWISE_SECRETKEY_OVERWRITE: потоки развернутся, а все credentials окажутся нечитаемым мусором.

Какой сервер под Flowise брать в MAATRIX

Flowise почти всё время ждёт — ответа модели, векторной базы, внешнего API. Процессор нужен на разбор документов и эмбеддинги, память — на Node и загруженные узлы. Тяжёлого счёта нет, если только вы не поставили модель на ту же машину.

• Минимум: 1 vCPU, 2 ГБ RAM, 20 ГБ NVMe. Docker, SQLite, один-два пользователя, десяток потоков на облачных моделях. Ограничения называю прямо: собрать Flowise из исходников на такой машине не выйдет — упрётесь в heap; режим очереди не поднять; параллельная загрузка нескольких больших PDF в базу знаний закончится процессом, убитым по OOM.
• Комфорт: 2 vCPU, 4 ГБ RAM, 40–60 ГБ NVMe. Помещаются Flowise, Nginx с сертификатом, локальный Postgres и запас на индексацию документов. Разумная точка старта для небольшой команды.
• Команда и очередь: 4 vCPU, 8 ГБ RAM. Postgres, Redis, основной сервер плюс воркер, спокойные обновления и место под бэкапы.

Если хотите держать модель на своём железе рядом, планируйте отдельную машину. На нашем стенде — AMD EPYC 9554, 16 vCPU, Ollama 0.33.1 — модель qwen2.5:7b в Q4_K_M занимает 5,1 ГБ памяти и даёт около 7,6 токена в секунду на CPU; llama3.1:8b — 5,6 ГБ и 12,8 ток/с; qwen2.5:3b — 2,2 ГБ и 34,1 ток/с. Показательно, что генерация выходит на полку уже на четырёх потоках (num_thread 4): упор идёт в память, а не в ядра. Отдавать Flowise и локальной модели один сервер поэтому плохая идея.

Локация — Великобритания, Лондон. Причина прикладная: Flowise почти всегда ходит в чужие API, и лондонский адрес там принимают штатно, без тех самых 403 по региону. До дата-центров ЕС пинг минимальный, а из Москвы RTT до Лондона ощутимо меньше, чем до Нью-Йорка, — при интерактивной работе на холсте это чувствуется. Если основная аудитория ваших ботов в Америке, берите Нью-Йорк, разница только в маршруте. Российская локация под Flowise с облачными моделями не годится: интерфейс будет открываться быстро, а запросы к моделям упираться в блокировку по региону.

Про установку честно: Flowise в каталоге apps.maatrix.io нет и, учитывая архивацию проекта, не появится. Сервер приезжает чистым — Ubuntu 24.04 или Debian, root-доступ, — и Flowise вы ставите по инструкции выше, минут за пятнадцать вместе с сертификатом. Зато в каталоге есть готовые сборки родственных сервисов — они разворачиваются автоматически при заказе, доступы появляются в личном кабинете: n8n, Dify, AnythingLLM, Open WebUI, Ollama, LiteLLM, Qdrant, Langfuse, Portainer. Если Flowise нужен под прототип, а долгоживущую автоматизацию хочется на поддерживаемом инструменте — это ровно те кандидаты.

Оплата — картой российского банка, по СБП, криптовалютой или токеном MAAT; зарубежная карта не нужна, хотя сервер стоит в Лондоне. И последнее по порядку, первое по важности: сразу после первого входа закройте инстанс — фаервол, HTTPS, свои JWT-секреты, а лучше и ограничение админского входа по IP. Патчей для Flowise больше никто не выпустит, и единственный оставшийся уровень защиты — тот, который вы поставите сами.

Частые вопросы