Dify против Flowise: что выгоднее и когда

MAATRIX

Оба обещают одно: AI-приложение, собранное мышью, без единой строки кода. Только Flowise — один процесс Node с файлом SQLite рядом, а Dify — стек из десяти контейнеров с Postgres, Redis, векторной базой и песочницей для кода. Расходятся они не в цене сервера, а в том, что готово из коробки, кто сможет работать в интерфейсе и что разрешает лицензия.

Dify или Flowise: разница, из которой следует всё остальное

Flowise — визуальный редактор графа. Dify — продукт, построенный вокруг такого графа. Остальное вытекает отсюда.

Узлы Flowise почти дословно повторяют классы LangChain: Recursive Character Text Splitter, Conversational Retrieval QA Chain, Buffer Memory, Custom Function — вы видите те же параметры, что и в коде. Физически это одно Node-приложение плюс каталог ~/.flowise с database.sqlite, encryption.key и папкой storage:

$ docker ps --format '{{.Names}}\t{{.Image}}\t{{.Ports}}'
flowise   flowiseai/flowise   0.0.0.0:3000->3000/tcp

Dify прячет фреймворк и выдаёт готовые типы приложений — чат-бот, агент, чатфлоу, воркфлоу — плюс базу знаний, историю диалогов, ключи API и рабочие пространства с ролями. Плата за это — состав сервисов:

$ cd dify/docker && docker compose ps --services | wc -l
10

За десяткой стоят api (Flask/gunicorn), worker (Celery), web (Next.js), db (Postgres), redis, weaviate, sandbox для узлов с кодом, ssrf_proxy (Squid) для исходящих запросов, nginx и plugin_daemon — демон плагинов из ветки 1.x, когда провайдеры моделей уехали из ядра в маркетплейс.

Итог: Flowise убирается удалением каталога, Dify — инфраструктура с миграциями базы. Развёртывание: Dify на VPS, Flowise для no-code AI.

Что готово из коробки: база знаний, логи и API

База знаний. В Dify это раздел консоли, а не набор узлов. Загружаете файлы, выбираете режим нарезки (обычный или родитель-потомок), длину фрагмента, перекрытие, метод индексации: High Quality — через эмбеддинги, Economical — по ключевым словам, без обращений к модели и счёта за токены. Дальше извлечение: векторный, полнотекстовый или гибридный поиск, реранк, Top K, порог релевантности, фильтры по метаданным. Рядом кнопка проверки: видно, какие фрагменты и с какими оценками вернулись.

Во Flowise то же собирается руками: узел загрузчика, сплиттера, эмбеддингов, векторного хранилища, ретривера — и так в каждом потоке заново. С ветки 2.x есть Document Store, общее хранилище для нескольких чатфлоу, но параметры поиска остались в свойствах узлов.

Обратная сторона: во Flowise делается то, для чего в Dify нет пункта меню — свой сплиттер, инструмент на JavaScript в узле Custom Function, связка двух ретриверов. Dify мыслит сценариями, Flowise — блоками, и на экзотике блоки гибче.

Наблюдаемость. Dify пишет каждый диалог: запрос, ответ, использованные фрагменты знаний, токены, стоимость; есть оценки и аннотации — ответ правится руками и закрепляется как эталонный. У Flowise логи скромнее, обычно рядом ставят Langfuse.

Отдача наружу. Оба дают HTTP API и виджет чата. У Flowise это POST /api/v1/prediction/<chatflowId> с ключом в заголовке Authorization: Bearer. У Dify — POST /v1/chat-messages с ключом вида app-..., и в теле обязательно поле user: без него придёт 400 с "code": "invalid_param".

Ресурсы: чем платит каждая архитектура

Считать надо не «сколько ест», а что требуется по составу процессов. Документация Dify для Docker Compose требует минимум 2 ядра CPU и 4 ГБ RAM — порог запуска, а не рекомендация с запасом: Postgres, Redis, Weaviate с индексом в памяти, два воркера, демон плагинов, песочница, nginx и Next.js, у каждого свой резидент.

Flowise требований к памяти не выставляет, зато выставляет требование к рантайму — поле engines.node в package.json. На старом Node установка обрывается сразу:

error flowise@x.y.z: The engine "node" is incompatible with this module.
Expected version ">=18.15.0". Got "16.20.2"

В свежих ветках порог поднимался — смотрите engines своей версии.

Отказы при нехватке памяти разные. Dify на двух гигабайтах не падает красиво: его убивает ядро, а в docker compose ps вы видите Restarting (1) у случайного сервиса. Виновника покажет dmesg -T | grep -i "out of memory".

Flowise упирается не в системную память, а в кучу V8, обычно на индексации большого набора документов:

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed -
JavaScript heap out of memory

Лечится не апгрейдом тарифа, а переменной NODE_OPTIONS=--max-old-space-size=3072 — если три гигабайта на сервере физически есть. Расчёт под объём документов — в разборе сколько RAM нужно для Dify.

Про процессор: пока ответы и эмбеддинги считает облачная модель, оба остаются оркестраторами, CPU почти не нагружен.

Лицензии и работа командой: где заканчивается «бесплатно»

Dify распространяется под Apache 2.0 с дополнительными условиями. Два из них практические: нельзя использовать Dify как основу мультиарендного SaaS без отдельного разрешения и нельзя убирать или подменять логотип и информацию о правообладателе в консоли. Внутренней платформе это не мешает. Агентству, которое продаёт клиентам «свою» AI-платформу под своим брендом, — стоп: развернуть Dify у клиента и обслуживать можно, перепродать как свой продукт нельзя.

Ядро Flowise — Apache 2.0 без таких оговорок, зато корпоративная часть (SSO, рабочие пространства, роли) вынесена в платную редакцию. Картина зеркальная: Dify ограничивает перепродажу, но роли отдаёт бесплатно; Flowise использование не ограничивает, но многопользовательский режим продаёт.

В открытой версии Dify роли живут на уровне рабочего пространства: владелец, администратор, редактор, участник. Редактор правит промпты и наполняет базу знаний, но не трогает ключи провайдеров и биллинг — разделение, которого не хватает, когда в проекте появляется третий человек (ИИ-ассистент для команды на Dify).

Оговорка: лицензии меняются, оба проекта свои уже правили. Перед внедрением, от которого зависят деньги, откройте LICENSE в репозитории, а не пересказ в статье — включая эту.

Эксплуатация: обновления, секреты и то, что теряется навсегда

Обновление Dify — процедура, а не команда: дамп базы, docker compose down, git pull, подъём с docker compose up -d --pull always, миграции применятся при старте api. Забывают одно: новые переменные в .env сами не появляются, файл сверяют с .env.example — иначе сервис стартует, но ведёт себя странно. У Flowise обновление — новый тег образа и перезапуск с тем же томом. Оба фиксируйте версией, а не latest: с latest откатываться некуда.

Ключ шифрования Flowise — самая дорогая грабля инструмента. Учётные данные (ключи OpenAI, токены, пароли к базам) лежат в SQLite зашифрованными, а ключ — файлом encryption.key рядом. Пересоздали контейнер, не примонтировав том, — интерфейс поднимется, потоки будут на месте, а узлы начнут падать на расшифровке кредов. Восстановления нет, только заводить заново; фиксируйте ключ переменной FLOWISE_SECRETKEY_OVERWRITE. У Dify ту же роль играет SECRET_KEY из .env — генерируется один раз (openssl rand -base64 42).

SQLite под нагрузкой. База Flowise отлично живёт, пока пользователь один. На нескольких параллельных диалогах появляется классика:

QueryFailedError: SQLITE_BUSY: database is locked

Ответ — DATABASE_TYPE=postgres с отдельной базой: на серьёзной нагрузке Flowise догоняет Dify по составу инфраструктуры.

Бэкап. У Flowise один каталог: tar czf flowise-$(date +%F).tgz -C ~ .flowise. У Dify — дамп Postgres, тома с файлами и векторами и обязательно .env: без SECRET_KEY дамп бесполезен, как база Flowise без encryption.key.

Сеть. Оба держат ключи от ваших моделей: наружу только через nginx с сертификатом, порт приложения закрыт фаерволом. Особенность Dify: исходящие запросы HTTP-узлов идут через ssrf_proxy, который режет обращения в приватные диапазоны — узлу, которому нужна внутренняя сеть, придёт отказ, а выглядеть это будет как «нода не работает». Разбор аварий — в статье Dify на сервере: частые ошибки.

Таблица и честный вывод: кому что выгоднее

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

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

Не берите ни то, ни другое, если задача не диалог, а автоматизация с расписанием и вебхуками: там уместнее n8n с AI-агентами. А для одного простого приложения тридцать строк кода дешевле любого конструктора.

И про цену ошибки: переезд между ними — не импорт, а пересборка. Форматы экспорта несовместимы; на средний проект закладывайте день работы.

Что заказать в MAATRIX под Dify или Flowise

Оба приложения есть в каталоге apps.maatrix.io и ставятся автоматически при заказе сервера — команды из статьи набирать не нужно. Работает на Ubuntu и Debian; адрес панели и стартовые доступы появляются в личном кабинете, в разделе «Доступ».

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

Честный минимум под Dify — 2 vCPU, 4 ГБ RAM, 60 ГБ NVMe плюс swap на 4 ГБ. Ровно то, что требует документация: стек поднимется и обслужит небольшую команду с базой знаний на несколько сотен документов. Запаса нет — параллельная индексация будет заметна. На 2 ГБ пытаться не стоит: до консоли вы дойдёте, а первая же индексация закончится строкой про out of memory в dmesg.

Комфортный вариант — 4 vCPU, 8 ГБ RAM, 100–120 ГБ NVMe. Здесь Dify перестаёт быть капризным: десяток приложений, база знаний на десятки тысяч фрагментов, спокойные обновления, место под дампы и растущий каталог volumes; рядом на другом порту помещается Flowise как песочница. Когда фрагментов станут сотни тысяч, дешевле вынести векторную часть на отдельный Qdrant, чем докупать память общему серверу.

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

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

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