Что случилось с Flowise: хронология закрытия
29 июля 2026 года команда Flowise объявила о закрытии визуального конструктора LLM-приложений и в тот же день заморозила код: активная разработка функций прекратилась, новые Pull Requests больше не принимались. 13 августа репозиторий на GitHub перевели в статус публичного архива, 31 августа поддержка закончилась. В объявлении прямо сказано: код под Apache 2.0 ваш, форкайте. Именно на этом шаге и выяснилось, что забрать проект «как есть» нельзя.
| Дата | Событие |
|---|---|
| 29 июля 2026 | Объявление о закрытии и заморозка кода |
| 13 августа 2026 | Репозиторий переведён в публичный архив |
| 31 августа 2026 | Поддержка прекращена |
| 10 сентября 2026 | Шесть advisory без исправленных версий |
Flowise - визуальный конструктор для LLM-приложений: на холст перетаскивают модель, векторное хранилище, инструменты и память, соединяют блоки линиями и получают чат-бота, RAG-поиск по документам или агента. Проект собрал 55 тысяч звёзд на GitHub, 25 тысяч форков и почти 7 миллионов скачиваний Docker-образа. Разворачивали его у себя компании, которым нельзя отправлять данные в облачные конструкторы.
Установки после закрытия никуда не делись, и это главная практическая проблема: код продолжает работать, а бюллетени об уязвимостях продолжают выходить. 10 сентября GitHub опубликовал ещё шесть advisory для Flowise, у всех пометка «исправленной версии нет». Исправлять их некому, потому что мейнтейнера больше нет. Разбор истории закрытия с цитатами из объявления опубликован в исходном материале на Habr, а официальная страница закрытия проекта доступна на flowiseai.com/sunset.
Почему команда объяснила закрытие именно так
Формулировка из объявления: «разработчики всё чаще доверяют сложные задачи агентам для программирования, а жёсткие low-code-процессы упираются в потолок». Речь не о техническом провале конструктора. Команда зафиксировала смену практики: задачи, под которые делали визуальные канвасы, всё чаще решают агенты, пишущие код напрямую. В такой картине мира холст с блоками проигрывает не по набору нод, а по гибкости.
Из этой логики не следует, что визуальные конструкторы исчезнут целиком: она описывает конкретный класс задач и конкретный момент времени. Переносить её на другие low-code AI-инструменты можно только с оговоркой, что их авторы таких заявлений не делали.
Что происходит с уже развёрнутыми установками
Работающие инсталляции не отключаются: архив репозитория не ломает уже запущенный код, и ваша копия продолжит работу. Проблема в другом: обновлений нет, исправлений безопасности тоже, а новые advisory только фиксируют дыры. Обновляться некуда, кроме сторонних форков, и каждая найденная уязвимость остаётся открытой в вашей инсталляции навсегда.
Для компании это означает выбор из двух путей: содержать своего мейнтейнера, который патчит код вручную, или мигрировать на форк. Сценарий «дождёмся апдейта» больше не работает.
Почему форк «как есть» невозможен: лицензионная ловушка
Заявление «код под Apache 2.0» покрывает не весь репозиторий. Файл лицензии начинается не с текста Apache, а с преамбулы. Вот она дословно:
Portions of this software are licensed as follows: All content that resides under packages/server/src/enterprise directory and files with explicit copyright notice such as IdentityManager.ts are licensed under Commercial License.
Перевод по смыслу простой: всё содержимое каталога packages/server/src/enterprise и файлы с явным уведомлением об авторских правах, например IdentityManager.ts, лицензированы под Commercial License FlowiseAI. Дальше идут условия: использовать в продакшене только с подпиской, модифицировать можно, но права на изменения принадлежат FlowiseAI, копировать, публиковать и распространять запрещено. Разрешено лишь копировать и менять код «для разработки и тестирования». При этом контент вне этих директорий и ограничений доступен под Apache 2.0. Полный текст лицензии опубликован в репозитории: Flowise/LICENSE.md.
Что именно лежит в packages/server/src/enterprise
По подсчётам автора форка, в каталоге около 130 файлов коммерческого кода, 13,4 тысячи строк на TypeScript - примерно пятая часть сервера. Импортируют эту папку 64 файла открытой части. От неё зависят вход в систему, JWT в cookie, сущности «пользователь», «организация» и «рабочее пространство», проверка прав на каждом маршруте и 48 миграций базы. Это не набор опциональных корпоративных надстроек, а та часть, без которой приложение не поднимается: по словам автора, бесплатная версия Flowise 3.x без неё даже не запускается.
Цифры по количеству файлов, строк и миграций приводит автор разбора форка; независимой проверки этих деталей в официальных материалах Flowise нет, поэтому перед установкой в продакшен их имеет смысл сверять с кодом репозитория.
Чем грозит использование коммерческого кода без подписки
Публикация форка с enterprise-файлами нарушает условия Commercial License: распространение прямо запрещено, а все права на изменения остаются у FlowiseAI. Оформить подписку тоже некуда, проект закрыт, и продавать её больше некому. Это не юридическая консультация, а чтение лицензии: если вы публикуете зеркало репозитория целиком, вы распространяете код, который распространять нельзя.
Схема open core (открытое ядро плюс закрытые корпоративные функции) сама по себе распространена и удобна для вендора. Ловушка появляется в момент закрытия: ядро открыто, но без коммерческой части оно не работает, а лицензия не даёт эту часть открыть.
Как автор Keelflow вырезал коммерческий код и написал замену
Автор форка сделал то, что предложили мейнтейнеры Flowise, и продолжил проект под именем Keelflow. Форк опубликован под Apache-2.0 и стартует с Flowise 3.1.4. Работа шла в три шага: вырезать коммерческий код из истории, написать свою реализацию базовых функций, сохранить совместимость с существующими базами.
Зачем вырезать код из истории, а не просто удалить файлы
Удаление файлов новым коммитом ничего не решает: код остаётся в предыдущих коммитах, доступен через git log и уезжает вместе с клоном репозитория. Утилита git filter-repo переписывает историю так, что файлы исчезают из всех коммитов. Для форка это ключевой шаг: чистая история означает, что вместе с репозиторием не распространяется чужая коммерческая лицензия.
Побочный эффект тоже надо учитывать: после перезаписи истории хеши коммитов меняются, и старые форки, зеркала и ссылки на конкретные коммиты перестают совпадать с новыми.
Что вошло в замену коммерческого кода
Замена закрывает базовую функциональность: одна учётная запись владельца плюс API-ключи с правами на отдельные действия, а сессии хранятся на сервере, а не в JWT. В cookie лежит случайный 32-байтовый токен, в базе - только его SHA-256. Речь о минимуме, при котором приложение работает, а не о воссоздании всей корпоративной части: корпоративные надстройки просто отброшены. Точный объём замены в строках в подтверждённых материалах не указан, поэтому перед установкой в продакшен состав и размер изменений стоит перепроверить по коду репозитория и по своим сценариям входа.
Совместимость со старыми базами Flowise 3.x
Keelflow заявляет совместимость со старыми базами Flowise 3.x: flows, credentials, API-ключи и база данных работают как есть, без пересборки схемы с нуля. Проверяется это тестом, который скачивает опубликованный пакет из npm и запускает скомпилированные миграции - все 57, включая коммерческие. Тест проверяет, что вместо создания владельца предлагается вход, регистрация закрыта, старый пароль подходит, старый flow виден, старый API-ключ читает flow. Отдельная работа здесь нужна потому, что 48 миграций базы лежали именно в коммерческом каталоге и их пришлось закрывать своей реализацией. Совместимость заявлена для ветки 3.x, поэтому перед миграцией проверьте свою версию и сделайте бэкап. Репозиторий форка: github.com/Perruer/keelflow.
Что нашлось в открытой части Flowise по дороге
Пока вырезался enterprise-каталог, автор разобрал и открытую часть кода. Ниже находки с оценкой риска. Часть из них типична для open-source проектов, часть выглядит странно для self-hosted инструмента; объединяет их одно - исправлять это больше некому. Детали и оценки приводятся со слов автора форка.
Сторонний скрипт Rewardful в админке
В административном интерфейсе найден сторонний скрипт Rewardful - сервиса партнёрских программ для SaaS, который отслеживает переходы по реферальным ссылкам и регистрации. Из-за общего кода интерфейса скрипт загружался и в каждой self-hosted установке. Риск в том, что админка тянет код третьей стороны, и вы не контролируете, какие данные он получает и куда уходят запросы. Утверждать, что данные утекали, оснований нет. Вопрос в другом: в проекте без мейнтейнера такую внешнюю зависимость уже никто не уберёт, и её придётся вырезать самостоятельно.
Загрузка списка моделей с GitHub при каждом обращении
Список моделей подтягивается с GitHub при каждом обращении; там же загружались шрифты с Google Fonts, а шапка на каждой странице запрашивала у GitHub API число звёзд репозитория. Минусы предсказуемы: задержка на каждом запросе, зависимость от внешнего сервиса, невозможность работы в изолированной сети без правок и сам факт обращения к внешнему хосту. После архивации репозитория источник может стать недоступен, и поведение функции придётся проверять отдельно. Тот же класс риска хорошо виден на истории с внезапным удалением моделей: Microsoft убрала Mage-Flow с Hugging Face без предупреждения, и все, кто опирался на эти ссылки, остались с ошибкой 404.
TRUST_PROXY=true по умолчанию
Настройка TRUST_PROXY=true выставлена по умолчанию, а это означает доверие заголовкам вида X-Forwarded-For: Express верил заголовку от кого угодно. Если приложение стоит за обратным прокси и не проверяет, кто именно передаёт эти заголовки, клиент может подставить себе любой IP. Практические следствия: обход ограничений по IP-адресу и искажённые логи, в которых вместо реального клиента видно что угодно. Для установок за nginx или Traefik настройку проверяют руками.
Уязвимость с учётными данными чужого пространства
Одна из находок позволяет получить учётные данные чужого рабочего пространства. В механику эксплойта углубляться смысла нет: важнее, что исправления не будет. Именно такими дырами и наполняются advisory после ухода мейнтейнера. Примеры опубликованных бюллетеней доступны в GitHub Security Advisories: GHSA-qqvm-66q4-vf5c и GHSA-6vh2-wg4h-4vwj.
Безопасность после закрытия: шесть advisory и сокращение зависимостей
10 сентября GitHub опубликовал ещё шесть advisory для Flowise, у всех пометка «исправленной версии нет». Механика простая: бюллетени продолжают публиковаться, но закрывать их некому, потому что репозиторий в архиве, а поддержка закончилась 31 августа.
Почему шесть advisory без исправлений - это важно
Для компании, которая развернула Flowise, шесть открытых бюллетеней означают конкретную работу: либо патчить самостоятельно, либо мигрировать. Патчинг требует своего мейнтейнера и понимания кодовой базы, миграция требует проверки данных и функциональности. Оба пути дешевле пройти заранее, чем после инцидента.
Сокращение зависимостей в Keelflow
Проверка зависимостей Flowise 3.1.4 дала 385 бюллетеней, из них 19 критических и 145 высоких. Смысл не в самой цифре: 385 чужих уязвимостей, которые нужно отслеживать и обновлять, это постоянная нагрузка на поддержку и большая поверхность атаки. В работе над Keelflow зависимости обновляли, но конкретное итоговое число бюллетеней в подтверждённых материалах не приводится, поэтому ориентироваться на какую-то одну цифру «после» не стоит. Это результат конкретной работы над форком, а не автоматическое следствие кнопки Fork: зависимости пришлось вычищать вручную.
Что не переносится при переезде на Keelflow
Ограничения лучше знать до миграции, а не после. Перечисленные ниже функции в Keelflow отсутствуют, потому что жили в коммерческом каталоге.
SSO, роли и несколько рабочих пространств
- SSO: единый вход через корпоративный провайдер. Без него пользователи входят по локальным учётным данным.
- Роли: разграничение прав между пользователями. В Keelflow этой модели нет, все учётные записи равны между собой.
- Несколько рабочих пространств: изоляция команд друг от друга. Общей становится одна область, и данные команд придётся разделять организационно, а не технически.
Появления этих функций автор форка не обещает: их нет в описанной замене, которая закрывает только сессии и API-ключи.
Другие пользователи корпоративной версии
Пользователи корпоративной версии не переносятся. Причина в том, что сущности пользователя и рабочего пространства вырезаны вместе с enterprise-кодом, а 48 миграций базы, которые их обслуживали, переписаны заново. На практике это означает, что учётные записи и права доступа придётся создавать заново, даже если сами данные чатфлоу и документы сохранились.
Стоит ли переезжать на Keelflow: практический чек-лист
Кому переезд подходит, а кому нет
Подходит:
- одиночным разработчикам и небольшим командам, которые используют базовые сценарии: чат-боты, RAG-поиск по документам, агенты;
- тем, у кого развёрнута Flowise 3.x и кто готов мириться с отсутствием SSO и ролей;
- тем, кто может сам читать код и патчить зависимости, потому что поддержка форка держится на одном человеке.
Не подходит:
- компаниям, где вход идёт через корпоративный SSO;
- командам с ролевой моделью доступа и несколькими изолированными рабочими пространствами;
- тем, у кого критичны учётные записи других пользователей корпоративной версии;
- тем, кто ищет вендорскую поддержку и SLA.
Что сделать до миграции
- Сделать полный бэкап базы и убедиться, что он восстанавливается, а не просто существует.
- Проверить точную версию Flowise: совместимость со стороны форка заявлена для ветки 3.x.
- Провести аудит функций: выписать всё, что используется, и сверить с тем, что переносится. Если в списке есть SSO, роли или несколько пространств, переезд закрывает не вашу задачу.
- Проверить лицензионную чистоту собственного форка: если в вашем зеркале остался каталог
packages/server/src/enterpriseв истории коммитов, вы распространяете код под Commercial License. - Развернуть тестовый контур на копии базы и прогнать свои сценарии до переключения продакшена.
Keelflow распространяется под Apache-2.0 и опубликован на GitHub. Гарантий поддержки и сроков выхода исправлений никто не даёт: это форк, который ведёт один автор.
Что эта история говорит об open-source AI-инструментах
Open core работает до тех пор, пока проект жив. При закрытии выясняется неприятная деталь: заявление «код под Apache 2.0, форкайте» может быть юридически неполным, если ключевые функции лежат в каталоге под коммерческой лицензией. Форк получается либо урезанным и без гарантий совместимости, либо нарушающим лицензию.
Практический вывод для выбора инструмента: до внедрения смотрите структуру репозитория и файл лицензии, а не только заголовок README. Проверьте, что лежит в директориях с пометкой коммерческой лицензии, и ответьте на вопрос, поднимется ли проект без них. Если система без этих файлов не стартует, вы зависите от вендора сильнее, чем кажется по лицензии Apache, а закрытие проекта превращается в ловушку с отложенным сроком.
Второй вывод касается внешних зависимостей: загрузка данных с чужого репозитория при каждом запросе, скрипты третьих сторон в админке и отсутствие локального кеша - это риски, которые становятся неуправляемыми, когда мейнтейнер уходит. История с удалением моделей Mage-Flow показывает тот же механизм с другой стороны: внешний источник может исчезнуть в любой день, и запасной план нужен заранее.
Пошаговый разбор закрытия и технические детали форка описаны в материале автора Keelflow. Если Flowise уже стоит у вас в продакшене, начните с инвентаризации базы и используемых функций: от неё зависит, тянет ли ваша установка переезд или требует отдельного мейнтейнера.