3行でいうと

  • n8nは、認証情報を暗号化して保存する。その鍵を控えないと、バックアップから戻しても認証情報が読めない。
  • Webhookは、リバースプロキシの内側では、n8nなら環境変数N8N_WEBHOOK_URLを、DifyならTRIGGER_URLを設定する。
  • n8nはSustainable Use License、Difyは条件つきのApache 2.0。社外の人に使わせる形は、条件に触れることがある。

この記事は、実際に使って確かめた記録ではありません。この記事は公式の文書を読んでまとめたものです。数字は2026年10月8日に確認し、版番号と初期値は10月22日に公式ページで読み直しました（SSLの手順とn8nのLICENSE.md原文は10月8日の確認のままです）。ソフトの版や設定名は変わります。

先に結論

前提：言葉の整理

n8nを動かす

最小の起動

公式のDockerの手順は、n8n_dataというボリューム（コンテナの外に残す保存場所）を作り、/home/node/.n8nに割り当てて、ポート5678で公開する形です。公式文書では「安定版（stable）は本番用、beta（最新）は不安定な場合がある」とされ、10月22日に読んだときの安定版は2.44.5、betaは2.45.1でした（10月8日には2.42.4と2.43.1）。ただし、このDockerの手順のページには「内容が古い」との表示があり、Docker Composeの手順のページへ案内されています。新しい小版は、ほぼ毎週出ると書かれています。

既定の保存先はSQLite（1つのファイルで済む軽いデータベース）です。Docker Composeの手順書は、利用者が数人を超える本番や、ワークフローを常時稼働させる本番にはPostgreSQLを勧め、SQLiteは試験用としています。

公式文書の起動コマンドの例

公式文書の例です。この記事では、実行していません。<YOUR_TIMEZONE>は自分のタイムゾーンに置き換える部分です。

docker volume create n8n_data
docker run -it --rm \
 --name n8n \
 -p 5678:5678 \
 -e GENERIC_TIMEZONE="<YOUR_TIMEZONE>" \
 -e TZ="<YOUR_TIMEZONE>" \
 -e N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true \
 -v n8n_data:/home/node/.n8n \
 n8nio/n8n

公式文書によると、N8N_RUNNERS_ENABLEDはn8n 2.0から非推奨で、設定は不要です（1.xではtrueが必要）。10月8日に読んだ例にはこの行がありましたが、10月22日の例からは外れていました。

Docker Composeの手順書は、AI機能（n8n Assistant）の実行環境も含む構成で、2 vCPU・4GB以上のメモリを必要とし、同梱の実行環境は開発・試験用で、本番には別の実行環境（Daytona）を勧めると書いています。さらに、Composeの手順にはPostgreSQLを足す例があります。そこには、PostgreSQL 18ではPGDATAの指定を消すとデータが空で始まる、という注意が書かれています。また、SQLiteのデータはPostgreSQLへ自動では移りません。

暗号鍵は、必ず控える

n8nは、認証情報（外のサービスのパスワードやAPIキー）を暗号化してデータベースに保存します。公式文書によると、鍵は初回の起動で自動生成され、~/.n8nフォルダの設定ファイルに保存されます。環境変数N8N_ENCRYPTION_KEYで自分の値を指定することもできます。キューモード（複数の処理役で分担する構成）では、すべての処理役に同じ鍵を渡す必要があります。

バックアップの文書は、鍵がないと、戻したデータベースも、暗号化した認証情報の書き出しも、復号できないと明記しています。

Webhookの公開URL

n8nは、Webhook用のURLを、プロトコル・ホスト・ポートの設定から組み立てます。リバースプロキシの内側では、内部のポート5678と、外のポート443が食い違い、この組み立てが合いません。公式文書の対策は3点です。

Webhookノードには「テスト用」と「本番用」の2つのURLがあります。本番用は、ワークフローを公開したときに登録されます。受け付けの認証は、Basic認証、ヘッダー認証、JWT認証、なしから選べ、IPアドレスの許可リストも設定できます。受け取れるデータの最大は16MBで、N8N_PAYLOAD_SIZE_MAXで変えられると書かれています。HTTPSは、公式文書が、リバースプロキシで終わらせる方法を勧めています。

バックアップの範囲

公式の「Back up and restore」には、完全なバックアップは次の2つだと書かれています。

  1. .n8nフォルダ（設定ファイルと暗号鍵。SQLiteなら、データベース本体も）。
  2. PostgreSQLを使うなら、そのデータベース。外部保管（S3など）やカスタムノードの置き場も含める。

SQLiteは、n8nを止めてからコピーする、と書かれています。CLIの書き出し（n8n export:workflow --backupなど）は便利ですが、ユーザーと役割、実行履歴、変数、暗号鍵を含みません。つまり、ワークフローの引っ越しには足りても、サーバー丸ごとの復旧には足りません。--decryptedで書き出した認証情報は平文になるため、戻したら消すよう警告されています。

Difyを動かす

最小の起動

公式文書の手順は、リリースのタグを指定してgit cloneし、dify/dockerで.env.exampleを.envにコピーして、docker compose up -dを実行する流れです。必要な条件はCPU 2コア以上、メモリ4GiB以上、Docker Compose 2.24.0以上と書かれています。起動するのは、中核のサービス7つ、周辺部品8つ（PostgreSQL、Redis、Weaviate、nginx、サンドボックスなど）、一度だけ動く初期化1つです。管理者の登録は、/installのページで行います。

秘密の値を初期値のままにしない

Difyの環境変数の文書には、置き換えを求める記述が複数あります。

Webhookの公開URL

Difyでは、Webhookトリガー（ワークフローの開始点）の呼び出し先を、環境変数TRIGGER_URLで決めます。初期値はhttp://localhostで、外のサービスが届く公開のドメインかIPアドレスにする必要がある、と書かれています。Webhookの認証設定は、読んだページでは確認できていません。ヘッダーの認証トークンを受け取る例の記述はありましたが、検証の仕組みの説明は見つかりませんでした。

バックアップと更新

公式のトラブルシューティングの文書は、Docker Composeならdify/docker/volumesフォルダ全体を控えるよう書いています。更新の前に、difyフォルダ全体のコピーを取る例もあります。イメージで動かしている場合の更新は、docker compose pullのあとdocker compose up -d、ソースから動かしている場合はgit pullのあとflask db upgradeが必要、と書かれています。更新後に新しい.env.exampleと自分の.envを見比べる、docker-compose.yamlを直していたなら新しい版のファイルへ変更を載せ直す（版によって必要なサービスが増えることがあるため）、という手順は、このページではなく、クイックスタートの文書（Deploy Dify with Docker Compose）に書かれています。更新の手順は版ごとに違うので、更新の前に、リリースの案内で変更点を確かめてください。

ライセンス：社外の人に使わせる形は、読んでから

ここは条文と公式FAQの紹介です。個別の判断は専門家に相談してください。

n8n Dify
ライセンス Sustainable Use License（fair-codeという考え方）。.ee.を含むファイルは別の有償ライセンス Apache 2.0を修正したもの（追加条件つき）
自社の業務で使う 可 可（商用も可）
注意が要る形 外部の利用者に、ワークフローを作らせる・設定させる形、n8nをサービスとして貸す形、ブランドを消して再販する形は不可と、公式FAQが列挙 複数テナント（1つのワークスペースが1テナント）の運用は、書面の許可がない限り不可。フロントエンドのロゴと著作権表示を消したり変えたりするのは不可（フロントエンドを使わない利用には適用されない）

n8nのFAQには、依頼主にこちらで作った自動化を使わせる形（依頼主が作成・編集できない場合）、自社製品の裏側で動かす形は、許される例として書かれています。画面上の見え方ではなく、誰がワークフローの中身を決めるかが基準、という説明があります。

選び方の目安

見立てです。ここまでの公式文書から、僕らは次のように整理しました。

気をつけること

出典

更新履歴