メインコンテンツへスキップ
このドキュメントは AI によって自動翻訳されています。不正確な部分がある場合は、英語版 を参照してください。

設定ファイル

Docker Compose は、3 種類のファイルから Dify の設定を読み込みます。
  • docker/.env:Compose プロファイルや公開ポートなどのデプロイ全体の設定と、共有の認証情報です。新規デプロイでは docker/.env.example から作成してください。
  • .defaults ファイル(docker/envs/ 内):サービスが自動で読み込む同梱のデフォルト設定です。リリースごとに新しいバージョンが同梱されるため、編集しないでください。
  • ローカル .env ファイル(docker/envs/ 内):そのファイルを読み込むサービスに対する上書き設定です。Git の追跡対象外のため、新しいリリースをチェックアウトしてもそのまま残ります。
ソースコードから Dify を実行する場合は、api/.env、web/.env.local、およびミドルウェアコンテナ用の docker/middleware.env に変数を設定してください。

変数の設定

1

対象ファイルの特定

ほとんどの変数は docker/envs/ 内のローカル .env ファイルに記述し、次の 2 種類の設定は docker/.env に記述します:
  • Compose がサービスファイルより先に読み込む設定:COMPOSE_PROFILES や VECTOR_STORE などが該当します。
  • 共有の認証情報:使用するすべてのサービスで同じ値になるよう、ここに設定します。
    • PLUGIN_DAEMON_KEY と PLUGIN_DIFY_INNER_API_KEY:それぞれ異なる、推測されにくい値を設定します。
    • DIFY_AGENT_API_TOKEN と DIFY_AGENT_LOCAL_SANDBOX_AUTH_TOKEN:それぞれ異なる、推測されにくい値を設定します。
    • SANDBOX_API_KEY と CODE_EXECUTION_API_KEY:両方に同じ値を設定します。値が異なると、コード実行ノードとテンプレートノードが HTTP 401 エラーで失敗します。
それ以外の変数は、docker/envs/ 内で変数名を検索し、見つかったファイルに応じて次のように対応します:
  • .defaults ファイルが 1 つ見つかった場合:.defaults ファイルの最初のコメントに記載されたローカルファイルを編集します。ローカルファイルがまだない場合は、先に .defaults ファイルをその名前でコピーします。
  • .defaults ファイルが複数見つかった場合:その変数を使うすべてのサービスが読み込むローカルファイルを編集します。そうしないと、サービスごとに値が異なってしまいます。
  • .env.example テンプレートが見つかった場合(envs/security.env.example など):.example を外した名前でコピーします。ただし、envs/middleware.env.example は対象外です。このファイルを読み込むのは、ソースコードから開発する際に使う別構成の ミドルウェアスタック だけです。
docker/.env とローカルファイルの両方で同じ変数を設定した場合は、docker/.env の値が優先されます。例外については 優先順位 を参照してください。
2

値の編集

ローカルファイルで必要な値を変更し、使いたいオプション設定だけコメントを解除します。
Container variable mappings の下にある行は変更しないでください。各行は、編集した設定値をコンテナが読み取る変数名に渡します。
同梱のデフォルト値に戻すには、その行を削除するかコメントアウトします。値を空にして残さないでください。CELERY_WORKER_AMOUNT= のように値が空の行は、デフォルト値を空の値で上書きすることがあります。また、docker/.env に値が空の行があると、ローカルファイルの値が反映されなくなります。
3

変更の適用

dify/docker で設定を検証し、影響を受けるコンテナを再作成します:
docker compose restart ではなく up -d を使ってください。restart では、コンテナは古い環境変数をそのまま使います。解決後の値を確認するには、docker compose config を実行します。出力にはシークレットが含まれるため、非公開で扱ってください。稼働中のサービスで値を確認するところまでの具体例は、カスタマイズ を参照してください。ローカルファイル、シークレット、データを失わずに新しいリリースへ更新するには、アップグレード の手順に従ってください。

優先順位

同じ変数が複数の場所で設定されている場合、サービスがどの値を使うかは、そのサービスが docker/.env を読み込むかどうかで決まります:
API、WebSocket API、ワーカー、Beat、Web、コード実行サンドボックス、プラグインデーモン、Agent バックエンドが対象です。これらのサービスは次の順に値を探し、最初に見つかった値を使います:
  1. docker/.env
  2. サービスのローカル .env ファイル
  3. サービスの .defaults ファイル
  4. アプリケーションのデフォルト値
.defaults ファイルの Container variable mappings コメントの下にある変数は、常に別の設定から値をコピーします。docker/.env を含め、これらを直接設定しても効果はありません。代わりにコピー元の設定を変更してください。
実際の値がこれらのファイルのどれにも由来しない場合は、次の 2 か所も確認してください:
  • Compose を実行するシェルでエクスポートされた変数(${...} の値では docker/.env より優先)
  • Compose ファイル内のサービスの environment: 項目(MODE: api など。すべての環境変数ファイルより優先)

共通変数

これらの URL 変数は、Dify の各サービスのアドレスを設定します。 Nginx 背後のシングルドメインデプロイ(デフォルトの Docker Compose 構成)の場合、これらは空のままで構いません。システムがリクエストから自動検出します。カスタムドメイン、マルチドメインデプロイ、またはリバースプロキシを使用する場合に設定してください。

CONSOLE_API_URL

デフォルト値:(空) Dify バックエンド API の公開 URL。OAuth ログイン(GitHub、Google)、Notion 連携、または OAuth を必要とするプラグインを使用する場合に設定してください。これらの機能は、認証後にユーザーをリダイレクトするための絶対コールバック URL を必要とします。また、セキュア(HTTPS のみ)Cookie を使用するかどうかも決定します。 例:https://api.console.dify.ai

SERVER_CONSOLE_API_URL

デフォルト値:http://api:5001 Web フロントエンドコンテナがサーバーサイドでリクエストを送信する際に使用する Console API のアドレスです。公開ドメインを経由せず、Docker 内部ネットワークから API に直接アクセスします。この変数は Web フロントエンドコンテナでのみ使用され、Python バックエンドには影響しません。ブラウザからのリクエストは引き続き CONSOLE_API_URL を使用します。空の場合は CONSOLE_API_URL にフォールバックします。API サービスの内部アドレスが異なる場合にのみ変更してください。

CONSOLE_WEB_URL

デフォルト値:(空) Dify コンソールフロントエンドの公開 URL。すべてのシステムメール(招待、パスワードリセット、通知)のリンク構築、および OAuth ログイン後のコンソールへのリダイレクトに使用されます。CONSOLE_CORS_ALLOW_ORIGINS が設定されていない場合、デフォルトの CORS 許可オリジンとしても機能します。 空の場合、メールリンクが正しく機能しません。シングルドメインデプロイでも、メール機能を使用する場合はこの変数を設定してください。 例:https://console.dify.ai

SERVICE_API_URL

デフォルト値:(空) Dify コンソールで Developer に表示される API Base URL。Developer が Dify API を呼び出すためにコードにコピーする URL です。空の場合、現在のリクエストから自動検出されます(例:http://localhost/v1)。サーバーが複数のアドレスでアクセス可能な場合、この変数を設定して一貫した URL を確保してください。 例:https://api.dify.ai

APP_API_URL

デフォルト値:(空) Web アプリフロントエンド(公開アプリ)のバックエンド API URL。この変数は Web フロントエンドコンテナでのみ使用され、Python バックエンドには影響しません。空の場合、Docker イメージのデフォルトは http://127.0.0.1:5001です。 例:https://api.app.dify.ai

APP_WEB_URL

デフォルト値:(空) 公開 Web アプリのアクセス URL。ワークフローの 人間の入力ノード に必要です。メール通知のフォームリンクは {APP_WEB_URL}/form/{token} 形式で構築されます。空の場合、人間の入力メールに有効なフォームリンクが含まれません。 例:https://app.dify.ai

TRIGGER_URL

デフォルト値:http://localhost Webhook およびインテグレーショントリガーエンドポイントのアクセス URL。外部システムがこのアドレスを使用してワークフローを呼び出します。Dify はトリガーコールバック URL を {TRIGGER_URL}/triggers/webhook/{id} の形式で構築し、コンソールに表示します。 外部システムからトリガーが動作するようにするには、それらがアクセスできるパブリックドメインまたは IP アドレスを指定する必要があります。

FILES_URL

デフォルト値:(空;CONSOLE_API_URL にフォールバック) ファイルプレビューおよびダウンロードリンクのベース URL です。Dify はすべてのファイル(アップロードされたドキュメント、ツール出力、ワークスペースロゴ)に対して、署名付きの時間制限 URL を生成します。生成された URL はフロントエンドとマルチモーダルモデルに提供されます。 ファイル処理プラグインを使用する場合、またはファイル URL を専用ドメインで使用したい場合に設定してください。FILES_URLと CONSOLE_API_URL の両方が空の場合、ファイルプレビューが機能しません。 例:https://upload.example.comまたはhttp://<your-ip>:5001

INTERNAL_FILES_URL

デフォルト値:(空;FILES_URL にフォールバック) Docker ネットワーク内のサービス間通信で使用されるファイルアクセス URL(例:プラグインデーモン、PDF/Word 抽出器)。これらの内部サービスは、Nginx やパブリックドメインを Nginx 経由する外部 FILES_URL にアクセスできない場合があります。 空の場合、内部サービスは FILES_URL を使用します。内部サービスが外部 URL にアクセスできない場合に設定してください。 例:http://api:5001

FILES_ACCESS_TIMEOUT

デフォルト値:300(5 分) 署名付きファイル URL の有効期間(秒)。この時間を過ぎると URL は拒否され、ファイルを再リクエストする必要があります。長時間実行プロセスの場合は増加し、セキュリティを強化する場合は減少させてください。

ENABLE_COLLABORATION_MODE

デフォルト値:true ワークフローキャンバスのリアルタイム共同編集(同時編集、キャンバス上のコメント、@メンション)を有効化します。 localhost 以外のホストから Dify にアクセスする場合、NEXT_PUBLIC_SOCKET_URL をブラウザから到達できる WebSocket URL に設定してください(CORS 設定 を参照)。デフォルトの ws://localhost はローカル専用環境でのみ動作します。 共同編集機能を無効化するには、この値を false に設定します。Docker Compose を使用している場合は、COMPOSE_PROFILES から collaboration も削除してください。削除しないと、専用の api_websocket コンテナはトラフィックを受け取らないまま起動し続けます。 独自のリバースプロキシを使用する場合は /socket.io/ パスで Upgrade および Connection ヘッダーを転送してください(同梱の nginx テンプレートにはこの設定が含まれています)。API を複数レプリカで運用する場合はスティッキーセッションが必要です。 大きなワークフローの共同編集中にエディタが切断と再接続を繰り返す場合は、WEBSOCKET_MAX_HTTP_BUFFER_SIZE を上げてください。

システムエンコーディング

サーバー設定

ログ

一般

SECRET_KEY

デフォルト値:(空。生成したキーを、設定されたストレージに保存) 認証トークンとファイル URL の署名、システムレベルの OAuth クライアント認証情報の暗号化に使います。 この変数が空の場合、Dify は設定されたストレージの .dify_secret_key にあるキーを再利用します。キーがない場合は生成して保存します。同梱のファイルシステムストレージでは、ホスト側のパスは docker/volumes/app/storage/.dify_secret_key です。 空でない SECRET_KEY は、保存されたキーより優先されます。独自のキーを使うには、推測されにくいランダムなキーを生成し、初回起動前に設定してください:
生成したキーを保存できない場合、Dify の初期化は失敗します。設定されたストレージを書き込み可能にするか、キーを明示的に指定してください。
明示的に指定する場合も永続ストレージに保存する場合も、アップグレードと復元では同じキーを保持してください。変更すると、既存の認証トークンと署名付きファイル URL が無効になります。既存のシステムレベルの OAuth クライアント認証情報も復号できなくなります。元のキーに戻すと、その認証情報を再び使えるようになります。

PASSWORD_PEPPER

デフォルト値:(空) メンバーが Dify へのサインインに使うパスワードに混ぜ込む、サーバー側の秘密値です。流出したデータベースのコピーだけでは、パスワードを解読できなくなります。空のままなら、動作は変わりません。 ペッパーを使う場合は、初回セットアップで管理者アカウントを作成する前に設定してください。十分なエントロピーを持つランダムな値を生成します。例:
Docker Compose では、docker/envs/core-services/api.env に設定します。docker/.env には書かないでください。Compose はこのファイルの値を、ワーカー、プラグインデーモン、Agent バックエンド、Web フロントエンド、コード実行サンドボックスにも渡します。ソースコードからデプロイした場合は、api/.env に設定します。
アカウント作成後にペッパーを設定、変更、削除すると、既存のパスワードはサインイン時に無効と判定されます。誤って操作した場合は、以前の値に戻してください。その間にリセットされなかったパスワードは、すべて再び使えるようになります。この値は SECRET_KEY と同様に厳重に管理してください。
既存のアカウントがあるデプロイで有効にする場合は、有効化後に各メンバーが再びサインインできる手段を用意してください:
  • API コンテナで flask reset-password を実行し、各アカウントのパスワードをリセットします。コマンドの詳細は 管理者パスワードのリセット を参照してください。
  • メンバー自身に、パスワードリセットメールからパスワードを再設定してもらいます。この方法には メール送信の設定 が必要です。
  • ENABLE_EMAIL_CODE_LOGIN を有効にしている場合、メンバーはパスワードの代わりに、メールで届くコードを使ってサインインできます。

KEY_PROVIDER_TYPE

デフォルト値:local 保存された資格情報(モデルプロバイダーの API キー、ツール資格情報などワークスペースの機密情報)を暗号化する、ワークスペースごとの鍵の保管場所を選択します。
  • local:ワークスペースごとに RSA 鍵ペアを生成し、秘密鍵を STORAGE_TYPE のストレージバックエンドに保存します。
  • azure-keyvault:各ワークスペースの RSA 鍵を Azure Key Vault に保管し、秘密鍵が Key Vault の外に出ることはありません。認証には DefaultAzureCredential(マネージド ID、環境変数、または Azure CLI ログイン)を使用します。
プロバイダーは最初のワークスペースを作成する前に決めてください。一方のプロバイダーで暗号化した資格情報はもう一方では復号できません。資格情報が保存済みのデプロイで切り替えると、再入力するまで読み取れなくなります。

INIT_PASSWORD

デフォルト値:(空) 初回セットアップ時のオプションのセキュリティゲート。設定すると、/install ページで管理者アカウント作成前にこのパスワードの入力が必要になります。サーバーが公開されている場合の不正なセットアップを防止します。セットアップ完了後、この変数は効力を失います。最大長:30 文字。

トークンとリクエスト制限

コンテナ起動設定

Docker イメージまたは Docker Compose で起動する場合にのみ有効です。

MODE

デフォルト値:サービスごとに異なります(Docker Compose では api、worker、beat) dify-api イメージがコンテナ起動時に実行するプロセスを選択します。同梱の Compose ファイルは、各サービスの environment で MODE を設定しています。この値は env ファイルの値より優先されます。指定できる値:
  • api(空または認識されない値も同様):API サーバー
  • worker:Celery タスクコンシューマー
  • beat:定期タスクディスパッチャー
  • job:Flask CLI コマンドを 1 つ実行して終了
  • migration:MIGRATION_ENABLED=true と併用し、データベース移行後に終了
Kubernetes などのカスタム構成でのみ設定してください。誤った値ではコンテナが別のプロセスを実行します。worker がないと、インデックス作成やメールのタスクが処理されずに滞留します。

API ツール設定

データベース設定

データベースはデフォルトで PostgreSQL を使用します。OceanBase、MySQL、seekdb もサポートされています。データベースの種類を変更しても保存済みのデータは移行されないため、初回起動の前に選択してください。 同梱の MySQL と Weaviate で新規デプロイを開始する場合は、docker/.env に次の値を設定します:
別のベクトルストアを使う場合は、weaviate の代わりにそのプロファイルを指定してください。 初回起動の前に、独自の DB_PASSWORD を設定してください。後からパスワードを変更する場合は、先にデータベースサーバー側で変更し、その後 DB_PASSWORD を同じ値に更新します。

コネクションプール

Dify がデータベースコネクションプールを管理する方法を制御します。デフォルト設定はほとんどのデプロイで問題なく動作します。

PostgreSQL パフォーマンスチューニング

これらは PostgreSQL コンテナへの起動引数として渡されます。Dify アプリケーションではなく、データベースサーバーの設定です。

MySQL パフォーマンスチューニング

これらは MySQL コンテナへの起動引数として渡されます。Dify アプリケーションではなく、データベースサーバーの設定です。

Redis 設定

これらの変数を設定して、Dify を Redis インスタンスに接続します。Dify はスタンドアロン(デフォルト)、Sentinel、Cluster の 3 つのデプロイモードをサポートしています。

Redis SSL 設定

REDIS_USE_SSL=trueの場合にのみ適用されます。Celery broker の URL が rediss:// スキームを使用する場合、これらの設定は Celery broker にも適用されます。

Redis Sentinel モード

Sentinel は高可用性のための自動マスター検出とフェイルオーバーを提供します。Cluster モードとは相互に排他的です。

Redis Cluster モード

Cluster モードは複数の Redis ノード間での自動シャーディングを提供します。Sentinel モードとは相互に排他的です。

Redis 接続の堅牢性設定

これらの変数は、Redis 接続のクライアント側リトライ、タイムアウト、ヘルスチェックの動作を調整します。デフォルト値は控えめに設定されています。ネットワークレイテンシが高いクラウド/WAN デプロイでは、タイムアウト値を増やしてください。

Celery 設定

データセットインデックス作成、メール送信、定期ジョブに使用されるバックグラウンドタスクキューを設定します。

CELERY_BROKER_URL

デフォルト値:redis://:difyai123456@redis:6379/1 Celery メッセージブローカーの Redis 接続 URL。 直接接続形式:
Sentinel モード形式(複数ノードはセミコロンで区切り):

CORS 設定

フロントエンドのクロスドメインアクセスポリシーを制御します。

Dify CLI とプログラマティック API

/openapi/v1/* は、Dify CLI(difyctl)などのクライアントが OAuth ベアラートークンで利用する、ユーザー単位のプログラマティック API です。デフォルトでは無効です。CLI を使うには OPENAPI_ENABLED と ENABLE_OAUTH_BEARER の両方を true にします。

ファイルストレージ設定

Dify がアップロードファイル、データセットドキュメント、暗号化キーを保存する場所を設定します。各ストレージタイプには独自の資格情報変数があります。使用するもののみを設定してください。

STORAGE_TYPE

デフォルト値:opendal ファイルストレージバックエンドを選択します。サポートされる値:opendal、s3、azure-blob、aliyun-oss、google-storage、huawei-obs、volcengine-tos、tencent-cos、baidu-obs、oci-storage、supabase、clickzetta-volume、local(非推奨;内部的に OpenDAL のファイルシステムスキームを使用)。
Apache OpenDAL を使用するデフォルトのストレージバックエンド。多くのストレージサービスをサポートする統一インターフェースです。Dify は OPENDAL_<SCHEME>_* に一致する環境変数を自動スキャンし、OpenDAL に渡します。例えば、OPENDAL_SCHEME=s3 の場合、OPENDAL_S3_ACCESS_KEY_ID、OPENDAL_S3_SECRET_ACCESS_KEY などを設定します。デフォルトの fs スキームの場合:利用可能なすべてのスキームとその設定オプションについては、 OpenDAL サービスドキュメント を参照してください。
ClickZetta Volume は、ベクトルデータベースセクションで設定された CLICKZETTA_* 接続パラメータを再利用します。

アーカイブストレージ

ワークフロー実行ログをアーカイブするための独立した S3 互換ストレージ。archive-workflow-runs メンテナンスコマンドが、指定した期限より古いワークフロー実行を月単位の Parquet バンドルにまとめます。アーカイブから生成される CSV エクスポートはエクスポート用バケットに一時保存されます。

ベクトルデータベース設定

ナレッジベースの埋め込みを保存し、類似検索に使うベクトルデータベースを設定します。

VECTOR_STORE

デフォルト値:weaviate 新規ナレッジベースに使うベクトルデータベースを選択します。既存のナレッジベースは、インデックス作成時のベクトルデータベースを引き続き使います。 サポートされる値:weaviate、oceanbase、seekdb、qdrant、milvus、myscale、relyt、pgvector、pgvecto-rs、chroma、opensearch、oracle、tencent、elasticsearch、elasticsearch-ja、analyticdb、couchbase、vikingdb、opengauss、tablestore、vastbase、tidb_vector、tidb_on_qdrant、baidu、lindorm、huawei_cloud、upstash、matrixone、clickzetta、alibabacloud_mysql、iris、hologres。 同梱のプロバイダー(それぞれ同名の Compose プロファイルあり):weaviate、qdrant、oceanbase、seekdb、couchbase、pgvector、pgvecto-rs、vastbase、chroma、iris、oracle、milvus、opensearch、opengauss、myscale、matrixone、elasticsearch、elasticsearch-ja。その他のプロバイダーや外部サーバーを使う場合は、同梱のプロファイルを含めないでください。接続設定はプロバイダーのローカル .env ファイルに記述します。ローカルファイルがないプロバイダーでは、envs/core-services/api-worker.env に記述してください。 別の同梱プロバイダーに切り替えるには:
1

既存のナレッジベースが使うプロバイダーの維持

COMPOSE_PROFILES には、以前のプロバイダーのプロファイルを残します。以前のプロバイダーが Weaviate 以外の場合は、あわせてその .defaults ファイルをローカルの .env ファイルにコピーします(例:qdrant.defaults を qdrant.env に)。elasticsearch-ja は elasticsearch と同じ elasticsearch.env を使います。自動で読み込まれるのは選択中のプロバイダーのデフォルト設定だけなので、コピーしないと既存のナレッジベースが接続できなくなります。
2

新しいプロバイダーの選択

docker/.env で VECTOR_STORE を設定し、COMPOSE_PROFILES にそのプロバイダーのプロファイルを追加します。その後、docker compose up -d を実行してください。
OceanBase と seekdb は OCEANBASE_* の設定を共有するため、Dify が同時に接続できるのはどちらか一方だけです。この 2 つの間で切り替える場合は、両方を残さずに既存のナレッジベースを移行してください。 既存のナレッジベースのデータを新しいプロバイダーに移すには、ベクトルデータベースマイグレーション を参照してください。 プロバイダーの接続設定を変更するには、変数の設定 の手順に従ってください。ユーザーのパスワードを保存するプロバイダーでは、先にデータベース側でパスワードを変更してから、対応するクライアント設定を更新します。
両方のプロバイダーで OCEANBASE_* 変数を使います。VECTOR_STORE を oceanbase または seekdb に設定すると、そのプロバイダーの接続設定のデフォルト値を読み込みます。
同梱の PGVector では、クライアント側のユーザー名、パスワード、データベース名は未設定のままにしてください。ベクトルデータベースサービス設定 にあるコンテナ側の設定値がそのまま使われます。外部サーバーを使う場合は設定してください。
同梱の Vastbase を使う場合は、VASTBASE_USER と VASTBASE_PASSWORD をデフォルト値のままにしてください。これらは docker-compose.yaml の VB_USERNAME と VB_PASSWORD に一致しています。外部サーバーを使う場合は、そのサーバーの認証情報を設定します。
同梱の PGVecto.RS では、クライアント側のユーザー名、パスワード、データベース名は未設定のままにしてください。ベクトルデータベースサービス設定 にあるコンテナ側の設定値がそのまま使われます。外部サーバーを使う場合は設定してください。
同梱の OpenSearch イメージにはデモ用証明書が含まれています。ローカル開発でこの OpenSearch を使う場合は、envs/vectorstores/opensearch.env に OPENSEARCH_VERIFY_CERTS=false を設定してください。本番環境と外部サーバーでは、クライアントが信頼する証明書を使い、検証は有効のままにします。
VECTOR_STORE=elasticsearch と VECTOR_STORE=elasticsearch-ja のどちらも、接続設定には envs/vectorstores/elasticsearch.env を使います。elasticsearch.defaults からコピーして編集してください。

ナレッジベース設定

アノテーションインポート

モデル設定

マルチモーダル設定

すべてのアップロードサイズ制限は NGINX_CLIENT_MAX_BODY_SIZE(デフォルト 100M)によっても制限されます。アップロード制限を 100 MB を超えて増加する場合は、NGINX_CLIENT_MAX_BODY_SIZE も同様に増加してください。そうしないと、Nginx が 413 エラーでアップロードを拒否します。

Sentry 設定

Sentry はエラー追跡とパフォーマンス監視を提供します。各サービスにはエラーレポートを分離するための独自の DSN があります。

Notion 連携設定

ナレッジベースデータソースとして Dify を Notion に接続します。 https://www.notion.so/my-integrations で連携資格情報を取得してください。

メール設定

Dify はアカウント招待、パスワードリセット、ログインコード、人間の入力ノード通知のメールを送信します。サポートされる 3 つのプロバイダーのいずれかを設定してください。メールリンクには CONSOLE_WEB_URL の設定が必要です。 共通変数 を参照してください。
3 つの TLS モード:暗黙的 TLS(SMTP_USE_TLS=true、SMTP_OPPORTUNISTIC_TLS=false、ポート 465)、STARTTLS(SMTP_USE_TLS=true、SMTP_OPPORTUNISTIC_TLS=true、ポート 587)、またはプレーン(SMTP_USE_TLS=false、ポート 25)。
詳細については、 SendGrid ドキュメント を参照してください。

その他の設定

コンソール機能

認証とアカウント

デフォルトでは、サインインはメールアドレスとパスワードで行い、新しいアカウントはワークスペースへの招待または初期セットアップウィザードで作成します。以下のトグルでこの方針を調整できます。

LLMOps トレース配信

アプリ実行のトレースは、バックグラウンドタスクが LLMOps プロバイダーへ配信します。対象のプロバイダーは Langfuse、LangSmith、Arize/Phoenix などです。Docker Compose でデプロイする場合は、docker/envs/core-services/api-worker.env にこれらの変数を設定します。

インデックス作成

新規ユーザーのデフォルト設定

ワークフロー生成

トークンと招待

すべてのトークン有効期限変数は、Redis に保存されるワンタイムトークンの有効期間を制御します。期限切れ後、ユーザーは新しいトークンをリクエストする必要があります。

コード実行サンドボックス

以下の設定は、API とワーカーがサンドボックスに接続する方法を指定します。コード実行ノード、テンプレートノード、Jinja2 プロンプト、組み込みの Code ツールで使います。

コードとテンプレートの出力制限

API とワーカープロセスは、コード実行ノードとテンプレートノードの出力にこれらの制限を適用します。設定は envs/core-services/api-worker.env で行います。サンドボックスサービスはこれらの変数を読み取りません。

ワークフローランタイム

ワークフローストレージリポジトリ

ワークフロー実行データを処理するバックエンド実装を選択します。デフォルトの SQLAlchemy リポジトリはすべてをデータベースに保存します。代替実装(例:Celery、Logstore)は異なるストレージ戦略に使用できます。

ワークフローログクリーンアップ

HTTP リクエストノード

ワークフローで外部 API を呼び出すために使用される HTTP リクエストノードの設定です。

Webhook

SSRF 保護

Dify からのすべてのアウトバウンド HTTP リクエスト(HTTP ノード、画像ダウンロードなど)は、プロキシを経由します。このプロキシは内部/プライベート IP 範囲へのリクエストをブロックし、Server-Side Request Forgery(SSRF)攻撃を防止します。

エージェント設定

Web フロントエンドサービス

これらの変数は Next.js Web フロントエンドコンテナのみで使用されます。Python バックエンドには影響しません。

NEXT_PUBLIC_ENABLE_FEATURE_PREVIEW

デフォルト値:true Go to Anything コマンドパレットの /create と /refine コマンドを有効にします。これらは自然言語の説明から Workflow や Chatflow アプリを生成・修正します。false に設定すると非表示になります。

新しい Agent

新しい Agent は、Docker Compose デプロイで追加サービス(Agent バックエンド、サンドボックス、サンドボックス専用の外向きプロキシ)として動作します。DIFY_AGENT_LOCAL_SANDBOX_AUTH_TOKEN を設定すれば、いずれも docker compose up で起動します。この機能はデフォルトで有効で、設定の大部分は既存の Compose の値から導出されるため、通常は以下の変数だけを確認すれば十分です。

DIFY_AGENT_SERVER_SECRET_KEY

デフォルト値:(同梱のデフォルト設定に開発用キーあり。本番環境では必ず置き換えてください) Agent バックエンドが内部トークンの鍵を導出するためのルートシークレットです。サンドボックス内の Agent からバックエンドへの呼び出しを認証する Bearer トークンの鍵も、このシークレットから導出します。 同梱のデフォルト値は、公開された開発用キーです。このキーを知っていれば誰でもトークンを偽造できるため、本番環境で使用する前に置き換えてください。 値はパディングなしの base64url テキストで、デコードするとちょうど 32 バイトになる必要があります。値が不正な場合、Agent バックエンドは起動しません。次のコマンドで生成できます:

DIFY_AGENT_API_TOKEN

デフォルト値:(同梱のデフォルト設定に開発用トークンあり。本番環境では必ず置き換えてください) Dify API とワーカーが Agent バックエンドの実行 API を呼び出す際に提示する Bearer トークンです。API、ワーカー、Agent バックエンドで同じ値を使うよう、docker/.env で設定してください。 同梱のデフォルト値は、公開された開発用トークンです。Agent バックエンドに到達でき、トークンを知っていれば誰でも実行を開始できます。本番環境で使用する前に、独自のランダムな値に置き換えてください。

DIFY_AGENT_LOCAL_SANDBOX_AUTH_TOKEN

デフォルト値:(空;ランタイムバックエンド がデフォルトの local の場合は必須) 同梱のサンドボックスが Agent バックエンドを認証するための共有シークレットです。トークンがないと、両方のサービスが起動直後に終了し、再起動を繰り返します。Dify を起動する前に設定してください。 次のコマンドでトークンを生成します:
Agent バックエンドと同梱のサンドボックス(local_sandbox)で同じ値を使うよう、docker/.env に設定してください。この変数は旧変数 DIFY_AGENT_SHELLCTL_AUTH_TOKEN に代わるものです。この変数が未設定または空の場合、Compose は引き続き docker/.env から旧変数を読み取ります。 envs/core-services/dify-agent.env だけに設定した値は反映されません。そこに設定している場合は、値を docker/.env に移し、dify/docker で docker compose up -d を実行してください。

NEXT_PUBLIC_ENABLE_AGENT_V2

デフォルト値:true(Docker Compose) 新しい Agent を Web UI に表示します。表示されるのは、メインナビゲーションの Agents 項目と、Workflow アプリのノード一覧にある新しい Agent ノードです。この変数は旧変数の ENABLE_AGENT_V2 に代わるもので、現在の Compose ファイルでは ENABLE_AGENT_V2 は効果がありません。 docker/envs/core-services/web.env で false に設定すると、新しい Agent が非表示になり、クラシック Agent ノードにフォールバックします。再表示するには true に戻します。どちらの場合も、web コンテナを再作成してから、ブラウザを強制リロードしてください:

NEXT_PUBLIC_ENABLE_AGENT_V2_IN_CHATFLOW

デフォルト値:false true にすると、Chatflow アプリのノード一覧にも新しい Agent ノードが表示されます。NEXT_PUBLIC_ENABLE_AGENT_V2 が true の場合のみ有効です。

UPLOAD_SKILL_FILE_SIZE_LIMIT

デフォルト値:50 スキルパッケージ(.zip または .skill)の最大サイズを MB 単位で指定します。Agent にアップロードする場合と、スキルライブラリへインポートする場合の両方に適用されます。上限を超えるパッケージはサイズエラーで拒否されます。 100 より大きくする場合は、NGINX_CLIENT_MAX_BODY_SIZE も同じ値以上に設定してください。設定しないと、Nginx が 413 エラーでアップロードを拒否します。 この環境変数が制限するのは、パッケージファイル自体のサイズだけです。パッケージの中身には、バイト単位で設定する別の上限があります:

Agent とアプリのパッケージ制限

これらの制限は、Agent に限らず、すべてのアプリパッケージ(.ifpkg)に適用されます。どのアプリタイプも、デフォルトではこの形式でエクスポートされるためです。制限はエクスポート時とインポート時の両方でチェックされ、ファイルとしてアップロードする場合も URL からインポートする場合も対象です。いずれかの制限を超えるパッケージは、超えた制限を引き上げるまで、エクスポートやインポート全体が失敗します。 100 MB を超えるパッケージをアップロードする場合は、NGINX_CLIENT_MAX_BODY_SIZE も引き上げてください。引き上げないと、Nginx が先にリクエストを拒否します。 パッケージに同梱する各スキルも、スキルの制限 を満たす必要があります:
  • インポート時、UPLOAD_SKILL_FILE_SIZE_LIMIT を超えるスキルがあると、インポート全体が失敗します。SKILL_PACKAGE_* の制限を超えるスキルはスキップされ、インポートは警告付きで完了します。そのスキルを取り込むには、超えた制限を引き上げてから、パッケージを再度インポートしてください。
  • エクスポート時、SKILL_PACKAGE_* の制限を超えるスキルがあると、その制限を引き上げるまでエクスポート全体が失敗します。

AGENT_BACKEND_BASE_URL

デフォルト値:http://agent_backend:5050 API が Agent バックエンドにアクセスするためのアドレスです。Docker Compose ではデフォルトのままにします。 その他の変数は、同梱のサービスを設定するか、既存の Compose 値から導出されるため、通常は変更不要です。

DIFY_AGENT_RUNTIME_BACKEND

デフォルト値:local Agent のサンドボックスをどこで実行するかを選択します:
  • local:同梱のサンドボックスコンテナを使います。
  • e2b:Agent ごとのサンドボックスを E2B のクラウド VM で実行します。同梱コンテナより強い分離が得られます。
  • openshell:自社で運用する NVIDIA OpenShell ゲートウェイを使い、サンドボックスを自社のインフラ上で実行します。
この変数と 2 つのコールバックアドレス(DIFY_AGENT_STUB_API_BASE_URL と DIFY_AGENT_SANDBOX_FILES_BASE_URL)は、envs/core-services/dify-agent.env で設定します。 リモートバックエンドごとに、専用の変数グループがあります:
docker/docker-compose.e2b.yaml オーバーレイは、空の専用 PostgreSQL ボリュームで E2B をテストするためのものです。既存のデプロイには適用しないでください。
openshell に切り替える前に、次の準備を済ませてください:
  • agent_backend コンテナから到達できる OpenShell ゲートウェイ(バージョン 0.0.106 以降)を用意します。
  • ゲートウェイの認証情報として、Bearer トークン、mTLS クライアント証明書のペア、またはその両方を用意します。Compose には証明書のマウント設定が含まれていないため、ファイルを読み取り専用で agent_backend に自分でマウントし、UID 1001 から読み取れるようにします。
  • ゲートウェイがサンドボックスの起動に使うランタイムイメージを用意します。
  • Agent が会話をまたいで保持する永続ファイル用に、共有ボリュームを用意します。docker compose down -v で削除されないよう、Compose の外で作成します。互いを信頼できない複数のテナントが同じデプロイを使う場合は、テナントごとに OpenShell ワークスペースとボリュームを分けてください。共有ボリュームでは、あるテナントが別のテナントの永続ファイルにアクセスすることを確実には防げません。
  • サンドボックスから Dify へ戻るネットワーク経路を確保します:
    • サンドボックスから到達できるコールバックアドレスを用意します。
    • Agent バックエンドの /agent-stub パスへのルートを用意します。ベースの Compose ファイルは、Agent バックエンドのポート 5050 を公開しません。このポートは Agent の実行を開始する API も提供しているため、リバースプロキシなどを使って /agent-stub だけを公開します。
OpenShell に切り替えるには、次の手順を実行します:
  1. OpenShell セットアップガイド を参照して、ゲートウェイと上記の準備をすべて整えます。ガイドには、ランタイムイメージのビルド、ボリュームの初期化、証明書のマウント、Kubernetes でのセットアップ、スモークテストの手順が記載されています。
  2. envs/core-services/dify-agent.env で DIFY_AGENT_RUNTIME_BACKEND を openshell に設定し、以下の変数を入力します。
  3. docker compose up -d で Agent バックエンドを再作成します。必須の値が欠けているか、形式が正しくない場合、Agent バックエンドは起動しません。
  4. Agent を実行して、設定を確認します。Agent バックエンドが初めてゲートウェイに接続するのは、Agent の実行時か、Agent のビルドチャットで 適用 をクリックしたときです。そのため、エンドポイント、認証情報、イメージの誤りは、その時点で初めて実行や適用の失敗として表面化します。
サンドボックスは実行が終わっても、Dify が削除するまでゲートウェイ上で動き続けます。ゲートウェイの容量は、アクティブなサンドボックスだけでなく、アイドル状態のサンドボックスも見込んで計画してください。同梱サンドボックスの外向きプロキシは、OpenShell サンドボックスには適用されません。ネットワークアクセスを制限するには、DIFY_AGENT_OPENSHELL_EGRESS_ALLOW を設定してください。

Agent トラジェクトリのエクスポート

すでに運用しているトレーシングバックエンドで Agent の動作を確認するには、トラジェクトリのエクスポートを有効にします。有効にすると、Agent バックエンドは Agent 実行のトレースを OTLP/HTTP で OpenTelemetry コレクターに送信します。トレースには、モデルへのリクエストとツール呼び出しが含まれます。デプロイ内のすべてのワークスペースの実行が、1 つのコレクターに届きます。 各スパンには、ワークスペース、アプリ、Agent、エンドユーザー、会話、ワークフロー実行、ノードの ID が付与されます。dify.app_id や dify.conversation.id などの属性で、トレースを 1 つのアプリや 1 つの会話に絞り込めます。これらの ID は、コンテンツのエクスポートを無効にしていてもエクスポートされます。 トラジェクトリのエクスポートは、API と Worker の OpenTelemetry 計装 とは別の仕組みです。 一方、LLMOps トレース配信 の設定はトラジェクトリのエクスポートに影響します。LLMOps トレース配信は、アプリ作成者がアプリごとに Langfuse などのプロバイダーを選んで設定するものです。LLMOps トレース配信で Agent トレースを有効にすると、アプリでトレースされる実行は、そのアプリのトレースプロバイダーにだけ送られます。それ以外の Agent 実行はコレクターに届きます。 有効にするには、次の手順を実行します:
  1. docker/envs/core-services/dify-agent.env で、DIFY_AGENT_TRAJECTORY_ENABLED を true に、DIFY_AGENT_TRAJECTORY_OTLP_TRACES_ENDPOINT をコレクターのトレース URL に設定します。認証情報が必要な場合は DIFY_AGENT_TRAJECTORY_OTLP_HEADERS に指定します。 Agent バックエンドは api-worker.env を読み込まないため、これらの変数を api-worker.env に設定しても反映されません。
  2. docker compose up -d で Agent バックエンドを再作成します。値が不正な場合、Agent バックエンドは起動せず、修正するまで Agent の実行は失敗します。
  3. ツールを呼び出すタスクを Agent に実行させ、トレーシングバックエンドでサービス名 dify-agent-trajectory のツール呼び出しスパンを探します。
DIFY_AGENT_TRAJECTORY_INCLUDE_CONTENT を true にすると、すべてのワークスペースのプロンプト、システムインストラクション、モデルの応答、ツールの引数と結果がコレクターに送られます。コレクターへのアクセスは、会話そのものと同じように制限してください。

データベースサービス

Docker Compose でデータベースと Redis のコンテナを直接設定します。「ミドルウェアスタック」と記した行は、ソースコードからのデプロイ で起動するスタックにのみ適用され、そのスタックの middleware.env で設定します。フル構成の Compose スタックでは、これらのサービスは内部ネットワークに留まります。

サンドボックスサービス

sandbox サービスは、コード実行ノード、テンプレートノード、Jinja2 プロンプト、組み込みの Code ツールを実行します。 デフォルトの API キーを置き換えるには、docker/.env で SANDBOX_API_KEY と CODE_EXECUTION_API_KEY に同じ推測されにくいシークレットを設定し、docker compose up -d を実行します。値が異なると、コード実行ノードとテンプレートノードが HTTP 401 エラーで失敗します。 SANDBOX_ENABLE_NETWORK=true のままにしてください。Dify は、コードがネットワーク通信を行わない場合でも、サンドボックスでの実行ごとにネットワークアクセスを要求します。false にすると、これらの機能は network is disabled, please enable it in the configuration エラーで失敗します。 サンドボックス内のコードは、インターネットに直接アクセスできません。外向きの HTTP と HTTPS のリクエストは SSRF プロキシを経由します。一方、同じ内部ネットワーク(ssrf_proxy_network)上の API、ワーカー、プラグインデーモンなどのサービスには直接接続できます。コードからこれらへの接続を禁止する必要がある場合は、サンドボックスのネットワークを独自に隔離してください。

Nginx リバースプロキシ

HTTPS を有効化した後、 共通変数 の URL 変数(例:CONSOLE_API_URL、CONSOLE_WEB_URL)も https:// を使用するように更新してください。

Certbot 設定

RESPECT_XFORWARD_HEADERS_ENABLED

デフォルト値:Docker Compose では true、ソースコードからのデプロイでは false 有効にすると、Dify は API の直前にあるプロキシが送る X-Forwarded-For ヘッダーから、各ユーザーの IP アドレスを取得します。 Docker Compose を Cloudflare やロードバランサーなどのプロキシの背後で運用する場合は、この変数を有効のままにします。そのうえで、同梱の Nginx がプロキシを信頼するよう設定 してください。設定が済むまでは、すべてのユーザーがプロキシのアドレスからのアクセスとして扱われます。サインインメールの送信制限なども、そのアドレス単位で全ユーザーが共有することになります。
有効にしている間は、API に直接接続できるものであれば、Dify が認識するアドレスを自由に指定できてしまいます。偽装されたアドレスは IP 単位のレート制限をすり抜けられるうえ、アカウントの最終サインイン IP などの記録にも残ります。Docker Compose は API のポートを公開していません。ただし、同じ Docker ネットワーク上のコンテナ(コードサンドボックスなど)からは直接接続できます。Docker ネットワークを internal にしても、これらの接続は防げません。API への直接接続は、信頼できる呼び出し元だけに許可してください。これらのコンテナで信頼できないコードを実行する場合は、ネットワークやファイアウォールのルールで隔離してください。これらのコンテナから API へのリクエストがそれでも必要な場合は、すべて X-Forwarded-For を書き換えるゲートウェイを通してください。すでに API のポートを公開している場合は、この変数を無効にするのではなく、ポートを閉じてください。無効にすると、すべてのユーザーが Nginx のアドレスからのアクセスとして扱われます。
ソースコードからのデプロイでは、API の前段にプロキシが 1 つだけあり、API へのアクセスがそのプロキシ経由に限られる場合に有効にしてください。そのプロキシは X-Forwarded-For を設定している必要があります。

SSRF プロキシ

内部/プライベートネットワークへのリクエストをブロックする Squid ベースの SSRF プロキシコンテナの設定です。

Docker Compose

Compose の設定は docker/.env に記述してください。Compose は、コンテナを起動する前にこれらの設定を読み込みます。 DB_TYPE や VECTOR_STORE を変更する際は、それに合わせて COMPOSE_PROFILES も更新してください。手順は データベース設定 と VECTOR_STORE を参照してください。

モデルプロバイダーとツールの表示順設定

アプリインターフェースで利用可能なツールとモデルプロバイダーおよびその表示順をカスタマイズします。カンマ区切りの値を使用し、項目間にスペースを入れないでください。

プラグインデーモン設定

プラグインデーモンは、プラグインのライフサイクル(インストール、実行、アップグレード)を管理する独立したサービスです。API は HTTP 経由で通信します。

Creator Center 設定

Creator Center(creators.dify.ai)は、Dify アプリをテンプレートとして提出する窓口です。提出されたテンプレートはレビューを経て Dify マーケットプレイスに掲載されます。Dify コンソールから Creator Center を開くと、新しいブラウザタブに表示されます。 スタジオの マーケットプレイスに公開 アクションは、アプリをアプリパッケージ(.ifpkg)としてエクスポートし、Creator Center にアップロードします。ユーザーは Creator Center で提出を完了します。手順は アプリをマーケットプレイスに公開 を参照してください。

OTLP / OpenTelemetry 設定

OpenTelemetry は分散トレーシングとメトリクス収集を提供します。有効時、Dify は Flask を計装し、テレメトリデータを OTLP コレクターにエクスポートします。

その他

定期タスク設定

Dify は Celery Beat を使用して、設定可能なスケジュールでバックグラウンドメンテナンスタスクを実行します。

レコード保持とクリーンアップ

古いメッセージとワークフロー実行レコードの定期クリーンアップを制御します。保持期間を超えたレコードはバッチ単位で削除されます。

Aliyun SLS ログストア設定

データベースの代わりにワークフロー実行ログを外部に保存するための Aliyun Simple Log Service とのオプション統合。ログストア実装を使用するようにリポジトリ設定変数を設定して有効化します。

イベントバス設定

API と Celery ワーカー間の Redis ベースのイベント転送です。

ベクトルデータベースサービス設定

これらの変数は、ベクトルデータベースのコンテナ自体を設定します。
認証を必須にするには、docker/envs/vectorstores/weaviate.env で WEAVIATE_AUTHENTICATION_ANONYMOUS_ACCESS_ENABLED=false を設定します。同じファイルで WEAVIATE_API_KEY に推測されにくいシークレットを設定してください。その値を WEAVIATE_AUTHENTICATION_APIKEY_ALLOWED_KEYS にも含めます。キーを置き換えるだけでは、匿名アクセスは有効なままです。
OPENSEARCH_MEMLOCK_* と OPENSEARCH_NOFILE_* は docker/.env で設定してください。Compose はサービスファイルを読み込む前にこれらを読み取ります。
これらの変数は docker/.env で設定してください。Compose はサービスファイルを読み込む前にこれらを読み取ります。

プラグインデーモンストレージ設定

プラグインデーモンは異なるストレージバックエンドにプラグインパッケージを保存できます。PLUGIN_STORAGE_TYPE に一致するプロバイダーのみを設定してください。
最終更新日 2026年11月4日