Привет. Если тебе надо выпустить community node для n8n в 2026 и потом нормально пройти к verified-статусу, схема теперь довольно конкретная: собираешь пакет через n8n-node, держишь публичный репозиторий, настраиваешь publish.yml в GitHub Actions, связываешь npm с workflow через trusted publishing и публикуешь релиз тегом. Ниже я покажу весь маршрут: что поменялось в правилах, что положить в package.json, какой workflow реально работает, где народ чаще спотыкается и каким чек-листом я сам пользуюсь перед отправкой в Creator Portal.
Статья пригодится и тем, кто только пилит первый узел, и тем, у кого пакет уже живёт на npm, но релизы пока едут с локальной машины. Смысл простой: пакет должен быть связан не с чьим-то ноутом, а с понятным репозиторием, коммитом и конкретным прогоном CI.
Сразу дам короткий маршрут: создай пакет через n8n-node CLI, проверь имя и метаданные, не тащи лишние runtime-зависимости, оформи README и лицензию MIT, подключи trusted publishing на стороне npm, добавь publish.yml, выпусти тег и проверь, что пакет на npm показывает provenance. После этого submit в Creator Portal уже выглядит как вменяемый финальный шаг, а не как лотерея.
Содержание
- Что поменялось в 2026 и зачем вообще нужен provenance
- Как выглядит пайплайн публикации: от тега до пакета в npm
- Что должно быть в package.json и репозитории
- Какой GitHub Actions workflow я считаю рабочей базой
- Чек-лист перед отправкой в Creator Portal
- Где чаще всего всё сыпется
- Финальный вывод
Что поменялось в 2026 и зачем вообще нужен provenance
Главная новость тут такая: публикация community node для n8n через GitHub Actions с provenance в 2026 стала уже не модной фишкой, а обязательной частью нормального процесса. Если целишься в verified community nodes, рассчитывай именно на такой сценарий. Я бы вообще строил процесс так с самого старта, даже если ты пока не бежишь в верификацию сегодня вечером.
Зачем весь этот движ? Потому что provenance связывает npm-пакет с конкретным репозиторием, коммитом и workflow. То есть у твоего релиза появляется внятное происхождение. Для пользователя это признак, что пакет собрался в понятной CI-среде, а не был залит откуда-то руками. Для самого автора это тоже плюс: меньше ручной возни, чище релизная дисциплина, легче откатывать косяки и проще объяснять команде, откуда взялась конкретная версия.
У n8n тут логика железная: verified-узлы должны выглядеть предсказуемо, проверяемо и одинаково аккуратно. Отсюда и рекомендация стартовать с n8n-node tool, и запрет на тяжёлую самодеятельность там, где можно опереться на стандартный шаблон. Если ты ещё не копал тему установки проверенных узлов, потом пригодится мой материал про verified community nodes — он хорошо даёт контекст, зачем вообще вписываться в эту историю.
И ещё один момент, который часто недооценивают. Верификация у n8n — это не только код. Смотрят на источник пакета, публичность репозитория, README, лицензию, соответствие автора, наличие нужных метаданных и общую опрятность узла. Короче, тут не прокатывает схема «код пашет, остальное потом дорисую».
Как выглядит пайплайн публикации: от тега до пакета в npm
Я люблю держать процесс максимально прямым. Сценарий такой: создаю узел через npm create @n8n/node@latest, пилю логику, гоняю локально через npm run dev, чищу линтером, затем делаю релиз через npm run release. Этот релиз обновляет версию, создаёт тег и пушит его. Дальше уже срабатывает GitHub Actions, ставит зависимости, собирает пакет и публикует его в npm с provenance.
Выглядит это примерно так:
- Создаёшь пакет с правильным именем.
- Добавляешь код узла, креды, документацию и метаданные.
- Подключаешь trusted publishing в npm для файла
publish.yml. - Коммитишь всё в публичный репозиторий.
- Делаешь
npm run release. - GitHub Actions публикует пакет.
- На странице пакета в npm проверяешь, что provenance подтянулся.
- После этого уже отправляешь узел в Creator Portal.
После первой настройки релизы становятся скучными, и это лучший комплимент процессу. Ты просто выпускаешь тег, а дальше работает конвейер. Если пакет уже публиковался руками, я бы не тянул с переходом. Заодно удобно сделать ревизию документации, package.json и публичных ссылок. И да, пока разбираешь релизный поток, полезно привести в порядок custom variables в стенде, если узел тестируется в связке с несколькими сервисами.
Что должно быть в package.json и репозитории
Вот тут, по моему опыту, и скрывается половина будущих факапов. Я всегда первым делом проверяю не код узла, а его упаковку. Для n8n community node это критично.
Минимум, который я считаю обязательным:
- имя пакета начинается с
n8n-nodes-или@scope/n8n-nodes-; - в keywords есть
n8n-community-node-package; - в
package.jsonзаполнен блокn8nс путями до nodes и credentials; - указан публичный
repository.url; - лицензия стоит MIT;
- есть README с описанием, примером использования и настройкой авторизации;
- автор и репозиторий не выглядят как два разных мира;
- интерфейс узла, help-тексты и README написаны на English.
Если пакет scoped, я отдельно напоминаю себе про первый публичный релиз. У scoped-пакетов на npm стартовая видимость обычно не публичная, и на первом publish можно легко влететь в тупую ошибку просто потому, что ты не открыл пакет наружу. Лучше проверить этот момент заранее, чем потом гадать, почему всё вроде настроено, а публикация буксует.
Для verified-пути я держу ещё три ограничения в голове. Первое: не тяну runtime-зависимости, если можно обойтись встроенными возможностями. Второе: узел не лезет напрямую в переменные окружения и файловую систему. Третье: если идея повторяет существующий официальный узел, то тут уже пахнет не новым community node, а обычным pull request в существующую экосистему.
Ниже каркас package.json, который я бы взял как ориентир:
{
"name": "@myorg/n8n-nodes-myservice",
"version": "0.1.0",
"description": "n8n community node for MyService",
"license": "MIT",
"homepage": "https://github.com/myorg/n8n-nodes-myservice",
"repository": {
"type": "git",
"url": "git+https://github.com/myorg/n8n-nodes-myservice.git"
},
"keywords": [
"n8n-community-node-package"
],
"files": [
"dist"
],
"n8n": {
"n8nNodesApiVersion": 1,
"credentials": [
"dist/credentials/MyServiceApi.credentials.js"
],
"nodes": [
"dist/nodes/MyService/MyService.node.js"
]
}
}Если репозиторий и package.json живут вразнобой, Creator Portal или предчек быстро это заметят. Я после каждого крупного изменения открываю карточку пакета как обычный пользователь и смотрю: видно ли README, понятна ли цель узла, совпадает ли репо.
Какой GitHub Actions workflow я считаю рабочей базой
Если создаёшь новый узел через n8n-node, часть работы уже прилетит из коробки. Для существующих пакетов я бы просто взял за основу свежий publish.yml из starter-репозитория n8n и не выдумывал велосипед. Там уже заложена логика публикации по тегу, нужные permissions и нормальный путь к provenance.
Базовая идея такая:
name: Publish
on:
push:
tags:
- '*.*.*'
jobs:
publish:
runs-on: ubuntu-latest
permissions:
id-token: write
contents: read
steps:
- uses: actions/checkout@v4
- name: Set up Node.js
uses: actions/setup-node@v4
with:
node-version: 'lts/*'
cache: 'npm'
- name: Install dependencies
run: npm ci
- name: Release
run: |
[ -n "$NPM_TOKEN" ] && npm config set //registry.npmjs.org/:_authToken "$NPM_TOKEN"
npm run release
env:
NPM_TOKEN: ${{ secrets.NPM_TOKEN }}Тут есть несколько моментов, которые я всегда подчёркиваю команде. id-token: write нужен не для красоты — без него provenance не взлетит как надо. Имя файла publish.yml тоже важно, потому что именно его ты указываешь в trusted publisher на стороне npm. И да, для старых проектов надо проверить версию @n8n/node-cli: если она древняя, релизный шаг может развалиться именно на публикации с provenance.
Я почти всегда выбираю trusted publishing, а не долгоживущий токен: меньше ручного секрета в репозитории и меньше возни с ротацией. Фолбэк с NPM_TOKEN оставляю как запасной план.
Ещё совет из практики: не пытайся одновременно чинить релизную схему и архитектуру больших workflow. Сначала доведи публикацию до скучного состояния. А уже потом иди в оптимизацию, тестовые ветки и разнос сценария на части. Если работаешь с крупными сборками, у меня есть отдельные заметки про pinned data и mock-сценарии, а ещё про разнос сценария на модули. Они хорошо экономят нервы, когда узел уже встроен в большой боевой процесс.
Чек-лист перед отправкой в Creator Portal
Перед submit я буквально прохожусь по короткому списку. Не в голове, а глазами. Это дисциплина, которая реально спасает.
| Проверка | Что именно смотрю |
| Имя пакета | Формат n8n-nodes-* или @scope/n8n-nodes-* |
| Репозиторий | Публичный, живой, совпадает с package.json |
| README | Есть описание, авторизация, пример, ограничения |
| Лицензия | MIT |
| Ключевое слово | Есть n8n-community-node-package |
| Проверка пакета | Линтер и сканер проходят нормально |
| Публикация | Релиз ушёл через GitHub Actions, а не руками |
| Provenance | На npm видно, что пакет опубликован с происхождением |
| Язык | UI и документация узла на English |
Из команд я обычно гоняю такие штуки:
npm run lint
npm run build
npm run dev
npx @n8n/scan-community-package n8n-nodes-myserviceВот этот последний скан люди часто пропускают, а потом удивляются, почему предчек выкатил список мелких проблем. Я бы не отправлял пакет в Creator Portal, пока локально не вижу чистый результат по линтеру, сборке и скану.
Отдельно проверяю обновления n8n. Если ты тестировал узел давно и потом дотягивал релиз, полезно быстро пробежаться по теме breaking changes в n8n. Иногда косяк уже не в твоём узле, а в том, что вокруг него поменялась среда.
Где чаще всего всё сыпется
Теперь к местам, где всё вроде красиво, а потом начинается возня.
1. Репозиторий не совпадает с карточкой пакета
Очень частая штука. Пакет уже переехал, репо переименовали, scope сменили, а в repository.url остался старый путь. Для provenance и проверок это плохой сигнал. Я после переезда всегда сверяю URL руками.
2. Старый node-cli
Если проект древний, обнови @n8n/node-cli заранее. Иначе можно полдня искать «загадочную» проблему, а причина банальная: старый релизный набор не умеет корректно пройти новый publish-процесс.
3. Scoped-пакет опубликовали не как public
Это классика. Особенно когда всё делается поздно вечером и на автопилоте. В итоге workflow честно отработал, а пакет не вышел туда, куда ты ожидал.
4. Trusted publisher настроен не на тот workflow
На npm нужно указывать именно файл publish.yml, а не красивое имя workflow из интерфейса GitHub. Я видел, как на этой мелочи сливается много времени просто потому, что визуально всё «как будто правильно».
5. README слабый или полупустой
Рабочий код сам по себе не объясняет, как авторизоваться, какие операции поддерживаются и что делать с ошибками API. Для verified review это уже не мелочь. README должен разговаривать с человеком, который впервые увидел твой узел.
6. Узел тащит лишнюю экзотику
Когда автор начинает собирать небольшой node как мини-фреймворк, review превращается в головную боль. Я стараюсь держать community node лёгким и понятным: минимум лишних слоёв, минимум лишних зависимостей, максимум прозрачности.
Мой практический совет: сначала добейся чистого первого релиза, потом уже наращивай фишки. Не пытайся одновременно дожать новую операцию, переделать UI, переписать креды и внедрить релизный конвейер. Такое комбо почти всегда плодит шум.
Финальный вывод
Если собрать всё в одну мысль, то community node для n8n в 2026 публикуется так: стартуешь от n8n-node, держишь пакет и репозиторий в порядке, подключаешь GitHub Actions, настраиваешь trusted publishing в npm, выпускаешь релиз тегом и убеждаешься, что provenance на месте. После этого отправка в Creator Portal уже выглядит как нормальный завершающий шаг, а не как попытка угадать требования наощупь.
Я бы именно так и строил процесс с первого дня. Это чуть дольше на старте, зато потом релизы выходят ровно, проверки проходят спокойнее, а сам пакет выглядит как взрослый продукт, которому не стыдно жить в экосистеме n8n.