メインコンテンツへスキップ
このドキュメントは AI によって自動翻訳されています。不正確な部分がある場合は、英語版 を参照してください。
Dify はデフォルト設定でそのまま動作します。デプロイをカスタマイズするには、関連するファイルの環境変数を編集します:
  • 必須の起動値 は docker/.env にあります(デプロイ時に docker/.env.example からコピーして作成したファイル)。直接編集します。
  • オプションまたはプロバイダー固有の設定 は docker/envs/ にテンプレートとして用意されています。デフォルト値を上書きするには、対応するテンプレートをコピーし(.example 拡張子を外す)、コピーを編集します。例:
docker/.env の値は、docker/envs/*.env ファイルの値より優先されます。
Dify をアップグレードした後、各 .env.example を対応する .env と比較し、新規または変更された変数を確認してください。

共通変数

これらの 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

デフォルト値:(.env.example にプリセット;本番環境では必ず置き換えてください) セッション Cookie 署名、JWT 認証トークンに使用されます。さらに、ファイル URL 署名(HMAC-SHA256)とサードパーティ OAuth 資格情報の暗号化(AES-256)にも使用されます。初回起動前に、強力なキーを生成してください:
デプロイ後にこのキーを変更すると、すべてのユーザーが即座にログアウトされ、すべてのファイル URL が無効になり、OAuth を使用するプラグイン連携が壊れます。暗号化された資格情報は復元できなくなります。

PASSWORD_PEPPER

デフォルト値:(空) メンバーが Dify へのサインインに使うパスワードに混ぜ込む、サーバー側の秘密値です。流出したデータベースのコピーだけでは、パスワードを解読できなくなります。空のままなら、動作は変わりません。 ペッパーを使う場合は、初回セットアップで管理者アカウントを作成する前に設定してください。十分なエントロピーを持つランダムな値を生成します。例:
Docker Compose では、docker/envs/core-services/api.env に設定します(ファイルがまだない場合は api.env.example から作成してください)。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

デフォルト値:worker(worker サービスの env ファイルに設定された値。変数が未設定の場合、コンテナは API サーバーを起動) dify-api イメージがコンテナ起動時に実行するプロセスを選択します。3 つの env サンプルファイルがそれぞれのサービス向けの値を設定しています:worker.env.example は worker、api.env.example は api、worker-beat.env.example は beat。指定できる値:
  • api(空または認識されない値も同様):API サーバー
  • worker:Celery タスクコンシューマー
  • beat:定期タスクディスパッチャー
  • job:Flask CLI コマンドを 1 つ実行して終了
  • migration:MIGRATION_ENABLED=true と併用し、データベース移行後に終了
付属の Compose ファイルはサービスごとに適切な値を設定済みのため、変更が必要なのは Kubernetes などのカスタム構成のみです。誤った値ではコンテナが別のプロセスを実行します。worker がないと、インデックス作成やメールのタスクが処理されずに滞留します。

API ツール設定

データベース設定

データベースはデフォルトで PostgreSQL を使用します。OceanBase、MySQL、seekdb もサポートされています。

コネクションプール

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 ベクトルデータベースバックエンドを選択します。データセットに既にインデックスがある場合、データセットに保存されたタイプがこの設定より優先されます。Docker Compose でプロバイダーを切り替える場合、COMPOSE_PROFILES がこの値に基づいて対応するコンテナを自動起動します。 サポートされる値:weaviate、oceanbase、seekdb、qdrant、milvus、myscale、relyt、pgvector、pgvecto-rs、chroma、opensearch、oracle、tencent、elasticsearch、elasticsearch-ja、analyticdb、couchbase、vikingdb、opengauss、tablestore、vastbase、tidb、tidb_on_qdrant、baidu、lindorm、huawei_cloud、upstash、matrixone、clickzetta、alibabacloud_mysql、iris、hologres。
seekdb は OceanBase のライト版であり、同じ接続設定を共有します。

ナレッジベース設定

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

モデル設定

マルチモーダル設定

すべてのアップロードサイズ制限は 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/shared.env にこれらの変数を設定します。

インデックス作成

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

ワークフロー生成

トークンと招待

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

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

以下の設定は、API と Worker がサンドボックスに接続する方法を指定します。サンドボックスは、コードノード(Python、JavaScript)とテンプレート変換ノード(Jinja2)を分離して実行する独立したサービスです。

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

API と Worker は、コードノードとテンプレート変換ノードの出力にこれらの制限を適用します。サンドボックスサービスはこれらの変数を読み取りません。変更を反映するには、サンドボックスではなく API と Worker を再起動してください。

ワークフローランタイム

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

ワークフロー実行データを処理するバックエンド実装を選択します。デフォルトの 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

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

DIFY_AGENT_API_TOKEN

デフォルト値:(.env.example に開発用トークンを設定済み。本番環境では必ず置き換えてください) Dify API が Agent バックエンドの実行 API を呼び出す際に提示する Bearer トークンです。Compose は同じ値を両方のサービスに渡すため、一度設定するだけで一致が保たれます。 デフォルトは公開された開発用トークンのため、デプロイはそのまま起動します。ただし、Agent バックエンドに到達でき、トークンを知っていれば誰でも実行を開始できます。本番環境で使用する前に、独自のランダムな値に置き換えてください。

DIFY_AGENT_LOCAL_SANDBOX_AUTH_TOKEN

デフォルト値:(空;ランタイムバックエンド がデフォルトの local の場合は必須) 同梱のサンドボックスが Agent バックエンドを認証するための共有シークレットです。空のままだと、両方のサービスが起動直後に終了し、再起動を繰り返します。Dify を起動する前に設定してください。 docker/.env で一度設定すれば、Compose が両方のサービスに渡します。docker/envs/ 配下のファイルにだけ設定した値は反映されません。 次のコマンドで生成できます:
旧 DIFY_AGENT_SHELLCTL_AUTH_TOKEN を置き換えます。旧名も互換エイリアスとして引き続き使えます。

NEXT_PUBLIC_ENABLE_AGENT_V2

デフォルト値:true 新しい Agent を Web UI に表示します。メインナビゲーションの Agents 項目と、ワークフローのノード一覧の新しい Agent ノードです。false にすると非表示になり、クラシック Agent ノードにフォールバックします。ENABLE_AGENT_V2 を置き換えるもので、こちらは引き続きフォールバックとして機能します。

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)は、docker/.env で設定します。Compose はこの 3 つを docker/.env から Agent バックエンドに渡すため、envs/core-services/dify-agent.env に書いた値は反映されません。 リモートバックエンドごとに、専用の変数グループがあります:
docker/docker-compose.e2b.yaml オーバーレイが、このバックエンド向けに Compose 構成を調整します。
openshell に切り替える前に、次の準備を済ませてください:
  • agent_backend コンテナから到達できる OpenShell ゲートウェイ(バージョン 0.0.106 以降)を用意します。
  • ゲートウェイの認証情報として、Bearer トークン、mTLS クライアント証明書のペア、またはその両方を用意します。Compose には証明書のマウント設定が含まれていないため、ファイルを読み取り専用で agent_backend に自分でマウントし、UID 1001 から読み取れるようにします。
  • ゲートウェイがサンドボックスの起動に使うランタイムイメージを用意します。
  • Agent が会話をまたいで保持する永続ファイル用に、共有ボリュームを用意します。docker compose down -v で削除されないよう、Compose の外で作成します。
  • サンドボックスから Dify へ戻るネットワーク経路を確保します:
    • サンドボックスから到達できるコールバックアドレスを用意します。
    • Agent バックエンドの /agent-stub パスへのルートを用意します。ベースの Compose ファイルは、Agent バックエンドのポート 5050 を公開しません。このポートは Agent の実行を開始する API も提供しているため、リバースプロキシなどを使って /agent-stub だけを公開します。
OpenShell に切り替えるには、次の手順を実行します:
  1. OpenShell セットアップガイド を参照して、ゲートウェイと上記の準備をすべて整えます。ガイドには、ランタイムイメージのビルド、ボリュームの初期化、証明書のマウント、Kubernetes でのセットアップ、スモークテストの手順が記載されています。
  2. docker/.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 は、コンテンツのエクスポートを無効にしていてもエクスポートされます。 トラジェクトリのエクスポートは、LLMOps トレース配信 とは別の仕組みです。LLMOps トレース配信は、アプリ作成者がアプリごとに Langfuse などのプロバイダーで設定します。API と Worker の OpenTelemetry 計装 とも別で、どちらの設定もトラジェクトリのエクスポートには影響しません。 有効にするには、次の手順を実行します:
  1. docker/.env で、DIFY_AGENT_TRAJECTORY_ENABLED を true に、DIFY_AGENT_TRAJECTORY_OTLP_TRACES_ENDPOINT をコレクターのトレース URL に設定します。認証情報が必要な場合は DIFY_AGENT_TRAJECTORY_OTLP_HEADERS に指定します。 Agent バックエンドは shared.env を読み込まないため、これらの変数を shared.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 スタックでは、これらのサービスは内部ネットワークに留まります。

サンドボックスサービス

サンドボックスは、コードノード(Python、JavaScript、Jinja2)を実行するための隔離されたサービスです。セキュリティのためにネットワークアクセスを無効化できます。

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

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

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

プラグインデーモン設定

プラグインデーモンは、プラグインのライフサイクル(インストール、実行、アップグレード)を管理する独立したサービスです。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 ベースのイベント転送です。

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

ベクトルデータベースコンテナ自体の設定です(Dify クライアント接続ではありません)。選択した VECTOR_STORE の変数のみが関連します。

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

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