Flowise на сервере: частые ошибки и решения

MAATRIX

Flowise редко ломается «весь сразу». Почти всегда причина одна и конкретная: Node не той версии, том без encryption.key, localhost в узле Ollama, nginx, проглотивший стриминг. Ниже — ошибки Flowise, которые чаще всего доходят до поддержки: точные тексты сообщений, команды проверки и рабочие конфиги. Плюс то, о чём молчат прошлогодние мануалы: проект переведён в архив, и совет «обновись до свежей версии» перестал быть решением.

Диагностика за пять минут: лог, код выхода, версия

Половина обращений «Flowise не работает» закрывается первым же логом:

docker logs -f --tail=200 flowise

Мало сообщений — поднимите подробность: LOG_LEVEL=debug и LOG_PATH=/root/.flowise/logs, файл переживёт перезапуск. На debug в лог уезжают тела запросов с промптами — после отладки верните info. Второй вопрос: как умер процесс.

docker inspect flowise --format 'exit={{.State.ExitCode}} oom={{.State.OOMKilled}} restarts={{.RestartCount}}'

Живой ли процесс мимо прокси, покажет curl -si http://127.0.0.1:3000/api/v1/ping. Ответ pong — приложение поднялось, и проблемы на уровне nginx, фаервола или DNS. Молчание — наоборот.

Теперь про версию — самый важный абзац статьи. 29 июля 2026 года команда Flowise заморозила код: новых функций, исправлений и принятых pull request не будет. В августе репозиторий переведён в публичный архив, issues и PR закрыты, пакеты npm и образы Docker помечены устаревшими, 31 августа заканчивается поддержка core-команды. Исходники остаются на GitHub под Apache 2.0 — форкать никто не запрещает.

Следствий два. Тег latest больше никуда не едет, и привычное «обновитесь, там починили» не работает. И версию надо зафиксировать явно: docker inspect flowise --format '{{.Config.Image}}'. Увидели latest — поменяйте на конкретный тег, пока образ лежит в реестре, и сохраните копию через docker save. Обзор инструмента — в разборах Flowise для no-code AI и Dify против Flowise.

Не стартует: Node не той версии, занятый порт, права на каталог

Установка через npm на неподходящем рантайме коварна: он не останавливается, а только предупреждает:

npm warn EBADENGINE Unsupported engine {
npm warn EBADENGINE   package: 'flowise@3.0.5',
npm warn EBADENGINE   required: { node: '>=18.15.0 <19.0.0 || ^20' },
npm warn EBADENGINE   current: { node: 'v22.14.0', npm: '10.9.2' } }

Прочитайте диапазон внимательно: подходят 18.15 и выше внутри восемнадцатой ветки — и вся двадцатая. Node 19, 21, 22 и 24 не подходят. Yarn откажется ставить честно, npm поставит и сломается позже — на ошибках нативных модулей, где связь с версией рантайма уже не очевидна. Ловушка Ubuntu 24.04: пакет nodejs из штатных репозиториев даёт 18.19.1 и в диапазон попадает, а скрипт NodeSource setup_22.x — нет.

curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash -
sudo apt install -y nodejs && node -v    # ожидаем v20.x

Порт 3000 — общажный: на нём по умолчанию сидят Grafana, Dokploy и половина Node-приложений.

Error: listen EADDRINUSE: address already in use :::3000

Кто занял, покажет ss -ltnp | grep :3000. Переезд задаётся переменной PORT, но менять надо в двух местах — и переменную, и публикацию порта. Разошлись: контейнер поднимется, а снаружи тишина.

services:
  flowise:
    image: flowiseai/flowise:3.0.5
    environment:
      - PORT=3100
    ports:
      - "127.0.0.1:3100:3100"

Права на каталог данных. Официальный образ работает от root и хранит всё в /root/.flowise. Ошибка появляется, когда контейнер запустили с --user 1000:1000 или примонтировали каталог хоста, принадлежащий другому пользователю:

Error: EACCES: permission denied, mkdir '/root/.flowise'

Лечится возвратом к root либо переносом путей туда, куда ваш UID может писать. Путей четыре — DATABASE_PATH, SECRETKEY_PATH, LOG_PATH, BLOB_STORAGE_PATH, — и забыть один легко.

Сборка из исходников встречает так:

FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
 ELIFECYCLE  Command failed with exit code 134.

Разработчики рекомендуют для сборки NODE_OPTIONS="--max-old-space-size=4096" — четыре гигабайта только под кучу. На VPS с двумя гигабайтами сборка не пройдёт, и swap лишь растянет агонию: берите готовый образ, из исходников собирают те, кто ведёт свой форк.

Три секрета, которые задают до первого запуска, а не после

Самая дорогая ошибка Flowise выглядит не как ошибка: интерфейс открывается, потоки на месте, учётки в списке — а каждый узел с моделью падает на выполнении.

Ключи провайдеров, токены и пароли лежат в базе зашифрованными, а ключ шифрования — отдельным файлом /root/.flowise/encryption.key, и при первом старте генерируется случайно. Пересоздали контейнер без тома или перенесли базу без этого файла — расшифровать нечем. Восстановления нет: только заводить все учётки заново, идя за токенами в каждый сервис. Профилактика делается до первого сохранения кредов:

echo "FLOWISE_SECRETKEY_OVERWRITE=$(openssl rand -hex 32)" >> /opt/flowise/.env

Формат произвольный, но случайные 32 байта надёжнее осмысленной строки. Задали её после того, как креды сохранены старым ключом, — старые записи станут нечитаемыми. Ключ на месте? docker exec flowise ls -l /root/.flowise/.

Второй слой — аутентификация консоли. В ветке 3.x за неё отвечают JWT_AUTH_TOKEN_SECRET, JWT_REFRESH_TOKEN_SECRET, EXPRESS_SESSION_SECRET и TOKEN_HASH_SECRET. Не задали — берутся значения по умолчанию, у сессионного секрета это буквально строка flowise. Дефолт, известный всему интернету, означает, что токен можно подделать и войти в консоль, где лежат ключи от всех моделей.

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 | tee -a /opt/flowise/.env
chmod 600 /opt/flowise/.env

Отсюда два симптома, которые списывают на баги. «После перезапуска разлогинивает всех» — секреты не зафиксированы, генерируются заново, выданные токены умирают. «Логин крутится по кругу, пароль правильный» — вы заходите по http://IP:3000 без TLS, и браузер не сохраняет cookie сессии; лечится доменом и сертификатом.

Бэкап снимайте на остановленном контейнере, иначе поймаете SQLite в середине записи. И помните: docker compose down -v уносит тома вместе со стеком, включая encryption.key.

docker stop flowise
tar czf /root/flowise-$(date +%F).tgz -C /root .flowise
docker start flowise

Узлы не видят модель: ECONNREFUSED, 403 по региону и «поток завис»

Самая частая ошибка подключения к локальной модели:

Error: connect ECONNREFUSED 127.0.0.1:11434

Внутри контейнера localhost — это сам контейнер, а не хост. Вариантов три, и они не взаимозаменяемы:

• Ollama соседним сервисом в том же compose — адрес по имени сервиса, http://ollama:11434. Чище всего.
• Ollama на хосте, Linux — адрес моста docker0, обычно http://172.17.0.1:11434. Сверьте фактический: ip -4 addr show docker0.
• host.docker.internal — из коробки работает только на macOS и Windows; на Linux имя добавляется через --add-host=host.docker.internal:host-gateway.

Мало указать адрес: сама Ollama слушает только петлю. Нужен override юнита и правило фаервола на docker-подсеть, а не на весь мир:

sudo systemctl edit ollama
# [Service]
# Environment="OLLAMA_HOST=0.0.0.0:11434"
sudo systemctl restart ollama
sudo ufw allow from 172.17.0.0/16 to any port 11434 proto tcp

С облачными провайдерами иначе: ключ рабочий, а узел падает с 403 {"error":{"code":"unsupported_country_region_territory"}}. Это отказ по географии исходящего адреса, перевыпуск ключа не помогает.

Отдельно про «поток завис». На локальной модели без видеокарты это обычно не зависание, а честная скорость. Наш замер на AMD EPYC 9554 (16 vCPU — 8 физических ядер плюс HT), Ollama 0.33.1, квантование Q4_K_M:

Ответ на 400 токенов от семимиллиардной модели на CPU — от полуминуты до минуты. Узел Flowise ждёт спокойно, а nginx с дефолтным proxy_read_timeout 60s — нет. Отсюда и «зависло»: оборвалось соединение, а генерация продолжалась.

Там же: на qwen2.5:7b генерация выходит на полку уже при четырёх потоках — 7,6 токена в секунду на 4, 8 и 16 потоках, то есть упор в память, а не в процессор. А num_thread 32 на 16 vCPU даёт 0,35 токена в секунду, обвал в двадцать раз. Не выкручивайте потоки «на всякий случай» — разбор в статье Ollama не использует все ядра CPU.

И ошибка, которую не связывают с моделью: индекс построен одними эмбеддингами, а ищете вы другими — размерность вектора не совпадёт, и хранилище вернёт ошибку на запросе, а не на записи. Сменили модель эмбеддингов — перестраивайте индекс целиком.

Ошибки за реверс-прокси: 401 на API, CORS, оборванный стриминг, 413

Второй крупный класс: Flowise жив, ломается стык с nginx.

401 на вызове потока. Ответ короткий: Unauthorized Access. Проверьте вызов на петле, минуя прокси:

curl -X POST http://127.0.0.1:3000/api/v1/prediction/<chatflowId> \
  -H "Authorization: Bearer <ключ из раздела API Keys>" \
  -H "Content-Type: application/json" \
  -d '{"question":"привет"}'

Причин три. Забыли слово Bearer — заголовок без него не парсится. Взяли не тот ключ: в разделе API Keys живёт DefaultKey, а к потоку привязан другой. Третья неочевидна: nginx с auth_basic занимает тот же заголовок Authorization, и базовая авторизация на весь сервер лишает клиента возможности передать ключ. Ставьте auth_basic на location /, но не на /api/.

CORS при встраивании виджета. В консоли браузера видно:

Access to fetch at 'https://flowise.example.com/api/v1/prediction/abc'
from origin 'https://site.example.com' has been blocked by CORS policy:
No 'Access-Control-Allow-Origin' header is present on the requested resource.

Лечится переменной CORS_ORIGINS со списком доменов через запятую, а для виджета в iframe — ещё и IFRAME_ORIGINS. Значение * работает и потому висит в половине инструкций. Не делайте так: эндпоинт вместе с вашими токенами становится доступен любому сайту.

CORS_ORIGINS=https://site.example.com,https://www.site.example.com
IFRAME_ORIGINS=https://site.example.com

Стриминг приходит одним куском в конце — буферизация nginx. Рабочий блок целиком:

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

server {
    server_name flowise.example.com;
    client_max_body_size 50m;

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

Добавьте NUMBER_OF_PROXIES=1: без неё встроенный ограничитель частоты считает всех клиентов одним адресом — адресом прокси, — а в логах вместо реальных IP светится 172.18.0.1.

413 Request Entity Too Large на загрузке документа. Лимитов два, и подняв один, упрётесь во второй: client_max_body_size в nginx (выше уже 50m) и FLOWISE_FILE_SIZE_LIMIT в приложении. Ошибка сменила формат с html-страницы на JSON — значит, дошли до второго.

И правило публикации, о котором забывают: Docker публикует порты в обход ufw. Строка -p 3000:3000 открывает порт всему интернету, даже если ufw status показывает deny 3000: правила Docker живут в цепочке DOCKER-USER раньше ваших. Публикуйте на петлю — -p 127.0.0.1:3000:3000 — и выпускайте наружу только через nginx с сертификатом.

Под нагрузкой и без патчей: SQLITE_BUSY, куча V8 и дыры, которые уже не закроют

Пока в консоли один человек, SQLite справляется. Как только пишут несколько или параллельно идёт индексация:

QueryFailedError: SQLITE_BUSY: database is locked

SQLite допускает одного писателя, и таймаутом это не лечится. Переезд на Postgres задаётся переменными:

DATABASE_TYPE=postgres
DATABASE_HOST=127.0.0.1
DATABASE_PORT=5432
DATABASE_NAME=flowise
DATABASE_USER=flowise
DATABASE_PASSWORD=<пароль>
DATABASE_SSL=false

Честно: автоматической миграции данных из SQLite в Postgres нет. Flowise создаст пустые таблицы и не перенесёт ни одного чатфлоу. Вручную это выгрузка каждого потока в JSON, импорт в новый инстанс и повторный ввод учётных данных — они зашифрованы и в экспорт не попадают. На десяток потоков вечер работы, так что базу планируют заранее.

Куча V8. Node выбирает предел старого поколения по памяти машины, и на маленьком VPS он маленький. Упирается в него индексация большого набора документов: нарезка на фрагменты держится в памяти целиком. Симптом — exit=134 и Reached heap limit в логе, лечение — NODE_OPTIONS=--max-old-space-size=3072. Но только если три гигабайта физически есть: иначе падение переезжает из V8 в OOM-киллер ядра и становится молчаливым exit=137. Кто прав, покажет dmesg -T | grep -i "out of memory".

Очередь. Один процесс Node — одна очередь выполнения. Когда пользователей много, Flowise делится на приёмник и воркеров через Redis. Плата — Redis плюс два процесса приложения: конфигурация от четырёх гигабайт, на двух смысла нет.

MODE=queue
QUEUE_NAME=flowise-queue
REDIS_URL=redis://redis:6379
WORKER_CONCURRENCY=5

Теперь неприятная часть. За полтора года в Flowise закрывали серьёзные вещи: CVE-2025-26319 — загрузка произвольных файлов без авторизации, 9,8 по CVSS, эксплуатировалась в дикой природе; CVE-2025-58434 — подделка токена сброса пароля и захват чужого аккаунта; CVE-2025-59528 — выполнение кода через параметр mcpServerConfig узла CustomMCP в версиях от 2.2.7-patch.1 до 3.0.6; CVE-2025-71327 — незащищённый эндпоинт регистрации; CVE-2025-71333 — загрузка файлов через /api/v1/attachments с обходом пути в chatId и chatflowId.

Все они исправлены вовремя. Проблема в другом: следующая находка исправления не получит — код заморожен, репозиторий в архиве. Вывод прямой: Flowise больше нельзя вешать в интернет голым портом. Сервис слушает петлю, снаружи только nginx с TLS, консоль по возможности за VPN или списком адресов. Регистрацию, если она не нужна, закройте отдельно:

location = /api/v1/account/register { return 403; }

Сверьтесь с маршрутами своей версии: соседние адреса под /api/v1/account/ могут обслуживать вход, и широкий location заблокирует логин. Проверка — curl -si -X POST https://flowise.example.com/api/v1/account/register: в ответе должно быть 403, а не 200.

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

Сразу честно: Flowise нет в каталоге apps.maatrix.io, и после архивации проекта добавлять не планируем — автоустановщик тянул бы образ, который больше не обновляется. Сервер приходит чистым, Flowise вы ставите по командам из этой статьи, минут за десять. Зато в каталоге есть готовые сборки родственных сервисов — n8n, Dify, AnythingLLM, LiteLLM, Ollama: они разворачиваются автоматически при заказе на Ubuntu и Debian, доступы появляются в личном кабинете.

Честный минимум — 1 vCPU, 2 ГБ RAM, 25 ГБ NVMe. Готовый образ Docker, SQLite, облачные модели по API, один пользователь в консоли. Ограничения называем прямо: собрать Flowise из исходников тут нельзя, сборщику нужно 4 ГБ под кучу; Postgres рядом не поместится; тяжёлая индексация упрётся в предел кучи V8 раньше, чем в память сервера.

Рабочий вариант — 2 vCPU, 4 ГБ RAM, 50–60 ГБ NVMe. Помещаются Flowise, локальный Postgres, nginx с сертификатом и архивы каталога данных. Здесь имеет смысл сразу поднять NODE_OPTIONS=--max-old-space-size=3072 и не бояться базы знаний на несколько тысяч фрагментов.

Комфортный вариант — 4 vCPU, 8 ГБ RAM, 100–120 ГБ NVMe. Режим очереди с Redis и парой воркеров, Postgres, векторная база рядом, место под сборку своего форка. Локальные модели на том же сервере — плюс память под веса: qwen2.5:3b в Q4 занимает 2,2 ГБ, llama3.1:8b — 5,6 ГБ, сверх всего остального. Расчёт под объём документов — в разборе сколько RAM нужно для Flowise.

Локация — Лондон. Причина инженерная: Flowise постоянно ходит наружу — в API моделей, за образами на Docker Hub, за пакетами npm при установке узлов. С британского адреса это открывается без ухищрений, а пинг из Москвы 45–60 мс делает веб-консоль неотличимой от локальной. Франция равноценна при аудитории в континентальной Европе, США берут ради чистого американского IP, Россия годится только под 152-ФЗ: с российского адреса запрос в OpenAI вернёт тот самый 403 unsupported_country_region_territory, и выглядеть это будет как поломка узла, хотя ключ исправен.

Оплата — картой российского банка, по СБП, криптовалютой или токеном MAAT: иностранная карта не нужна, даже когда сервер в Лондоне. Не уверены в конфигурации — напишите, сколько человек сядет в консоль и какого объёма база знаний, поможем подобрать. А если Flowise теперь кажется рискованной ставкой, посмотрите на n8n: проект живой и решает соседний класс задач.

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