n8n_runners_auth_tokenの設定で詰まったら読む完全ガイド【外部タスクランナー接続を徹底解説】
n8nのタスクランナーを外部モードで動かそうとして、「認証エラーが出る」「ランナーが接続できない」「404が返ってくる」といった壁にぶつかったことはないだろうか。その問題のほとんどは、N8N_RUNNERS_AUTH_TOKENの設定ミスや、トークンの不一致が原因だ。このページでは、公式ドキュメントやGitHubのIssue、コミュニティフォーラムで実際に議論されている情報を徹底的に調査し、設定手順からエラー対処まで一気通貫で解説する。
「とりあえず動かしたい」という初心者から「セキュリティをしっかり固めたい」という上級者まで、どちらにも役立つ情報を網羅した。docker-compose.ymlの書き方、GCPやCloud Runでの注意点、n8n v2.0への対応方法、さらに_FILEサフィックスの既知バグまで、ここを読めば一通りの疑問が解消できるように構成している。
| この記事のポイント |
|---|
| ✅ N8N_RUNNERS_AUTH_TOKENが何のためにあるトークンかわかる |
| ✅ 内部モード・外部モードの違いと使い分けがわかる |
| ✅ docker-composeの正しい書き方とトークン生成方法がわかる |
| ✅ 接続エラー・404・タイムアウトの原因と解決策がわかる |
N8N_RUNNERS_AUTH_TOKENの基本知識と設定の仕組み

- N8N_RUNNERS_AUTH_TOKENとは認証トークンのこと
- 内部モードと外部モードの違いはトークンが必須かどうか
- N8N_RUNNERS_AUTH_TOKEN_FILEがRunnerイメージで使えない既知の制限
- トークン生成の方法はopenssl rand -hex 32が最短
- N8N_RUNNERS_AUTH_TOKEN=your-secret-hereの書き方と設定場所
- 設定時に発生しがちなエラーとその原因
N8N_RUNNERS_AUTH_TOKENとは認証トークンのこと

N8N_RUNNERS_AUTH_TOKENは、n8nのメインインスタンスとタスクランナーの間で通信を行う際に使う「共有シークレット(共有秘密鍵)」のことだ。外部モードでタスクランナーを動かす場合、このトークンがなければランナーはブローカーに接続できず、認証エラーで弾かれてしまう。
n8nのCodeノードは、JavaScriptやPythonのコードを実行する機能を持つ。このコード実行を安全かつ高パフォーマンスに行うための仕組みがタスクランナーだ。タスクランナーはメインインスタンスとは別プロセス(または別コンテナ)で動作し、コード実行を隔離することでセキュリティリスクを最小化する。
「N8N_RUNNERS_AUTH_TOKEN:タスクランナーがn8nに認証するために使う共有シークレット。外部モード使用時に必須。」
(引用元:https://docs.n8n.io/hosting/configuration/environment-variables/task-runners/)
🔑 トークンの役割をまとめると次のとおりだ:
| 項目 | 内容 |
|---|---|
| 用途 | タスクランナーがブローカー(n8nメインインスタンス)に接続する際の認証 |
| 設定先 | n8nメインインスタンス側・タスクランナー側の両方 |
| 必須条件 | 外部モード(external)使用時は必須 |
| デフォルト値 | ランダム文字列(内部モード時は自動生成) |
| 型 | 文字列型(String) |
内部モード(N8N_RUNNERS_MODE=internal)では、n8nが子プロセスとしてランナーを自動起動するため、このトークンはn8nが内部的に自動生成して使い回す。そのため、ユーザーが意識して設定する必要はない。一方、外部モード(external)では外部のオーケストレーター(DockerやKubernetesなど)がランナーを起動するため、メインインスタンスとランナーの両方に同じトークンを手動で設定しなければならない。
このトークンが1文字でも違っていたり、片方にしか設定されていなかったりすると、認証に失敗してランナーが接続できなくなる。「ステータスコード403のエラーでランナーが接続できない」という報告がコミュニティに多数上がっているが、その大半はこのトークンの不一致が原因だ。
内部モードと外部モードの違いはトークンが必須かどうか

n8nのタスクランナーには2つの動作モードがある。どちらを選ぶかによって、N8N_RUNNERS_AUTH_TOKENの扱い方も変わってくる。
📊 内部モードと外部モードの比較
| 比較項目 | 内部モード(internal) | 外部モード(external) |
|---|---|---|
N8N_RUNNERS_MODE |
internal(デフォルト) |
external |
| ランナーの起動方法 | n8nが子プロセスとして起動 | 外部オーケストレーターが起動 |
| AUTH_TOKEN | 自動生成(設定不要) | 必須(手動設定) |
| 追加コンテナ | 不要 | 必要(ランナー用コンテナ) |
| Pythonコードノード | 非対応 | 対応(必須) |
| セキュリティ分離 | 中程度 | 高い |
| 設定の複雑さ | 簡単 | やや複雑 |
内部モードは設定が最もシンプルだ。N8N_RUNNERS_ENABLED=trueを1行追加するだけで動き始める。ただしPythonのCodeノードを使いたい場合は、外部モードが必須となる。n8n v2.0以降では、Pyodide(ブラウザベースのPython)が廃止され、ネイティブPythonのみが対象となっており、その実行には外部タスクランナーが必要だ。
✅ モード選択の判断フロー:
- PythonのCodeノードを使う → 外部モード一択
- セキュリティを最大限高めたい → 外部モードを推奨
- シンプルに動かしたい、JSコードのみ → 内部モードで十分
外部モードを選んだ場合は、openssl rand -hex 32などでランダムなトークンを生成し、メインインスタンスのN8N_RUNNERS_AUTH_TOKENとランナー側のN8N_RUNNERS_AUTH_TOKENにまったく同じ値をセットする必要がある。この「同じ値」という部分が見落とされやすいポイントだ。
N8N_RUNNERS_AUTH_TOKEN_FILEがRunnerイメージで使えない既知の制限

DockerやKubernetesのシークレット管理では、機密情報をファイルとして渡す_FILEサフィックスが広く使われている。n8nのメインイメージ(n8nio/n8n)ではこの仕組みをサポートしており、N8N_RUNNERS_AUTH_TOKEN_FILE=/run/secrets/auth_tokenのように書ける。
しかし、ランナーイメージ(n8nio/runners)ではこの_FILEサフィックスが現時点でサポートされていないという重要な制限がある。
「
N8N_RUNNERS_AUTH_TOKEN_FILE環境変数(_FILEサフィックスに注目)を使うと、次のエラーが発生する:ERROR Failed to load config: AuthToken: missing required value: N8N_RUNNERS_AUTH_TOKEN」
(引用元:https://github.com/n8n-io/n8n/issues/23709)
📋 _FILEサポート状況の比較
| イメージ | N8N_RUNNERS_AUTH_TOKEN_FILE |
備考 |
|---|---|---|
n8nio/n8n(メイン) |
✅ サポートあり | シークレットファイルから読み込める |
n8nio/runners(ランナー) |
❌ 非サポート(既知バグ) | 直接値を指定する必要あり |
この問題はGitHubのIssue #23709として報告されており、現在も対応中の状態だ。コミュニティからは「メインイメージで_FILEをサポートしているのに、ランナーイメージでサポートしていないのは矛盾している」という声が上がっている。
コミュニティフォーラムでも同様のフィーチャーリクエストが上がっており(https://community.n8n.io/t/support-n8n-runners-auth-token-file-in-n8nio-runners/242849)、将来的には対応される可能性が高いと思われる。ただし、2026年5月現在ではN8N_RUNNERS_AUTH_TOKENに直接値を記載する方法が唯一の確実な手段だ。
task-runner-launcherの公式ドキュメント(https://github.com/n8n-io/task-runner-launcher/blob/main/docs/setup.md)によれば、launcherバイナリを使う構成では_FILEサフィックスがサポートされているとの記載がある。n8nio/runnersイメージとlauncherバイナリとでは挙動が異なる点に注意が必要だ。
トークン生成の方法はopenssl rand -hex 32が最短

N8N_RUNNERS_AUTH_TOKENに設定する値は、推測されにくいランダムな文字列であることが重要だ。適当な固定文字列を使い回すのはセキュリティ上NGで、本番環境では必ず専用のランダムトークンを生成して使うべきだ。
🛠️ トークン生成コマンド一覧
| コマンド | 出力例 | 備考 |
|---|---|---|
openssl rand -hex 32 |
a3f2c1...(64文字の16進数) |
最も一般的、推奨 |
openssl rand -base64 24 |
8xK2mP...(32文字程度) |
Base64形式 |
python3 -c "import secrets; print(secrets.token_hex(32))" |
64文字の16進数 | Python環境があるなら使える |
最も広く使われているのはopenssl rand -hex 32だ。これで生成した64文字のランダム文字列をそのまま.envファイルや環境変数に設定する。
# .envファイルの例
N8N_RUNNERS_AUTH_TOKEN=a3f2c1d4e5b6a7c8d9e0f1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2
生成したトークンはメインインスタンス側とランナー側で必ず同じ値を使うこと。これが一番大事なポイントだ。異なる値を設定してしまうと、ランナーはブローカーに接続できず認証エラーになる。
.envファイルを使う場合は、そのファイルへのアクセス権限も適切に設定しよう。chmod 600 .envでオーナーのみが読み書きできる状態にしておくと安全だ。
N8N_RUNNERS_AUTH_TOKEN=your-secret-hereの書き方と設定場所

実際にdocker-compose.ymlを書くとき、N8N_RUNNERS_AUTH_TOKENをどこにどう書けばいいか迷う人は多い。ここでは最小構成の設定例を示す。
📄 docker-compose.yml基本設定例
services:
n8n:
image: n8nio/n8n:latest
environment:
# タスクランナーを有効化
- N8N_RUNNERS_ENABLED=true
# 外部モードを指定
- N8N_RUNNERS_MODE=external
# 外部ランナーからの接続を受け付けるために0.0.0.0を指定
- N8N_RUNNERS_BROKER_LISTEN_ADDRESS=0.0.0.0
# ブローカーのポート番号
- N8N_RUNNERS_BROKER_PORT=5679
# 認証トークン(ランナー側と同じ値を使う)
- N8N_RUNNERS_AUTH_TOKEN=${N8N_RUNNERS_AUTH_TOKEN}
n8n-runner:
image: n8nio/runners:latest
environment:
# ブローカーのアドレス(n8nコンテナ名:ポート番号)
- N8N_RUNNERS_TASK_BROKER_URI=http://n8n:5679
# 認証トークン(n8n側と同じ値を使う)
- N8N_RUNNERS_AUTH_TOKEN=${N8N_RUNNERS_AUTH_TOKEN}
depends_on:
- n8n
✅ 設定のチェックポイント:
N8N_RUNNERS_ENABLED=trueがn8n側にあるN8N_RUNNERS_MODE=externalがn8n側にあるN8N_RUNNERS_BROKER_LISTEN_ADDRESS=0.0.0.0がn8n側にある(これがないと外部からランナーが接続できない)N8N_RUNNERS_AUTH_TOKENがn8n側とランナー側で完全一致しているN8N_RUNNERS_TASK_BROKER_URIがランナー側に設定されている
.envファイルを使う場合は${N8N_RUNNERS_AUTH_TOKEN}のように変数参照を使うのが定石だ。直接値を書き込む場合はN8N_RUNNERS_AUTH_TOKEN=your-actual-token-hereのようにイコールの後ろに値を続ける。
設定時に発生しがちなエラーとその原因

N8N_RUNNERS_AUTH_TOKEN周りで発生するエラーには、いくつかの典型的なパターンがある。
🚨 よくあるエラーと原因・対処法
| エラーメッセージ / 症状 | 原因 | 対処法 |
|---|---|---|
Task runner connection attempt failed with status code 403 |
トークンが不一致または未設定 | 両側で同じトークンを設定する |
key not found, generating a new key... |
_FILEサフィックスがRunnerイメージで未サポート |
_FILEを使わず直接値を設定 |
| n8nが起動後に全ルートが404を返す | AUTH_TOKENが未設定のまま外部モードを有効化 | トークンを設定して再起動 |
| JSコードノードがずっとローディングのまま | ランナーとブローカーの通信失敗 | URIとポート設定を確認 |
Task request timed out after 60 seconds |
ネットワーク経路の問題 | ファイアウォール・ポート5679の疎通確認 |
特に「n8nが起動したのにすべてのルートが404を返す」という問題は、GCPのCloud Runユーザーから多く報告されている。これはN8N_RUNNERS_ENABLED=trueとN8N_RUNNERS_MODE=externalを設定したにもかかわらず、N8N_RUNNERS_AUTH_TOKENが未設定だった場合に起きる。n8nはブートストラップ時にルートを登録する前に失敗してしまうため、HTTPサーバー自体は動いているのに全てのAPIが404になるという状況が発生する。
解決策はシンプルで、認証トークンを正しく設定してコンテナを再起動するだけだ。コミュニティの報告によれば、この1点を修正するだけで404問題が解消されたケースが多数ある。
N8N_RUNNERS_AUTH_TOKENを活用した外部タスクランナーの実践設定

- docker-composeでの基本構成はmain側とrunner側で同じ値を使うこと
- GCPやCloud Runでのタスクランナー接続でありがちな404問題の解決策
- N8N_RUNNERS_BROKER_LISTEN_ADDRESSを0.0.0.0にする理由
- Docker Swarm・PortainerでのN8N_RUNNERS_AUTH_TOKEN_FILE問題への対処
- セキュリティを高めるBlast Radius設計のすすめ
- n8n v2.0でのタスクランナー必須化とマイグレーションのポイント
- 総括:N8N_RUNNERS_AUTH_TOKENのまとめ
docker-composeでの基本構成はmain側とrunner側で同じ値を使うこと

実際の本番環境でよく使われるのは、n8nコンテナとランナーコンテナを同一のdocker-compose.ymlで管理するパターンだ。ここではPostgresを使う本格的な構成例を示す。
📄 本番向けdocker-compose.yml構成例
version: "3.8"
services:
postgres:
image: postgres:15
environment:
- POSTGRES_USER=n8n
- POSTGRES_PASSWORD=${DB_PASSWORD}
- POSTGRES_DB=n8n
volumes:
- postgres_data:/var/lib/postgresql/data
n8n:
image: n8nio/n8n:latest
ports:
- "5678:5678"
environment:
- N8N_HOST=your-domain.com
- N8N_PORT=5678
- N8N_PROTOCOL=https
- WEBHOOK_URL=https://your-domain.com/
- DB_TYPE=postgresdb
- DB_POSTGRESDB_HOST=postgres
- DB_POSTGRESDB_PORT=5432
- DB_POSTGRESDB_DATABASE=n8n
- DB_POSTGRESDB_USER=n8n
- DB_POSTGRESDB_PASSWORD=${DB_PASSWORD}
# タスクランナー設定
- N8N_RUNNERS_ENABLED=true
- N8N_RUNNERS_MODE=external
- N8N_RUNNERS_BROKER_LISTEN_ADDRESS=0.0.0.0
- N8N_RUNNERS_BROKER_PORT=5679
- N8N_RUNNERS_AUTH_TOKEN=${N8N_RUNNERS_AUTH_TOKEN}
volumes:
- n8n_data:/home/node/.n8n
depends_on:
- postgres
n8n-runner:
image: n8nio/runners:latest
environment:
- N8N_RUNNERS_TASK_BROKER_URI=http://n8n:5679
- N8N_RUNNERS_AUTH_TOKEN=${N8N_RUNNERS_AUTH_TOKEN}
depends_on:
- n8n
volumes:
postgres_data:
n8n_data:
🗂️ .envファイルの中身
N8N_RUNNERS_AUTH_TOKEN=ここにopensslで生成したトークンを入れる
DB_PASSWORD=ここにDBパスワードを入れる
この構成で重要なのは、${N8N_RUNNERS_AUTH_TOKEN}という変数参照を使っている点だ。同じ変数を両方のサービスで参照することで、常に同じ値が入ることが保証される。.envファイル内の値を変更すれば、両方のコンテナに自動的に同じ新しいトークンが適用されるため、メンテナンスが楽になる。
起動後はdocker-compose logs n8n-runnerでランナーのログを確認しよう。ブローカーへの接続が成功すれば、接続完了を示すログが表示されるはずだ。
GCPやCloud Runでのタスクランナー接続でありがちな404問題の解決策

GCP(Google Cloud Platform)のCloud Runでn8nを動かしている場合、タスクランナーの設定には特有の難しさがある。Cloud Runはデフォルトでポート5678しか外部に公開しないため、タスクブローカーが使うポート5679をランナーから直接叩くことができない。
コミュニティで報告されている事例によると、Cloud RunでN8N_RUNNERS_AUTH_TOKENを含む外部モードの設定を行った直後に、全てのエンドポイントが404を返すようになったという問題が複数発生している。
「N8N_RUNNERS_ENABLED=trueとN8N_RUNNERS_MODE=externalを設定したところ、n8nはHTTPサーバーを起動するがルートを登録せず、外部からは全て404が返るようになった。」
(引用元:https://community.n8n.io/t/task-runners-in-gcp/259823)
📋 Cloud Run特有の問題と対策
| 問題 | 原因 | 対策 |
|---|---|---|
| 全ルートが404を返す | AUTH_TOKENが未設定のまま外部モードを有効化 | トークンを正しく設定して再デプロイ |
| ランナーがブローカーに接続できない | port 5679がCloud Runから到達不可 | サイドカーパターンでlocalhostで接続 |
| タスクリクエストが60秒でタイムアウト | ランナーとブローカーの通信失敗 | 内部ネットワーク経由に変更 |
Cloud Runで外部タスクランナーを使う場合に有効な解決策の一つがサイドカーパターンだ。メインインスタンスと同じCloud Runサービスにランナーをサイドカーとして配置することで、localhost:5679経由でブローカーに接続できる。コミュニティの実例では、mainインスタンスとworkerインスタンスの両方にサイドカーとしてランナーを追加することで動作したという報告がある。
また、Cloud RunではRequest ModeではなくInstance Modeに変更することで解決したというケースも報告されている。Cloud Runの動作モードがランナーの接続に影響することがあるため、設定を見直す価値がある。
N8N_RUNNERS_BROKER_LISTEN_ADDRESSを0.0.0.0にする理由

外部モードで設定する際に見落とされがちなのがN8N_RUNNERS_BROKER_LISTEN_ADDRESSの設定だ。デフォルト値は127.0.0.1(ループバックアドレス)で、これはローカルからの接続しか受け付けないことを意味する。
🌐 アドレス設定と接続可能範囲の比較
| 設定値 | 意味 | 外部コンテナからの接続 |
|---|---|---|
127.0.0.1(デフォルト) |
ローカルのみ受け付け | ❌ 不可 |
0.0.0.0 |
全インターフェースで受け付け | ✅ 可能 |
外部コンテナ(n8n-runner)からブローカー(n8nメインインスタンスのポート5679)に接続するためには、n8nメインインスタンス側でN8N_RUNNERS_BROKER_LISTEN_ADDRESS=0.0.0.0を設定する必要がある。これを設定していないと、ランナーコンテナからブローカーへの接続が拒否され、Codeノードがタイムアウトするまで「ローディング中」のまま固まってしまう。
「ランナーが起動してもCodeノードを実行するとずっとローディングが続く」という問題は、ほとんどの場合このBROKER_LISTEN_ADDRESSの設定漏れが原因だ。
(参考:https://community.n8n.io/t/task-runners-in-gcp/259823)
✅ 外部モードのn8n側に必要な最低限の設定まとめ:
N8N_RUNNERS_ENABLED=true
N8N_RUNNERS_MODE=external
N8N_RUNNERS_BROKER_LISTEN_ADDRESS=0.0.0.0 ← これを忘れずに
N8N_RUNNERS_BROKER_PORT=5679
N8N_RUNNERS_AUTH_TOKEN=your-secret-token
ファイアウォールやセキュリティグループの設定も忘れずに。コンテナ間のポート5679への通信が許可されていないと、0.0.0.0でリッスンしていても繋がらない。Docker Composeの場合は同一のdockerネットワークに属していれば基本的に問題ないが、swarmモードや別のネットワークに分かれている場合は注意が必要だ。
Docker Swarm・PortainerでのN8N_RUNNERS_AUTH_TOKEN_FILE問題への対処

Docker SwarmやPortainerを使っている場合、シークレット管理には_FILEサフィックスを使うのが一般的な慣習だ。しかし前述のとおり、n8nio/runnersイメージはこの_FILEサフィックスをサポートしていない。
コミュニティでは実際にこの問題にぶつかった事例が共有されている:
「シークレットでN8N_RUNNERS_AUTH_TOKEN_FILEを定義しているにもかかわらず、ログには『key not found, generating a new key』と表示される。」
(引用元:https://community.n8n.io/t/compose-file-for-running-task-runner/214690)
📋 Docker SwarmでのWorkaround(回避策)
| アプローチ | 説明 | メリット / デメリット |
|---|---|---|
| 直接値を環境変数に設定 | N8N_RUNNERS_AUTH_TOKEN=値 を環境変数に直接書く |
簡単だがセキュリティ的にベストでない |
| Swarm Secretsを使ってenvに展開 | entrypoint スクリプトでSecret読み込み後に環境変数にセット | やや複雑だが安全性は高い |
| task-runner-launcherバイナリを使用 | ランナーイメージではなくlauncherを使う(_FILE対応あり) |
設定が複雑になる |
現時点での最も現実的な回避策は、n8nメインイメージ(n8nio/n8n)側は_FILEを使い、ランナー側(n8nio/runners)は直接値を環境変数に設定するという方法だ。Swarm Secretsを使う場合は、PortainerのUIでサービスのシークレットとして登録し、ランナーサービスの環境変数には値を直接書く形になる。
将来的にこの制限が解消されることが期待されるが、現時点では上記の回避策を取るしかない。GitHubのIssueをウォッチしておくと、修正が入ったタイミングで気づける。
セキュリティを高めるBlast Radius設計のすすめ

タスクランナーアーキテクチャの本質的な目的は、コード実行の爆発半径(Blast Radius)を最小化することだ。メインインスタンスでコードを直接実行すると、悪意あるコードや暴走したスクリプトがn8n全体の権限でOSにアクセスできてしまう。
「これをタスクランナーアーキテクチャで解決する。コード実行をオーケストレーターから切り離すことで、スクリプトがクラッシュしてもランナーが死ぬだけで済む。」
(引用元:https://medium.com/@abhishekaryan2/n8n-task-runners-the-blast-radius-protocol-1b8388364597)
🛡️ セキュリティ強化のための設定一覧
| 設定 | 値 | 効果 |
|---|---|---|
N8N_BLOCK_ENV_ACCESS_IN_NODE |
true |
Codeノードからの環境変数アクセスを遮断 |
N8N_RUNNERS_INSECURE_MODE |
false(デフォルト) |
タスクランナーのセキュリティ機能を有効に保つ |
N8N_RUNNERS_ALLOW_PROTOTYPE_MUTATION |
false(デフォルト) |
プロトタイプ汚染攻撃を防ぐ |
N8N_BLOCK_RUNNER_ENV_ACCESS |
true(デフォルト) |
Pythonコードから環境変数へのアクセスを遮断 |
allowed-env(config file) |
必要なものだけリスト | ランナーが参照できる環境変数を明示的に制限 |
Dockerfileでカスタムランナーイメージを作る場合は、n8n-task-runners.jsonのallowed-envセクションで許可する環境変数を明示的にリスト化するのがベストプラクティスだ。これにより、ランナーが不必要な環境変数(APIキーや認証情報など)を参照できないようにできる。
ただし、タスクランナーによる隔離はあくまでコード実行レベルの分離であり、n8nエンジン自体の脆弱性を防ぐものではない点に注意が必要だ。n8nのメインイメージは常に最新版に更新しておくことが重要だ。
n8n v2.0でのタスクランナー必須化とマイグレーションのポイント

n8n v2.0(2025年12月ベータ、12月15日安定版リリース)は、セキュリティ面で大きな変更が加えられたバージョンだ。タスクランナー周りの変更点は特に重要で、既存の設定が動かなくなるケースがある。
📅 v2.0の主要な変更点(タスクランナー関連)
| 変更内容 | v1.x の挙動 | v2.0 の挙動 |
|---|---|---|
| タスクランナーの使用 | オプション | 全Codeノードで必須 |
| Pythonの実装 | Pyodide(ブラウザベース) | ネイティブPython(外部モード必須) |
N8N_BLOCK_ENV_ACCESS_IN_NODE |
デフォルトfalse |
デフォルトtrue |
| ExecuteCommandノード | 有効 | デフォルト無効 |
v2.0ではPythonのCodeノードが完全に書き直された。従来のPyodideベースの実装が廃止され、ネイティブPythonのみになった。これに伴い、PythonのCodeノードを使う場合は外部タスクランナーが必須となった。_input変数やドット記法アクセスも廃止されているため、既存のPythonコードの見直しが必要だ。
✅ v2.0へのマイグレーションチェックリスト(外部モード使用の場合):
- [ ]
openssl rand -hex 32でトークンを生成 - [ ]
.envにN8N_RUNNERS_AUTH_TOKEN=生成したトークンを追加 - [ ] n8nサービスに外部モード関連の環境変数を追加
- [ ] ランナーサービスを追加(
n8nio/runners:latest) - [ ] 既存のPythonコードノードを確認(
_input変数・ドット記法の書き換え) - [ ] OAuth連携のテスト(
N8N_SKIP_AUTH_ON_OAUTH_CALLBACKのデフォルト変更) - [ ] ファイル操作ノードのパス確認(サンドボックス化による制限)
- [ ] ステージング環境での全体テスト
v2.0はセキュリティが大幅に強化されており、長期的には安定した基盤になると考えられる。ただし移行には相応の確認作業が必要なため、本番環境への適用前に必ずステージング環境でテストすることを強く推奨する。
総括:N8N_RUNNERS_AUTH_TOKENのまとめ

最後に記事のポイントをまとめます。
- N8N_RUNNERS_AUTH_TOKENはタスクランナーがn8nブローカーに接続する際の「共有認証トークン」である
- 外部モード(
N8N_RUNNERS_MODE=external)使用時はこのトークンの設定が必須であり、省略するとエラーになる - 内部モードではトークンはn8nが自動生成するためユーザーが設定する必要はない
- トークンはメインインスタンス側とランナー側で完全に同じ値を設定しなければならない
- トークンの生成には
openssl rand -hex 32コマンドを使うのが最も一般的で推奨される方法である n8nio/runnersイメージは現時点でN8N_RUNNERS_AUTH_TOKEN_FILE(_FILEサフィックス)をサポートしていないため、直接値を設定する必要がある- 外部ランナーコンテナから接続を受け付けるために、n8n側で
N8N_RUNNERS_BROKER_LISTEN_ADDRESS=0.0.0.0の設定が必要である - 全ルートが404を返す問題は、AUTH_TOKENが未設定のまま外部モードを有効化したことが原因であるケースが多い
- GCPのCloud RunなどCloud Run環境では、ポート5679の公開制限によりサイドカーパターンの採用が有効な解決策となる
- n8n v2.0ではタスクランナーが全Codeノードで必須化されており、PythonのCodeノードは外部モードが必須である
- セキュリティ強化のため
N8N_BLOCK_ENV_ACCESS_IN_NODE=trueやallowed-envの適切な設定を組み合わせることが推奨される N8N_RUNNERS_AUTH_TOKENの設定は.envファイルで変数参照することで、メインとランナーの両サービスに同じ値を一元管理できる
記事作成にあたり参考にさせて頂いたサイト
- https://docs.n8n.io/hosting/configuration/environment-variables/task-runners/
- https://community.n8n.io/t/compose-file-for-running-task-runner/214690
- https://github.com/n8n-io/n8n/issues/23709
- https://community.n8n.io/t/task-runners-in-gcp/259823
- https://www.reddit.com/r/n8n/comments/1qmzlvn/using_python_on_selfhosted_n8n/
- https://community.n8n.io/t/support-n8n-runners-auth-token-file-in-n8nio-runners/242849
- https://github.com/n8n-io/task-runner-launcher/blob/main/docs/setup.md
- https://railway.com/deploy/n8n-task-runner-only
- https://medium.com/@abhishekaryan2/n8n-task-runners-the-blast-radius-protocol-1b8388364597
- https://www.idir.ai/en/blog/n8n-v20-breaking-changes-you-need-to-know-before-december
各サイト運営者様へ
有益な情報をご公開いただき、誠にありがとうございます。
感謝の意を込め、このリンクはSEO効果がある形で設置させていただいております。
※リンクには nofollow 属性を付与しておりませんので、一定のSEO効果が見込まれるなど、サイト運営者様にとってもメリットとなれば幸いです。
当サイトは、インターネット上に散在する有益な情報を収集し、要約・編集してわかりやすくお届けすることを目的としたメディアです。
引用や参照の方法に不備、あるいはご不快に感じられる点がございましたら、お問い合わせフォームよりご連絡ください。
今後とも、どうぞよろしくお願いいたします。

