n8n GitHubの使い方｜公式リポジトリの見方、GitHub連携とワークフローのGit管理

n8nのGitHub公式リポジトリは「n8n-io/n8n」で、n8nのソースコードはここで誰でも読めます。ただし利用条件はオープンソースではなく、fair-code（Sustainable Use Licenseとn8n Enterprise License）です。自社の業務を自動化するために無料で入れて使えますが、n8nそのものを他社向けのサービスとして売ることはできません。入れ方はDockerが基本で、GitHubとの連携はGitHubノードとGitHub Triggerで組み、ワークフローのGit管理は3つの方法から選びます。

2026年10月16日時点の情報です。手順と機能はn8nの公式ドキュメント（n8n Docs）とGitHubのn8n-io/n8nのページで最新の内容をご確認ください。

この記事の答え

• n8nの公式リポジトリはGitHubのn8n-io/n8nで、利用条件はfair-codeのため、自社の業務の自動化には無料で使えます
• ワークフローをGitで管理する方法は、JSONの書き出し・GitHubノードでのコミット・有償プランのソース管理の3つで、本番と検証を分けたいかで選びます
• まずDockerで手元のPCに起動し、試したワークフローを1本書き出してGitHubに置くところから始めます

n8nのGitHub公式リポジトリはn8n-io/n8n

n8nのソースコードは、GitHubのn8n-io/n8nで公開されています。n8n-ioはn8nを開発している会社のアカウントで、本体のコード、READMEの起動手順、版ごとのリリースの記録がここにまとまっています。

n8nが何をするツールか、どう読むかを先に知りたい場合は、中心の記事で全体像をつかめます。ノードと呼ぶ部品を画面上でつなぎ、ほかのサービスとの間のデータの受け渡しを自動にするツールです。

関連記事：n8nとは？n8nの使い方・読み方・できること・無料の範囲を解説

公式リポジトリとフォークの見分け方

GitHubで「n8n」と検索すると、公式リポジトリのほかに、個人がコピーしたフォークや、ワークフローを集めたリポジトリがたくさん出てきます。入れるときに使うのは、所有者の名前がn8n-ioになっているリポジトリだけにします。

フォークには、リポジトリ名の下に「forked from n8n-io/n8n」と表示されます。ワークフロー集のリポジトリは、n8nの本体ではなく、誰かが作ったワークフローのJSONを並べたものです。起動に使うDockerのイメージも、READMEに書かれたdocker.n8n.io/n8nio/n8nを使い、名前の似た別のイメージを選ばないようにします。

リポジトリのページで確かめられる数字（2026年10月16日に確認）

リポジトリの数字は日々変わるため、確かめた日と一緒に扱います。

スターの数は人気の目安にはなりますが、品質や安全性を保証するものではありません。業務で使うかどうかは、利用条件と、版を上げ続ける体制を組めるかで決めます。

なお、GitHubが提供するGitHub Copilotは、コードを書くときに提案を出すAIの製品で、n8nとは別のものです。名前に同じGitHubが付くため検索で混ざりますが、料金もプランも別に決まっています。

関連記事：GitHub Copilotの料金はいくら？無料・Pro・Business・Enterpriseの月額とAIクレジット

GitHubで公開されていても利用条件はfair-code

n8nのREADMEは、n8nをfair-codeのソフトウェアとして、Sustainable Use Licenseとn8n Enterprise Licenseのもとで配布していると書いています。ソースコードが公開されていることと、どんな使い方でも自由にできることは別です。fair-codeは、ソースコードを公開し、自社のサーバーに入れて使うことも認める一方で、商用での使い方に一部の制限を残す考え方です。

無料で使える範囲と商用利用の線引き

自社の業務を自動化するために社内で使う範囲なら、GitHubから入れた無料版をそのまま使えます。認められていないのは、n8nを自社のサービスとして顧客に提供し、顧客にワークフローを組ませる使い方や、n8nを自社製品として売る使い方です。

プランごとの料金と、商用利用でどこまで許されるかの細かい線引きは、料金の記事で表にしています。顧客向けの製品に組み込む計画があるなら、構築の前にn8nのライセンスのFAQで条件を確かめます。

関連記事：【2026年10月最新】n8n料金プランの比較｜無料の範囲と上限

有償の機能のコードも同じリポジトリにある

公式リポジトリには、無料版の機能と、n8n Enterprise Licenseの対象になる有償の機能のコードが一緒に入っています。有償の機能は、ライセンスキーを入れたときだけ有効になります。GitHubから入れたn8nでも、ライセンスキーが無ければ無料版として動きます。

n8nをGitHubから入れて起動する手順

READMEと公式ドキュメントに載っている始め方は3つあります。どれも、起動したらブラウザでhttp://localhost:5678を開くと、最初の利用者を作る画面が出ます。

Dockerで起動する（READMEの手順）

READMEが最初に示しているのは、Dockerで起動する方法です。データを残す置き場所（ボリューム）を作ってから、n8nのコンテナを起動します。

docker volume create n8n_data
docker run -it --rm --name n8n -p 5678:5678 -v n8n_data:/home/node/.n8n docker.n8n.io/n8nio/n8n

1行目で作ったn8n_dataに、ワークフローと認証情報が保存されます。2行目の --rm でコンテナは止めるたびに消えますが、ボリュームは残るため、もう一度同じコマンドで起動すれば作ったワークフローはそのまま出てきます。

インストールスクリプトで入れる

READMEには、1行で入れるスクリプトも載っています。このスクリプトもDockerを前提にしているため、先にDockerを入れておきます。

curl -fsSL https://get.n8n.io | sh

インターネットから取ったスクリプトをそのまま実行する形なので、社内のPCで使う場合は、情シスの決まりで許されているかを先に確かめます。

npx n8nで試す

Node.jsが入っているPCなら、Dockerを使わずに1行で起動できます。Node.jsの版が古いと起動の途中で止まるため、先に node -v で版を確かめます。

npx n8n

npmでの導入は試用向けで、n8nの3.0からは非推奨になる予定と公式ドキュメントに書かれています。業務で使い続けるなら、最初からDockerで動かしておくと、あとでサーバーへ移すときに手順を変えずに済みます。

本番で動かす前に決めること

手元で試したあと業務で動かすには、Docker Composeでの構成、ドメインとSSL、バックアップを決めてからサーバーに載せます。手元で試したn8nを、そのまま本番として使い続けないようにします。

関連記事：n8nセルフホストの手順｜Docker・Docker Composeでの構築と本番運用で決めること

GitHubのリリースの記録には、版ごとの修正の内容が載ります。重大な脆弱性の修正が出たときにすぐ版を上げられるよう、誰がリリースを見て、いつ上げるかを決めておきます。

関連記事：n8nの脆弱性と対策｜CVE-2026-21858など重大な脆弱性の影響範囲と、自社の版の確かめ方

GitHubノードとGitHub TriggerでGitHubの作業を自動にする

n8nとGitHubをつなぐ部品は2つあります。GitHubノードは、ワークフローの途中でGitHubに書き込んだり読み出したりします。GitHub Triggerは、GitHubで起きた出来事を受けてワークフローを動かし始めます。

GitHubノードで操作できるもの

GitHubノードでは、ファイル・Issue・Pull Requestなど、GitHubの主な対象を作ったり読んだりできます。公式ドキュメントに載っている対象と操作は次のとおりです。

このほか、組織や利用者に属するリポジトリの一覧を取ったり、利用者を招待したりもできます。GitHubノードを使うには、GitHubのアカウントで発行したトークンなどを、n8nの認証情報として登録します。

GitHub Triggerで起動できる出来事

GitHub Triggerは、GitHubのWebhookを使って、リポジトリで出来事が起きたときにワークフローを起動します。選べる出来事は40種類あまりあり、よく使うのはPush・Pull request・Issue comment・Releaseです。ほかにも、レビューの投稿、スターやフォーク、脆弱性の警告などを起点にできます。

Webhookは外からn8nへ届く通知なので、GitHub Triggerを使うには、n8nがインターネットから届くURLで動いている必要があります。手元のPCで起動しただけのn8nには、GitHubからの通知は届きません。

GitHubとn8nをつなぐ自動化の例

どの例も、GitHubの出来事やフォームの送信を合図に動き、GitHubへ書き込むか、GitHubの内容をほかへ渡します。よく組まれる例を4つ挙げます。

問い合わせフォームからIssueを作る

フォームの送信を受けたらGitHubノードでIssueを作成し、内容に応じたラベルを付けます。窓口に届いた不具合の報告を、担当者が書き写さずに済みます。

Issueのコメントをチャットに知らせる

GitHub TriggerのIssue commentで起動し、コメントの本文と書いた人をチャットへ送ります。GitHubを普段見ない担当者にも動きが伝わります。

Pull Requestの差分をAIに要約させる

Pull requestの出来事で起動し、GitHubノードで差分を取得してAIに要約させ、Pull Requestにコメントとして書き戻します。レビューする人が全体をつかむ手間が減ります。

リリースのたびに更新のお知らせを下書きする

Releaseの出来事で起動し、リリースの説明を社内向けの言葉に直した下書きを作ります。配信は人が中身を確かめてから行います。

AIを組み込むワークフローの作り方は、n8nでAIエージェントを作る記事で手順を追っています。

関連記事：n8nでAIエージェントを作る手順｜MCP・RAGのつなぎ方

n8nのワークフローをGitHubで管理する3つの方法

作ったワークフローは、n8nの中ではJSONの形で保存されています。これをGitHubに置いて変更の履歴を残す方法は3つあり、使えるプランと手間が違います。

エディターからワークフローのJSONを書き出す

いちばん手軽なのは、エディターの右上のメニューから「Download」でワークフローをJSONのファイルとして書き出し、GitHubにコミットする方法です。戻したいときは、同じメニューの「Import from File…」で読み込みます。

手で書き出すため、直したのに書き出し忘れると、GitHubの版が古いまま残ります。1人で数本を持つ段階なら十分ですが、本数や人が増えると漏れが出やすくなります。

GitHubノードで定期的にコミットする

無料版のまま履歴を自動で残したいなら、バックアップ用のワークフローを1本作ります。Schedule Triggerで決まった時刻に起動し、n8nノードで自分のn8nからワークフローの一覧を取り、GitHubノードのFileの操作で1本ずつJSONのファイルを作成・更新します。

この方法で残るのは決まった時刻の状態だけで、その間に何度直したかまでは分かりません。GitHubに書き込むトークンを渡すことになるため、書き込める範囲をバックアップ用のリポジトリだけに絞って発行します。

ソース管理で本番と検証を分ける

n8nの有償プランには、Gitのリポジトリとn8nをつなぐソース管理の機能があります。公式ドキュメントでは、Source control and environmentsの名前で、有償プランのうち上位の2つで使えると案内されています。枝（ブランチ）ごとに別のn8nをつなぎ、検証用で直したものを本番用へ移す使い方ができます。

設定は、公式ドキュメントでは次の順に進めます。

1. GitHubにn8n用のリポジトリを作り、検証用・本番用など環境ごとの枝を作る
2. n8nの「Settings」から「Environments」を開き、リポジトリのURLを入れる
3. SSHの鍵をn8nの画面からコピーしてGitHubに書き込み権限付きで登録するか、HTTPSで利用者名とトークンを入れる
4. 「Connect」を押してつなぎ、このn8nで使う枝を選ぶ
5. 本番のn8nでは「Protected instance」を選び、画面で直接直せないようにしてから「Save settings」で保存する

n8nの画面では、変更をGitへ送る操作（push）とコミットが同時に行われます。Gitから取り込む操作（pull）は、まだ送っていない変更を上書きするため、取り込む前に送っておきます。n8nの中にはプルリクエストで変更を見比べて承認する機能が無いため、承認はGitHubの画面で行います。

Gitに置かれるものと、認証情報の扱い

ソース管理でGitに置かれるのは、選んだワークフロー、タグ、認証情報と変数の枠（名前と種類だけの空の入れ物）です。パスワードやAPIキーなどの認証情報の中身はGitに置かれないため、取り込んだ先のn8nで入れ直します。

検証用と本番用で、つなぐ先のアカウントを分けられるのはこの仕組みのおかげです。本番用のn8nには本番のアカウントの認証情報を一度入れておけば、ワークフローを取り込み直しても入れ直す必要はありません。

GitHubのワークフロー集やテンプレートを読み込むときの注意

GitHubには、n8nのワークフローをJSONで公開しているリポジトリが多くあります。n8nの公式サイトにもテンプレートの一覧があり、気になるものをそのままインポートして試せます。どちらも、読み込んだワークフローは中身を確かめてから動かします。

読み込む前と後に確かめることは次のとおりです。

読み込んだワークフローには認証情報が付いてこないため、つなぐ先ごとに自社の認証情報を選び直します。最初は、外部へ書き込まない操作だけを手動で実行し、出力を見てから本番のデータでつなぎます。

社内の誰かが作ったワークフローが増えてくると、どこで何が動いているかを把握しにくくなります。申請と棚卸しの決め方は、内製したAIの管理を扱った記事が参考になります。

関連記事：現場が作ったAIエージェントを誰が管理するか｜野良AIを増やさない申請・棚卸し・停止の基準

まとめ：n8nのGitHubは入れ方と管理の方法で使い分ける

• n8nのGitHub公式リポジトリはn8n-io/n8nで、所有者がn8n-ioのものだけを使う
• 利用条件はfair-codeで、自社の業務の自動化には無料で使えるが、n8nそのものを他社向けに売ることはできない
• 試すならREADMEのDockerの2行で起動し、npx n8nは短時間の試用に留める
• GitHubノードはIssue・Pull Request・ファイルなどを操作し、GitHub TriggerはPushやPull requestなどの出来事で起動する
• ワークフローのGit管理は、JSONの書き出し・GitHubノードでのコミット・BusinessとEnterpriseのソース管理の3つから、本番と検証を分けたいかで選ぶ
• ソース管理でも認証情報の中身はGitに置かれず、取り込んだ先で入れ直す

Augueでは、n8nを使った業務の自動化を社内で作って保守できるよう、ワークフローの設計から変更の管理の決め方まで一緒に進める支援をしています。ご興味がある方は是非ご相談ください。

AIツールを、業務の成果につなげませんか？

使い方を覚えたあとは、どの業務にどう組み込むかで成果が変わります。自社の業務に合う使い方を、無料相談で一緒に考えます。

資料をダウンロードする無料相談に申し込む

よくある質問

GitHubからソースコードを落として、自分でビルドして使うこともできますか？

できますが、社内の業務で使うだけなら勧めにくい方法です。自分でビルドすると、セキュリティの修正が出るたびに取り込み直してビルドし直す作業が自社に残ります。公式のDockerイメージなら版の番号を変えて起動し直すだけで済むため、ソースコードを読むのは、動きを確かめたいときや不具合を報告するときに留めるのが現実的です。

n8nに不具合を見つけたら、GitHubに報告してよいですか？

報告できます。公式リポジトリのIssueに、使っている版、動かしている環境、再現の手順を添えて書きます。使い方の質問はIssueではなく、n8nのコミュニティフォーラムで尋ねるのが通例です。脆弱性のように公開すると悪用されうる問題は、Issueに書かず、n8nが公開している脆弱性の報告の手順に従って非公開で伝えます。

GitHubではなくGitLabやBitbucketでもワークフローを管理できますか？

管理できます。有償プランのソース管理は、SSHかHTTPSでつながるGitのリポジトリであれば、GitHubに限らず接続先に選べます。GitHubノードで定期的にコミットする方法も、GitLabノードなど同じ役割のノードに置き換えれば組めます。社内で使っているGitのサービスに合わせて選べば、権限の管理を増やさずに済みます。

ソース管理を使うと、ワークフローの変更をプルリクエストで承認できますか？

n8nの画面の中には、プルリクエストで変更を見比べて承認する機能はありません。承認したい場合は、検証用の枝へ反映したあと、GitHubの画面でプルリクエストを作り、レビューを経て本番用の枝へ取り込みます。本番のn8nはその枝から取り込む流れにすれば、承認していない変更は本番に入りません。

関連する記事

n8nとは？n8nの使い方・読み方・できること・無料の範囲を解説n8nとは、ノードをつないで業務を自動化するツールです。n8nの使い方を、登録から公開までの手順と式・テンプレート・Webhookの扱いで解説し、読み方や無料の範囲、日本語での扱いもまとめます。n8nセルフホストの手順｜Docker・Docker Composeでの構築と本番運用で決めることn8nセルフホストは、DockerやDocker Composeを使えば自社のPCやVPSに無料で構築できます。クラウド版との費用の違い、起動の手順、SSLとリバースプロキシ、暗号化キーとバックアップの扱いを解説します。内製したAIエージェントの運用・保守｜壊れたときに誰が直すかと、外部支援を外すタイミング内製したAIに起きる不具合を、指示の調整で済むもの、接続先の仕様変更、権限の問題に分けて一次対応者を決める方法から、月次点検の項目、精度低下への気づき方、外部支援を外す目安までを整理します。生成AIの内製化とは｜メリット・デメリットと始め方、外注に残す範囲生成AIの内製化とは、対象の選定から業務が変わったときの修正までを社内の判断で回せる状態です。メリット・デメリットと何から始めるかを先に答え、層ごとに外注へ残す範囲と、併走を終える判断を表で整理しました。