У агентства два заказчика, и оба хотят сами менять свои сценарии. Интернет-магазин игрушек желает поправить правило, по которому заявки из формы уходят в CRM. Клиника хочет добавить в напоминания о приёмах ещё один шаг. Оба просят «доступ в n8n», и тут выясняется, что это просьба с очень разным содержанием. Магазину достаточно открывать три своих сценария и не трогать остальное. Клинике нужно, чтобы её подрядчик по аналитике видел результаты выполнения, но не видел ни одного ключа от почты и мессенджера. Если на этом месте просто поставить один общий n8n и раздать учётные записи, в итоге получится не изоляция, а доверие на слово.
Эта статья про то, как разложить такую задачу по полочкам до того, как вы выберете сервер и начнёте разворачивать контейнеры. Порядок будет таким: сначала понять, чья это автоматизация, потом проверить лицензионную границу, затем сопоставить схемы с возможностями редакции, а в конце посмотреть, что происходит с секретами, журналами, обновлениями и уходом заказчика.
Две разные задачи под одним названием
Слово «агентство» скрывает как минимум два режима работы с n8n, и смешивать их опасно.
Первый режим: автоматизации самого агентства. Сводка по заявкам для менеджеров, выгрузка отчётов в таблицу, уведомления в рабочий чат, перенос оплат в бухгалтерский учёт. Это ваши процессы, ваши данные и ваши учётные записи. Здесь вопрос изоляции сводится к порядку внутри команды: кто что редактирует и где лежат ключи.
Второй режим: сервис для заказчиков. Сценарий работает с данными клиента, использует его доступы к CRM, почте, платёжной системе, а сам клиент (или его подрядчик) хочет видеть и менять этот сценарий. Тут появляются сразу три вопроса. Кто владелец автоматизации? Кто может её читать и менять? Что произойдёт, когда договор закончится?
Практичный приём: для каждого сценария в реестре фиксировать четыре поля. Владелец данных, владелец сценария, список людей с правом правки, место хранения секретов. Если для какого-то сценария вы не можете заполнить хотя бы одно поле одной фразой, схема ещё не готова. Общий экземпляр на всех заказчиков часто разваливается именно на этом: поля заполняются как «ну, агентство», «ну, Иван», «ну, где-то в учётках».
Лицензия идёт раньше расчёта серверов
Есть соблазн сначала прикинуть, сколько ядер и памяти нужно на десять заказчиков, а потом уже разбираться с условиями. Лучше наоборот. Сначала нужно понять, в каком режиме вы вообще вправе использовать выбранную редакцию, потому что от этого зависит, какие схемы вообще рассматривать.
В тексте Sustainable Use License использование ограничено собственными внутренними деловыми, личными или некоммерческими целями, а файлы Enterprise из этой лицензии исключены. Из этого следует аккуратный вывод для планирования: автоматизации, которые обслуживают процессы самого агентства, ложатся в понятную рамку. А вот модель, где вы оказываете заказчикам сервис на n8n, предоставляете им доступ или берёте плату именно за работу платформы, требует отдельной сверки.
Это не юридическая консультация, и ни одну агентскую схему здесь нельзя объявить разрешённой или запрещённой. Граница между «я пишу сценарии для клиента на своём рабочем инструменте» и «клиент пользуется моим n8n как услугой» зависит от конкретной коммерческой модели и формулировок договора. Правильный путь простой: опишите правообладателю свою схему такой, какая она есть, и получите ответ в письменной форме. Приложите к реестру автоматизаций это письмо, а не собственное толкование.
Практическое следствие для архитектуры: пока вопрос не закрыт, не стоит строить схему, которая необратимо зависит от одного из ответов. Если сценарии и экспорты хранятся так, что их можно перенести на экземпляр заказчика или в другую редакцию, ошибка в расчётах обойдётся дёшево.
Что даёт и чего не даёт Community
Теперь о возможностях. В сравнении редакций в документации n8n указано, что Community не включает проекты, совместное использование credentials, external secrets и внешнее бинарное хранилище. Отдельно сказано, что queue mode и multi-main имеют разные условия доступности, поэтому «масштабирование» нельзя считать бесплатным приложением к любой редакции.
Для агентства это ключевой момент, и вот почему. Проекты в n8n как раз и придуманы, чтобы разложить рабочие процессы и учётные данные по группам людей. Если их нет, внутри одного экземпляра Community вы не получите той границы, на которую рассчитываете, когда говорите заказчику «у вас будет своё пространство». Но важна и обратная осторожность: наличие проектов в старшей редакции ещё не делает их отдельной инфраструктурой. Проект разделяет права и видимость внутри одной установки. База данных, ключ шифрования, обновления, нагрузка и журналы остаются общими.
Вот как это выглядит на двух сценариях из начала статьи.
| Запрос | Магазин игрушек | Клиника |
|---|---|---|
| Кто правит сценарии | Маркетолог заказчика, только свои три сценария | Подрядчик по аналитике, только чтение результатов |
| Кто владеет ключами к внешним сервисам | Заказчик, ключи выдаются агентству на время работ | Клиника, ключи не должны попадать к подрядчику |
| Что страшнее всего | Случайная правка чужого сценария | Утечка доступа к почте или мессенджеру |
| Что нужно от схемы | Видимость только своего набора | Невозможность прочитать чужие секреты и возможность отозвать доступ одним действием |
Для магазина мягкого разделения по людям иногда достаточно, и здесь проекты были бы естественным инструментом, если ваша редакция их включает. Для клиники ставка выше: к секретам подрядчик не должен прикасаться вообще. Без проектов и без общих credentials в Community вы не можете рассказать заказчику, что «в вашем пространстве живут только ваши доступы». Всё, что у вас есть внутри одной установки, это договорённости. Поэтому для данной редакции честная картина такая: граница между заказчиками проходит по отдельным экземплярам, а не по ролям внутри общего.
Отдельный экземпляр: что именно он разделяет
Отдельный экземпляр на заказчика звучит как универсальное решение, но разберём, что он реально отделяет, а что нет. Говорить здесь про «один сервер на клиента» как догму не нужно: экземпляр это прежде всего отдельная база, отдельные настройки и отдельный секретный ключ. Где он физически работает, вопрос вторичный.
- База данных. Сценарии, история выполнений и учётные данные клиента лежат в его базе. Удаление или выдача её копии заказчику не затрагивает остальных.
- Ключ шифрования. Согласно документации по ключу шифрования, он шифрует credentials перед сохранением в базе. Если у каждого заказчика свой ключ, компрометация одного не открывает секреты другого.
- Пользователи. Список учётных записей у каждого экземпляра свой. Отозвать подрядчика означает удалить его в одном месте, не вспоминая, к чему ещё он мог иметь доступ.
- Обновления. Версию можно двигать для каждого заказчика по его графику, а не заставлять всех жить на одной.
Что отдельный экземпляр сам по себе не решает: он не защищает от ваших собственных ошибок. Если вы одним и тем же ключом шифрования запускаете десять экземпляров, потому что так было удобно копировать конфигурацию, изоляции секретов нет. Если один и тот же служебный токен лежит в переменных окружения всех экземпляров, он остаётся точкой пересечения. И если все контейнеры работают от одной системной учётной записи с общим каталогом данных, граница существует только на схеме.
Один сервер или несколько
Несколько экземпляров можно запустить на одном сервере или разнести по разным. Это решение про ресурсы и риск, а не про приватность. Разные VPS не оказываются автоматически на разном оборудовании и сами по себе не дают отказоустойчивости приложению, поэтому разнесение нужно обосновывать иначе: чтобы выделить заказчику с тяжёлыми сценариями собственную ёмкость, чтобы выбрать подходящую локацию, чтобы при передаче проекта можно было просто отдать сервер или его содержимое.
Если заказчиков немного и сценарии лёгкие, несколько изолированных контейнеров на одном VPS с root-доступом могут быть вполне разумным стартом. Ресурсы тарифов MAATRIX, от Ba с 1 vCPU, 2 ГБ RAM и 40 ГБ NVMe до Djed с 16 vCPU, 32 ГБ и 320 ГБ, стоит читать как ориентир по размеру, а не как обещание ёмкости: сколько экземпляров поместится, покажет только замер на ваших сценариях. Заказчику, у которого сценарии тяжёлые или данные чувствительные, логично выделить отдельный сервер, и тогда границу видно физически. Для n8n в каталоге MAATRIX предлагается установка, но точное наличие образа и ОС проверяется в форме заказа.
Если ваши сценарии включают вызовы моделей и обработку документов, полезно заранее прочитать про ИИ-автоматизации в n8n на VPS: такие нагрузки заметно меняют расчёт ресурсов.
Нужен сервер под эту задачу?
Разверните VPS MAATRIX за пару минут: NVMe, AMD EPYC, root-доступ, локации Россия, США, Франция и Великобритания. Оплата картой РФ и по СБП.
Секреты: где клиенты пересекаются тихо
Самые неприятные пересечения происходят не там, где их ждёшь. Рассмотрим три места, куда нужно заглянуть до запуска.
Ключ шифрования. Он защищает credentials в базе, и в queue mode, как сказано в документации, этот же ключ требуется всем workers. Для архитектуры из этого вытекает правило: у каждого заказчика своя связка «основной процесс плюс его workers» с одним общим для этой связки ключом, а между заказчиками ключи разные. Нельзя «для экономии» подключить worker одного заказчика к очереди другого: он получит и работу, и доступ к тому, что нужно для расшифровки. Храните ключи отдельно от резервных копий базы. Копия базы вместе с ключом это открытая книга, копия без ключа почти бесполезна.
Credentials внутри сценариев. Раз в Community нет совместного использования credentials и external secrets, учётные данные заказчика живут в его экземпляре и больше нигде. Это удобно как граница, но накладывает дисциплину: не копируйте сценарий из экземпляра в экземпляр вместе с привязанными данными доступа и не вставляйте токены прямо в узлы кода или HTTP-запросов ради скорости. Такой токен переживёт и сценарий, и договор, и попадёт туда, где его никто не ждёт. Для токенов, которыми агентство работает от своего имени, заведите отдельный экземпляр для внутренних автоматизаций, а не прячьте их в клиентских.
Права самих ключей во внешних сервисах. Изоляция в n8n бессмысленна, если заказчик выдал агентству ключ с правами администратора всей CRM. Просите ключи с минимальными правами и отдельного технического пользователя на каждую интеграцию. Тогда отзыв доступа делается там, где ключ родился, а не в вашей панели.
Журналы и данные выполнений
Секреты внимание привлекают, а журналы забываются. Между тем в истории выполнений лежат реальные данные: тело входящего запроса из формы, ответ платёжной системы, письмо из ящика. Для клиники это могут быть персональные данные пациентов, и вопрос о том, где и сколько они хранятся, это уже не про удобство отладки.
Отдельный экземпляр делает ситуацию проще: история выполнений остаётся в базе заказчика, и вы решаете, сколько её хранить, именно для него. Общий экземпляр заставляет искать компромисс: чтобы разобрать сбой магазина, вам приходится открывать список выполнений, в котором соседствуют записи клиники. Даже если вы благоразумно не смотрите, технически вы можете, а значит, об этом придётся говорить в договоре.
Несколько вещей, которые стоит решить заранее для каждого заказчика:
- сколько хранить историю выполнений и нужно ли сохранять данные успешных запусков;
- куда уходят системные журналы контейнера и кто имеет к ним доступ;
- что попадает в уведомления об ошибках: достаточно названия сценария и узла, тело запроса в чат отправлять незачем;
- где лежат бинарные файлы. Внешнее бинарное хранилище в Community недоступно, значит файлы остаются на диске экземпляра, и его размер надо учитывать при выборе тарифа.
Последний пункт приземлённый, но важный: сценарии, которые гоняют вложения и выгрузки, растут по диску быстрее, чем по процессору. Для таких заказчиков объём NVMe нужно смотреть раньше, чем число ядер.
Обновления: общая версия как скрытая зависимость
На общем экземпляре обновление это событие для всех. Вы переходите на новую версию, потому что магазину нужна свежая функция, а у клиники в это время работает напоминание, которое вы три недели не проверяли. Если что-то в поведении узла изменилось, пострадавшего вы узнаете по жалобе.
Отдельные экземпляры позволяют обновляться по очереди. Сначала внутренний экземпляр агентства, потом заказчик с самыми простыми сценариями, потом остальные. Это не гарантирует отсутствия проблем, но делает их локальными и позволяет откатить одного заказчика, не трогая прочих. Чтобы откат был возможен, перед каждым обновлением нужна копия базы и конфигурации именно этого экземпляра. Автоматические резервные копии на стороне хостинга считать готовым ответом нельзя, пока вы не убедились в их наличии для своего тарифа: сделайте и проверьте собственные.
Если вы в какой-то момент выйдете на queue mode, помните, что его доступность зависит от редакции, как отмечено в сравнении редакций, и что workers должны получать тот же ключ шифрования, что и основной процесс. Для небольшого числа заказчиков это обычно избыточно: проще держать отдельные скромные экземпляры, чем один крупный распределённый.
Заказчик уходит: проверка на реальность
Любая схема проверяется не в день запуска, а в день расставания. Возьмём клинику: договор закончился, и она хочет забрать свои сценарии вместе с работающими напоминаниями. Или, наоборот, подрядчик по аналитике больше не работает с клиникой, и его нужно срочно отключить.
В схеме с общим экземпляром приходится вырезать. Экспортировать сценарии по одному, вычищать из них упоминания чужих данных, переносить учётные данные (которых в экспорте не будет, значит, клиника заводит доступы заново), удалять историю выполнений клиники из общей базы. Каждый из этих шагов можно сделать, но каждый требует внимания, и ошибка в любом из них задевает другого заказчика.
В схеме с отдельным экземпляром порядок такой:
- Отключить входящие точки: вебхуки и триггеры, чтобы данные перестали поступать.
- Отозвать ключи во внешних сервисах заказчика, там, где они были выданы.
- Сделать итоговую копию базы и конфигурации, передать заказчику в договорённом виде. Ключ шифрования передавать отдельным каналом и только тому, кто принимает экземпляр.
- Удалить экземпляр, его том с данными, копии и записи в ваших реестрах и менеджере паролей. Срок хранения копий у себя зафиксировать в договоре.
Если нужно отключить только подрядчика, а не всю клинику, достаточно удалить его учётную запись и сменить те секреты, которые он видел. В отдельном экземпляре это один набор действий, а не поиск по всем клиентам.
Заметьте, что в этом разборе нигде не прозвучало «и всё будет в порядке». Отдельный экземпляр не освобождает от подготовки к уходу, он лишь делает подготовку предсказуемой. Пересмотреть реестр автоматизаций и отметить, какие сценарии заказчик сможет унести без вас, лучше при запуске, а не при расторжении.
Архитектура, где у каждой автоматизации есть хозяин
Соберём картину. Автоматизации самого агентства живут на собственном экземпляре, лицензионные вопросы по которому закрыты, а его секреты не пересекаются с клиентскими. Для каждого заказчика, чьи данные и доступы вы обрабатываете, существует отдельный экземпляр со своей базой, своим ключом шифрования, своим списком пользователей и своим графиком обновлений. Размещение этих экземпляров, на одном VPS или на разных, выбирается по ресурсам, локации и желаемой лёгкости передачи, а не из убеждения, что сервер сам обеспечивает приватность.
Проекты и общие credentials в старших редакциях могут пригодиться внутри одного экземпляра, например, чтобы разделить маркетинг и бухгалтерию одного и того же заказчика. Но между заказчиками границу всё равно стоит проводить отдельной установкой. А какая редакция и какая коммерческая модель допустимы для вашей схемы, нужно подтвердить у правообладателя, а не выводить из этой статьи.
Проверка у такой архитектуры простая: возьмите любой сценарий и ответьте на три вопроса. Кто его владелец? Где лежат его секреты и кто может их прочитать? Какими действиями его можно отделить от остальных и отдать? Если на каждый вопрос есть короткий конкретный ответ, заказчики и правда разделены. Если ответ звучит «ну, у нас всё в одном n8n», то разделены они пока только в презентации.