Привет. Я в своей мастерской эту штуку однажды уже словил: меняешь один base URL, а потом полдня бегаешь по десятку workflow и вычищаешь хвосты. В n8n нормальная схема такая: константы и общие адреса держим в Variables, секреты и токены — в Credentials или External Secrets, настройки окружения — в env, а то, что меняется во время работы, складываем в Data Table или в хранилище данных.
Дальше покажу мою рабочую раскладку, где какой тип данных живёт, когда custom variables реально спасают, а когда только создают лишнюю возню. Плюс дам таблицу выбора, примеры именования и чек-лист, чтобы потом не ковырять каждый сценарий вручную.
- Оглавление
- Короткий ответ
- Моя рабочая схема
- Когда брать Custom Variables
- Где держать токены и секреты
- Когда тащить значения в env
- Что делать в Community Edition
- Типовые косяки
- FAQ
Оглавление
- Сначала короткий ответ: что куда класть
- Моя рабочая схема: четыре ящика для общих значений
- Custom Variables: где они реально удобны
- Credentials и External Secrets: место для токенов
- env: когда URL и режимы завязаны на окружение
- Как жить, если у тебя Community Edition
- Ошибки, которые потом больно чинить
- Частые вопросы
Сначала короткий ответ: что куда класть
Вот мой быстрый фильтр, которым я пользуюсь сам:
| Что храню | Куда кладу | Почему так |
|---|---|---|
| Общий base URL API, пути, имена очередей, лимиты, статусы, константы | Custom Variables | Удобно переиспользовать в разных workflow и менять в одном месте |
| API token, client secret, пароль, refresh token | Credentials | Это секреты, их логичнее держать в credential-слое, а не раскидывать по узлам |
| Секреты, которыми управляешь централизованно для нескольких окружений | External Secrets | Нормально работает, когда dev и prod должны брать разные значения из одного общего контура |
| URL, которые завязаны на конкретный инстанс, docker-compose или серверные настройки | env | Это уже часть конфигурации запуска n8n, а не просто значение для бизнес-логики |
| Курсор синхронизации, last run, временный кэш, изменяемые значения | Data Table, база или workflow static data | Такие штуки меняются во время исполнения, для read-only переменных они не подходят |
Если говорить совсем по-честному, то запрос где хранить токены в n8n я закрываю одним правилом: токены несу в credentials. А вот запрос где хранить общие URL в n8n обычно упирается в выбор между variables и env. Тут уже смотри, это бизнес-константа или настройка конкретного окружения.
Если ты только собираешь архитектуру, тебе ещё пригодятся мои материалы про готовые шаблоны n8n и про partial execution для AI tools — там удобно посмотреть, как я обычно строю повторно используемые куски.
Моя рабочая схема: четыре ящика для общих значений
Я давно перестал валить всё в один карман. Когда у тебя пять сценариев, можно ещё жить на Set-узлах и копипасте. Когда их двадцать, начинается цирк. Поэтому я делю данные на четыре ящика.
1. Ящик констант
Сюда у меня идут base URL, названия коллекций, стандартные таймауты, лимиты страниц, статусы вроде new, paid, archived, а ещё общие пути для webhook и служебные префиксы. Если эти значения должны читаться из разных workflow и не меняться на лету, это идеальный кандидат для custom variables.
2. Ящик секретов
Секреты — это отдельная история. API ключи, bearer token, client secret, пароли к SMTP, ключи к CRM или платёжке я не держу в variables. У меня для этого credentials. Тогда один credential можно переиспользовать в нескольких узлах и не светить секрет в каждом HTTP Request.
3. Ящик окружения
Когда один и тот же workflow живёт в dev и prod, я стараюсь вытащить в env всё, что привязано именно к среде запуска: домен инстанса, служебные URL, внутренние endpoints, режимы логирования, отдельные системные параметры. Это уже не бизнес-константы, а часть конфигурации инстанса.
4. Ящик изменяемого состояния
Вот тут многие ошибаются. Видят слово variables и думают: «О, сейчас я туда запишу новый токен после refresh или курсор последней выгрузки». Нет, это плохая идея. Для таких штук нужен Data Table, база, Redis, внешний storage или хотя бы workflow static data, если сценарий локальный и небольшой. Кстати, если тебе близок такой подход, посмотри мой разбор про внутренние таблицы в n8n — там как раз о том, когда таблица удобнее, чем городить костыли.
Короче, моя формула такая: константы — в Variables, секреты — в Credentials, настройки окружения — в env, меняющиеся данные — в таблицу или хранилище. Как только начинаешь мешать эти слои, поддержку workflow сразу ведёт в кювет.
Custom Variables: где они реально удобны
Теперь про сами n8n custom variables. Штука годная, когда нужно держать одинаковые значения для нескольких сценариев и не плодить копии. Например, у тебя есть общий API endpoint, префикс для имен файлов, лимит батча, список допустимых статусов или флаг, который читает несколько workflow.
Мне нравится, что доступ к ним простой: в выражениях и в Code node можно брать значение как $vars.KEY_NAME. Это как раз тот случай, когда константы для workflow n8n начинают жить в одном месте, а не в двадцати Set-узлах. Поменял значение один раз — и все сценарии, где оно используется, подтянули новое значение.
Но есть несколько нюансов, про которые народ часто забывает:
- Custom Variables — это read-only слой. Они не для того, чтобы что-то записывать в процессе выполнения.
- Все значения там строковые. То есть числа, флаги и JSON ты потом сам приводишь к нужному виду в выражении или в коде.
- Если переменная не задана, workflow не падает автоматически. Это удобно, но легко пропустить косяк в конфиге.
- В новых версиях есть project-scoped variables, и это прямо кайф, когда не хочешь светить общие значения на весь инстанс.
Я обычно называю переменные скучно и предсказуемо: CRM_BASE_URL, ORDERS_PAGE_SIZE, MEDIA_CDN_URL, DEFAULT_SALES_STATUS. Чем меньше романтики в именах, тем быстрее потом разбирать чужой workflow.
Ещё важный момент: если ты засунул variable в Schedule Trigger, а потом поменял её значение, расписание может не перестроиться само. Такие места я всегда перепроверяю руками после публикации новой версии workflow.
Credentials и External Secrets: место для токенов
Вот тут начинается взрослая жизнь. Если в значении есть секрет, я его не называю «удобной переменной». Я называю это credential и отношусь к нему соответственно. Иначе очень быстро ловишь ситуацию, когда один токен торчит в HTTP заголовке, второй в Set, третий в заметке у коллеги, а четвёртый вообще забыли поменять.
Для большинства задач хватает обычных credentials. Создал один credential для API, подключил в нужных узлах и живёшь спокойно. Если токен обновляется через refresh flow, лучше строить схему так, чтобы credential или связанный слой аутентификации был единой точкой входа, а не набором копий в каждом workflow.
Когда проект жирнеет и появляется несколько окружений, я смотрю в сторону external secrets. Это уже нормальная история для тех, кто хочет управлять секретами централизованно. Особенно удобно, если dev и prod должны смотреть на разные значения, а логика workflow остаётся одной и той же.
Здесь правило простое: токены в n8n не надо хранить как обычные custom variables. Для секретов у платформы есть более аккуратные механики. Variables — про общие читаемые значения. Credentials и External Secrets — про чувствительные штуки, которые не хочется таскать по узлам руками.
А если строишь сценарии с уведомлениями и аварийной обработкой, заодно глянь мою схему контроля ошибок в n8n. Там как раз видно, почему единая точка для секретов и служебных адресов сильно упрощает поддержку.
env: когда URL и режимы завязаны на окружение
Я люблю env не за моду, а за дисциплину. Если значение относится к самому инстансу n8n, docker-compose, reverse proxy или сетевой схеме, ему чаще всего место именно в env. Типичный пример — внутренний домен, базовый служебный адрес, системные флаги, параметры запуска и прочая серверная кухня.
Такой подход особенно удобен, когда один и тот же workflow ты переносишь между окружениями. В логике сценария ничего не меняется, а конфиг на уровне запуска подсовывает нужное значение. Для self-hosted n8n это прям рабочий путь.
Но есть тонкая грань. Если у тебя URL относится не к серверу n8n, а к бизнес-логике проекта — например, CRM_API_BASE_URL или WAREHOUSE_API_BASE_URL, — я чаще оставляю это в variables. Иначе бизнес-константы размазываются по docker-файлам, а редактор workflow становится слепым.
Ещё я всегда проверяю, разрешён ли доступ к env в узлах на конкретном инстансе. На некоторых сборках или в более строгих настройках безопасности этот доступ ограничивают. Так что схема рабочая, но только если ты понимаешь, как именно настроен твой self-hosted контур.
Когда инфраструктура растёт, полезно ещё заранее продумать апдейты и масштабирование. На эту тему у меня уже лежат заметки про спокойные обновления n8n и про queue mode и вынос воркеров.
Как жить, если у тебя Community Edition
Вот это частый вопрос из серии n8n custom variables community edition. И тут ответ простой: в Community Edition самой фичи Custom Variables нет. Значит, нужен обходной, но аккуратный маршрут.
Я обычно делаю так:
- секреты держу в credentials;
- настройки инстанса и окружения — в env;
- общие справочники, маршруты и изменяемые данные — в Data Table или во внешней базе;
- повторяющиеся куски логики выношу в sub-workflow, чтобы не копировать одно и то же по всей сетке.
Это не так нарядно, как нативные variables, но жить можно очень бодро. Особенно если заранее договориться об именовании и не пихать константы в случайные Set-узлы под названием вроде test2_final_fix. Такое творчество я видел, больше не хочу.
Если сценарий у тебя повторяется в нескольких местах, иногда выгоднее вынести общую подготовку данных в отдельный sub-workflow и вызывать его из разных процессов. Тогда даже часть общих URL и констант можно собирать централизованно на входе, а не раскидывать по каждому workflow отдельно.
Ошибки, которые потом больно чинить
- Хранить токен прямо в HTTP Request узле. Сегодня работает, через месяц кто-то забыл, где он лежит.
- Смешивать секреты и константы в одном слое. Потом никто не понимает, что можно свободно редактировать, а что лучше не трогать.
- Пихать изменяемые значения в read-only переменные. Для курсоров, last sync и временного кэша это просто не тот инструмент.
- Хранить один и тот же base URL в пяти workflow вручную. Это классическая причина лишних правок и тихих расхождений.
- Называть переменные туманно. Чем яснее имя, тем меньше шанс, что через два месяца ты сам себе устроишь квест.
Мой финальный чек-лист перед запуском такой:
- секрет или нет;
- должно меняться во время исполнения или нет;
- это часть бизнес-логики или конфиг окружения;
- значение нужно одному workflow, проекту или всему инстансу;
- кто потом это будет поддерживать, кроме меня сегодняшнего.
Если ответить на эти пять вопросов честно, место для каждой переменной находится почти сразу. И тогда тема где держать общие URL, токены и константы в n8n перестаёт быть вечной головной болью.
FAQ
Можно ли хранить base URL в Custom Variables?
Да, это один из самых нормальных сценариев. Если адрес относится к логике интеграции и должен переиспользоваться в нескольких workflow, custom variables подходят отлично.
Можно ли класть API токен в Custom Variables?
Технически что угодно можно куда угодно засунуть, но рабочая практика такая себе. Для токенов я беру credentials или external secrets.
Что выбрать для dev и prod?
Если отличается конфигурация окружения, чаще выручает env или связка с external secrets. Если нужна общая константа внутри проекта, удобнее variables.
Подойдут ли workflow static data для общих констант?
Только если тебе нужен локальный сценарий внутри одного workflow. Для общего слоя между несколькими процессами это не лучший вариант.
Какой вариант я бы выбрал для нового проекта?
Я бы стартовал так: credentials для секретов, variables для общих констант, env для окружения, Data Table для изменяемых справочников и служебного состояния. Эта схема потом масштабируется заметно спокойнее.
Вот такой у меня рабочий расклад. Если в двух словах: custom variables в n8n — отличный дом для общих URL и констант, но не для секретов и не для данных, которые меняются на ходу. Как только разделяешь эти роли, поддержка автоматизации становится вменяемой, а правок по всем workflow резко меньше.