OpenConnector, Composio, Nango и Pipedream: что именно открыто?
Сравниваем исходный код, самостоятельное развёртывание и лицензии четырёх инструментов интеграции, добавление provider и переход с OOMOL SaaS на свой сервер.

Когда AI-агент впервые успешно работает с Gmail, Notion или Slack, результат становится ощутимым. Помощник уже не только отвечает на вопросы: он находит письма, обновляет документы и выполняет рабочие задачи.
Затем возникают более конкретные вопросы. Можно ли добавить недостающую операцию? Насколько подробно получится изучить неудачный вызов? Если клиент требует хранить учётные данные в своей инфраструктуре, можно ли перенести туда и сервис подключений?
Здесь важны объём опубликованного кода и возможность самостоятельно управлять сервисом. OpenConnector, Composio, Nango и Pipedream подходят для интеграции приложений, но открывают разные части системы и предлагают разные условия развёртывания.
Какая часть системы доступна в исходном коде
SDK, коннектор и среда выполнения решают разные задачи.
- SDK формирует запросы и получает ответы. Его исходный код позволяет проверить поведение клиента.
- Код коннектора превращает операцию в запрос к стороннему API: преобразует параметры и обрабатывает результат. Публикация этого кода позволяет изучать и расширять реализацию.
- Среда выполнения коннекторов запускает операции и обычно управляет учётными данными, правами и журналами. Открытый код и инструкции по развёртыванию позволяют команде взять эти компоненты под свой контроль.

Рисунок 1. Код коннектора работает внутри среды выполнения. Конкретная реализация зависит от продукта.
Публичный SDK не означает, что опубликован и код шлюза. Возможность изменить коннектор сама по себе также не даёт возможности развернуть всю платформу независимо от поставщика.
Сравнение четырёх продуктов
| Продукт | Основной публичный код | Самостоятельное развёртывание | Что нужно проверить |
|---|---|---|---|
| OpenConnector | Connector SDK, oo CLI, шлюз, определения provider, исполнители операций и Web Console | Публичные инструкции для Docker и Node.js, поддержка Cloudflare | Основной репозиторий — Apache-2.0, SDK и CLI — MIT. Для каждой операции нужны исполнитель и соответствующая авторизация |
| Composio | SDK, CLI и адаптеры фреймворков в основном публичном репозитории | Корпоративные варианты самостоятельного и частного развёртывания | MIT-лицензия SDK не определяет лицензию реализации шлюза |
| Nango | Код платформы интеграций и функций | Бесплатная и Enterprise-редакции для своего сервера | Основной репозиторий — Elastic License 2.0; бесплатная редакция имеет ограниченный набор функций |
| Pipedream | Компоненты, документация и связанные пакеты | Компоненты обычно исполняются в инфраструктуре Pipedream | Лицензия Source Available; публичные компоненты не означают доступность всей платформы для самостоятельного развёртывания |
Источники: OpenConnector, репозиторий Composio, развёртывание Composio, развёртывание Nango, компоненты Pipedream.
Если нужного provider ещё нет
Предположим, команда внедрила новую CRM. Агент должен искать клиентов и обновлять историю взаимодействий, но этого сервиса пока нет в каталоге.
Полезная точка расширения — добавление provider на стороне шлюза. Это интеграция сервиса с его способом авторизации, параметрами и операциями. SDK и CLI сохраняют привычный способ вызова; пользователю обычно не приходится изменять их исходный код.
OpenConnector предлагает три пути:
- Реализовать provider самостоятельно в своём шлюзе и использовать его в нужные бизнесу сроки.
- Отправить PR, чтобы интеграцией могли пользоваться и другие команды.
- Создать issue, описав сервис и операции, поддержку которых должна добавить наша команда.
Для таких запросов на новые provider или операции мы обычно включаем соответствующую реализацию в проект в течение 24–36 часов. Это обычный темп работы команды; сложность API, доступ к тестовым аккаунтам и условия авторизации стороннего сервиса могут повлиять на сроки.
Поэтому отсутствие сервиса в каталоге не закрывает путь к интеграции. Можно разработать её самим или вместе с сопровождающими проекта, сохранив существующие инструменты вызова. Руководство по добавлению provider · Создать запрос
Публичный код OpenConnector охватывает Connector SDK, oo CLI, шлюз, определения и исполнители операций, Web Console. Для приложения доступен SDK, для командной строки — oo connector, для совместимых агентов — MCP, для других клиентов — HTTP/OpenAPI. SDK и CLI работают как с OOMOL, так и с собственной средой выполнения. Инструменты разработчика
Код находится в репозиториях OpenConnector, Connector SDK и oo CLI. Можно проверить путь от клиента до исполнения, управлять подключёнными аккаунтами, правами на операции и журналами со скрытыми чувствительными данными в своей инфраструктуре.

Рисунок 2. Снимок из официального репозитория. Названия и числа относятся к версии на снимке и не подтверждают текущее количество интеграций.
После добавления provider приложения и агенты используют те же точки входа. Перед внедрением операции проверьте наличие исполнителя, подходящие параметры и возможность выполнить требования стороннего сервиса к авторизации.
Основной репозиторий Composio описан как SDK monorepo: Python, TypeScript, CLI и адаптеры. Он помогает изучить клиентское поведение, но не подтверждает открытость внутренней реализации шлюза. Репозиторий Composio
При этом Composio предлагает корпоративное самостоятельное развёртывание и частные конфигурации. Называть его исключительно облачным сервисом было бы неверно. Стоит отдельно сравнивать доступность публичного кода, необходимость корпоративного соглашения и возможность изменений после развёртывания. Composio MCP Gateway
Nango публикует код платформы и поддерживает свой сервер. Бесплатная редакция в основном покрывает авторизацию и API-прокси; функции, синхронизация, webhooks и MCP относятся к полному предложению Cloud или Enterprise. Обзор Nango
В Pipedream можно читать код компонентов, писать собственные и отправлять PR. Обычно они работают в бессерверной инфраструктуре Pipedream. Возможность изменить операцию и возможность самостоятельно эксплуатировать всю платформу — разные свойства. Документация Pipedream
У опубликованного кода тоже есть условия использования
Наличие кода на GitHub не означает одинаковых лицензионных прав.
| Код | Опубликованная лицензия |
|---|---|
| Основной репозиторий OpenConnector | Apache-2.0 |
| Connector SDK | MIT |
| oo CLI | MIT |
| Публичный SDK Composio | MIT |
| Основной репозиторий Nango | Elastic License 2.0 |
| Основной репозиторий Pipedream | Pipedream Source Available License |
Если планируете поддерживать форк, распространять код или предоставлять на его основе внешний сервис, сначала изучите соответствующие условия. Лицензия OpenConnector распространяется на код проекта; условия внешних API, правила авторизации и права на бренды сохраняются отдельно.
Свой сервер требует сопровождения
Самостоятельное развёртывание позволяет изучать состояние среды, недавние ошибки и журналы, а затем менять конфигурацию или код.

Рисунок 3. Пример интерфейса из официального репозитория. Статистика на снимке не является текущим показателем масштаба или надёжности.
Потребуется также отвечать за обновления, резервные копии, ключи, инфраструктуру и регистрацию OAuth-приложений для некоторых сервисов. Контроль над системой сопровождается этой работой.
Начать с SaaS и перейти на свой сервер по мере роста
OOMOL SaaS и открытый OpenConnector используют общую модель вызова коннекторов: идентификаторы provider и операций, а также контракты параметров. Приложение или агент оперирует теми же сущностями независимо от того, где работает среда — у OOMOL или на ваших серверах. Варианты использования
Можно начать с SaaS, а при росте бизнеса или появлении требований клиента развернуть OpenConnector у себя и направить SDK и CLI на новый адрес. Поддерживаемые вызовы и их параметры можно использовать повторно, не реализуя эти интеграции заново.
| Инструмент | Настройка для своего сервера | Что можно сохранить |
|---|---|---|
| Connector SDK | Создать клиент OpenConnector со своим baseUrl и токеном среды | Идентификаторы поддерживаемых операций, входные параметры и методы вроде execute |
| oo CLI | Задать OO_CONNECTOR_URL и при необходимости OO_CONNECTOR_TOKEN | Команды коннектора search, schema, run и параметры операций |
Подробности — в руководствах SDK и CLI.
В новой среде всё равно нужно настроить подключения аккаунтов, OAuth-приложения и учётные данные. Управление командами, пользователи проектов и прочие возможности SaaS требуют отдельной проверки совместимости. Общая модель сохраняет слой вызовов коннекторов, а не переносит автоматически все аккаунты и функции платформы.
Для проверки выполните привычную операцию в SaaS, а затем подключите тот же SDK или CLI к своей установке и повторите вызов с теми же параметрами. Если сервиса нет, оцените также процесс добавления provider или подачи запроса.
Команда, которой нужен быстрый старт и возможность дальнейшего самостоятельного управления, может подключить приложение через OOMOL или развернуть свой экземпляр и проверить ежедневную рабочую операцию.
Логотипы и снимки интерфейса взяты с официальных сайтов или из репозиториев для идентификации и сравнения продуктов. Права принадлежат их владельцам. Концептуальная схема создана для этой статьи.