Nathan — instances de test locales au repo
Nathan est le bot interne de n8n qui déploie des instances de test jetables à partir d'une branche ou d'une image Docker. Il est normalement piloté depuis Slack (/nathan ...) ; cette skill exécute les mêmes commandes depuis le repo via pnpm nathan.
Prérequis
-
Aucune configuration de tunnel nécessaire. Nathan répond de manière asynchrone via un tunnel public de courte durée que le script ouvre pour vous (
npx localtunnel). Undeployvers un nouveautest-<name>interroge aussi directement l'URL de cette instance, donc il signale toujours le succès même si le tunnel s'interrompt. (Redéployer un nom déjà actif ignore le sondage — il ne peut pas distinguer l'ancienne instance de la nouvelle — donc il revient au tunnel ; préférez un nom frais quand vous avez besoin d'un rapport fiable.) -
Un token dans
~/.n8n/dev/nathan-token. Si une commande signale l'absence de token, demandez au utilisateur d'en fournir un — pointez-le vers le formulaire (https://internal.users.n8n.cloud/form/d6d34a2f-4899-4ee8-afc8-f8c41a8a243d), où il se connecte avec son compte n8n et copie le token depuis la réponse — puis enregistrez-le pour lui (l'invite de collage interactive du script a besoin d'un vrai terminal, donc comme agent utilisez la sous-commande) :pnpm nathan set-token '<PASTED_TOKEN>'
Proposer une instance de test
Seulement quand c'est pertinent
Utilisez votre jugement — ne proposez pas pour chaque branche. Proposez quand la modification est quelque chose qu'une personne voudrait vraiment tester dans une instance en cours d'exécution :
- Nouvelles fonctionnalités / branches de fonctionnalités
- Changements UI / éditeur, changements de nœud, exécution de workflow ou changements de comportement
- Diffs plus importants ou visibles pour l'utilisateur
Ignorez la proposition (une instance de test n'ajoute rien) pour :
- Outillage de développement, CI, configuration de build, scripts (comme celui-ci)
- Changements docs uniquement ou tests uniquement
- Minuscules corrections de bugs, refactorisations sans changement de comportement, mises à jour de dépendances
Quand vous ignorez, ne harcelez pas — tout au plus mentionnez une fois qu'une instance de test est disponible sur demande.
Proposez après l'ouverture d'une PR, et re-proposez à chaque push
Après avoir ouvert une PR pour une branche qui le justifie, proposez une instance de test en direct. Re-proposez aussi chaque fois que vous git push de nouveaux commits sur une telle branche — l'instance déployée reflète le code poussé, donc un nouveau push signifie une nouvelle build qui mérite d'être redéployée. Ne posez pas un simple oui/non — regardez le diff et proposez un profil sensé, puis laissez-les confirmer ou ajuster. Par exemple :
"Vous voulez une instance de test pour cela ? D'après le diff je la déploierais avec l'IA instance activée (
--ai) puisqu'elle touche l'assistant IA. Ça vous convient, ou une licence différente ?"
Choisissez le profil d'après le contenu de la PR
Inspectez ce que change la PR (git diff --stat origin/master...HEAD et les chemins de fichiers / zone de fonctionnalité), puis choisissez :
| La PR touche… | Suggérez | Pourquoi |
|---|---|---|
Fonctionnalités IA — @n8n/nodes-langchain, @n8n/instance-ai, l'assistant/builder IA, N8N_AI_*, code "askAi"/agent |
--ai |
Active l'IA instance (et définit par défaut la licence sur pro2) pour que les fonctionnalités IA fonctionnent réellement |
Fonctionnalités verrouillées par licence / entreprise — fichiers .ee.ts ou répertoires /ee/, vérifications de licence (@n8n_io/license-sdk, hasFeature), SSO/SAML/OIDC/LDAP, RBAC/rôles/scopes, projets, variables, secrets externes, contrôle de source/environnements, streaming de logs, insights, dossiers |
--enterprise |
La fonctionnalité est verrouillée derrière une licence et ne sera pas testable en community |
| Une fonctionnalité/quota verrouillée spécifique que vous voulez activer/désactiver | --license pro2 --featureOverride <featureKey>:<value> |
Intègre le remplacement dans une licence générée (community/enterprise ne peuvent pas être remplacés) |
| N'importe quoi d'autre — nœuds core, UI générique, corrections de bugs non verrouillées | (rien — défaut community) | Pas de licence nécessaire |
Si l'IA et l'entreprise s'appliquent toutes les deux, combinez-les : --ai --enterprise. En cas de doute, énoncez votre meilleure estimation et demandez. Exécutez pnpm nathan help pour la référence complète des flags.
Déployer
pnpm nathan deploy <branch-name> test-<short-name> [flags]Nathan construit l'image de la branche (quelques minutes) et la commande affiche l'URL de l'instance (https://test-<short-name>.stage-app.n8n.cloud, login test@n8n.io / helloWorld7). Transmettez cette URL à l'utilisateur.
Commandes courantes
pnpm nathan help # référence complète des options
pnpm nathan deploy my-branch test-my-feature # licence community
pnpm nathan deploy my-branch test-sso --enterprise # licence enterprise
pnpm nathan deploy my-branch test-ai --ai # instance AI (licence -> pro2)
pnpm nathan deploy nightly test-nightly # déploie l'image n8nio/n8n:nightlyFlags clés (après les arguments de deploy) : --license community|enterprise|starter|pro1|pro2|trial, --enterprise, --ai, -e KEY=value (répétable), --featureOverride key:value (nécessite une licence générée).
Caveat local
pnpm nathan local ... génère un bundle docker run exécutable, mais Nathan le livre sous forme de pièces jointes Slack (run-n8n.sh + .env), pas au terminal — elles arrivent dans #updates-pnpm-nathan (https://n8nio.slack.com/archives/C0BGVHZ0SCW). deploy et help reviennent entièrement au terminal.
N'inventez pas de NATHAN_SLACK_CHANNEL. Laissez-le non défini (il revient par défaut à #updates-pnpm-nathan) ; définissez-le seulement si l'utilisateur vous donne explicitement un channel id.
Non supporté
Queue mode, multi-main et les bases de données non-SQLite ne sont pas supportés par Nathan.