このドキュメントは AI によって自動翻訳されています。不正確な部分がある場合は、英語版 を参照してください。
デプロイ前の準備
ハードウェア
- CPU：2 コア以上
- RAM：4 GiB 以上
ソフトウェア
Docker と Docker Compose 2.35.0 以降をインストールし、Docker デーモンを起動してください。Dify のダウンロードには Git、Agent のローカルサンドボックス用トークンの生成には OpenSSL も必要です。
開始前に Compose のバージョンを確認します：
デプロイと起動
既存のデプロイでは、設定とデータを維持するため、この手順ではなく アップグレード に従ってください。
1
Dify リリースの取得
Dify のリリース からバージョンを選び、
<version> をそのタグに置き換えてクローンします：2
起動設定
テンプレートから設定ファイルを作成します：Agent のローカルサンドボックス用のトークンを生成します：
.env の DIFY_AGENT_LOCAL_SANDBOX_AUTH_TOKEN に、出力された値を設定します。Agent バックエンドとローカルサンドボックスの起動には、この共有トークンが必要です。3
サービスの起動と確認
dify/docker で次のコマンドを実行します：Up または healthy と表示されていれば正常です。init_permissions タスクはストレージの権限を準備するために 1 回だけ実行され、完了すると Exited (0) と表示されます。アクセス
ブラウザでhttp://localhost/install を開いて管理者アカウントを作成し、http://localhost でサインインします。
リモート環境では、localhost をサーバーの IP アドレスまたはドメインに置き換えてください。デフォルトの HTTP ポートは 80 です。ポート 80 が使用中の場合は、docker/.env の EXPOSE_NGINX_PORT に別のポートを設定し、アドレスにそのポート番号を付けてください。
カスタマイズ
デプロイ全体に関わる設定はdocker/.env に記述します。Compose のプロファイル、公開ポート、マウントパス、ヘルスチェックのスケジュール設定のほか、デプロイのセキュリティ強化 で設定する共有の認証情報も対象です。
それ以外の設定は、サービスごとに分かれています。ほとんどのサービスは、docker/envs/ 内にある同梱の .defaults ファイルを読み込みます。このファイルは編集せず、コメントに記載されたローカルの .env ファイルに変更を書き込んでください。API、ワーカー、定期タスクで共通の設定は、envs/core-services/api-worker.env に記述します。
たとえば、Nginx のリクエストボディの上限を 200M に引き上げるには、dify/docker で次の手順を実行します：
1
上書き値の設定
envs/infrastructure/nginx.env がない場合は作成します：envs/infrastructure/nginx.env に次の値を設定します：2
変更の適用
設定を検証し、影響を受けるコンテナを再作成します：
docker compose restart ではなく up -d を使ってください。restart では、コンテナは古い環境変数をそのまま使います。3
適用値の確認
Nginx が使用している設定を確認します：出力に
client_max_body_size 200M; が含まれていれば正常です。別の値が表示される場合は、まず docker/.env に上書き設定がないか確認します。値の設定元になりうるその他の場所は、優先順位 を参照してください。デプロイのセキュリティ強化
他の人がアクセスできる状態にする前に、HTTPS を設定し、docker/.env にある同梱の開発用認証情報を置き換えてください：
- データベースと Redis：
DB_PASSWORDとREDIS_PASSWORDを置き換えます。 - コード実行サンドボックス：
SANDBOX_API_KEYとCODE_EXECUTION_API_KEYに、同じ推測されにくいシークレットを設定します。詳しくは サンドボックスサービス を参照してください。 - Weaviate：
WEAVIATE_API_KEYに推測されにくいシークレットを設定し、同じ値をWEAVIATE_AUTHENTICATION_APIKEY_ALLOWED_KEYSにも含めます。認証を必須にするため、WEAVIATE_AUTHENTICATION_ANONYMOUS_ACCESS_ENABLED=falseも設定します。詳しくは ベクトルデータベースサービス設定 を参照してください。 - プラグインデーモン：
PLUGIN_DAEMON_KEYとPLUGIN_DIFY_INNER_API_KEYに、それぞれ別の推測されにくい値を設定します。詳しくは プラグインデーモン設定 を参照してください。 - Agent：
DIFY_AGENT_API_TOKENを置き換え、DIFY_AGENT_SERVER_SECRET_KEYを指定の形式で生成します。起動時に生成したDIFY_AGENT_LOCAL_SANDBOX_AUTH_TOKENはそのまま使います。
docker compose up -d で新しい値を適用します。ただし、データベースのパスワードは例外です。データベースの初期化後は、先にデータベースサーバー側でパスワードを変更し、その後 DB_PASSWORD を同じ値に更新してください。
SECRET_KEY は変更しないでください。自分で設定しない限り、Dify は初回起動時にランダムなキーを生成し、データと一緒に保存します。後から設定や変更を行うと、古いキーで署名されたトークンやファイルリンクが使えなくなります。影響を受ける範囲は SECRET_KEY を参照してください。アップグレード
Dify のリリース で対象のリリースを選び、まずそのアップグレードガイドを確認してください。 以下の Compose コマンドはすべて、既存のデプロイと同じプロジェクト名とファイルで実行してください。-p、-f、COMPOSE_PROJECT_NAME を指定している場合も、同じ値を使います。これにより、名前付きボリュームが引き続き接続されます。
1
デプロイのバックアップ
-
ファイルのコピー中にデータベースへの書き込みが発生しないよう、
dify/dockerでデプロイを停止します：停止できない場合は、代わりに各データベース専用のダンプツールでバックアップしてください。 -
docker/.env、ローカルのサービス用.envファイル、カスタム Compose ファイル、永続データをバックアップします。永続データにはdocker/volumes/のほか、外部のデータベースやストレージも含みます。 -
デプロイに
local_sandboxが含まれる場合は、その名前付きボリュームもバックアップします。マウント先は/home/difyと/workspaceです。ボリューム名には Compose プロジェクトのプレフィックスが付くため、次のコマンドで一覧を確認してください： -
更新後の比較用に、
docker compose configの出力を保存します。出力にはシークレットが含まれるため、非公開で保管してください。
2
新しいリリースへの更新
ローカルの その後、
.env ファイルと docker/volumes/ 内のデータは Git の追跡対象外のため、リリースをチェックアウトしてもそのまま残ります。docker-compose.yaml などの追跡対象ファイルを編集している場合は、先にその変更を stash してください。リポジトリのルートで次のコマンドを実行します：git stash pop などで新しいリリースのファイルに変更を適用し直し、競合があれば解決してください。3
設定の確認
docker/.env.example と既存の docker/.env を比較します。各ローカルサービスファイルも、対応する .defaults または .env.example テンプレートと比較してください。必要な設定は既存のファイルに反映してください。テンプレートで上書きコピーすると、独自の上書き設定が失われます。テンプレートで設定名が変わっている場合は、新しい名前を使います。Container variable mappings の下にある行は変更しないでください。既存のデータベースと、ナレッジベースが引き続き使うすべてのベクトルストアは、接続設定と Compose プロファイルごと維持してください。DB_TYPE や VECTOR_STORE を変更しても、データは移行されません。最後に、新しい docker compose config の出力を保存しておいたコピーと比較し、認証情報、ボリュームパス、プロファイル、カスタマイズした設定を確認します。4
アップグレードの適用と確認
dify/docker で次のコマンドを実行します：Up または healthy、init_permissions に Exited (0) と表示されていれば正常です。その後、Dify を開き、カスタマイズした設定を使う機能を試してください。