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

​
デプロイ方法

​
旧バージョンのインストール

--branch フラグを使用して特定のバージョンをインストールします：
残りのセットアップは最新版のインストールと同じです。

​
ZIP アーカイブを使用したインストール

ネットワーク制限がある環境や git が利用できない場合：
または、別のデバイスで ZIP をダウンロードして手動で転送することもできます。 アップグレードするには：

​
クローン時の「Remote branch null not found」エラー

Docker Compose で Dify をデプロイする のクローンコマンドは、GitHub API を通じて Dify の最新バージョンを取得します。このリクエストが失敗すると（未認証リクエストに対する GitHub のレート制限が主な原因）、jq が null を出力し、git は fatal: Remote branch null not found in upstream origin を報告します。 代わりに、バージョンを明示してクローンしてください。Dify releases で最新バージョンを確認し、次のコマンドを実行します：
--branch なしでもクローンできます。main ブランチの Compose ファイルは最新リリース版のイメージを指定しているため、起動されるのはリリース版です。ただし、Compose ファイルや環境変数テンプレートなどのデプロイ用ファイル自体は開発中の内容であり、リリース版と異なる場合があります。

​
バックアップ手順

​
アップグレード前のバックアップ作成

データ損失を防ぐため、アップグレード前は必ずバックアップを行ってください：
これにより、復元しやすいタイムスタンプ付きのバックアップが作成されます。

​
リバースプロキシ設定

​
フロントエンドとバックエンドが異なるサブドメインで動作する場合のログインセッション切れ

Web と API を異なるサブドメインに分けてリバースプロキシ経由で公開している場合、認証 Cookie が両方のホストに届きません。たとえば UI が app.example.com、バックエンドが api.example.com の構成です。ログインは成功したように見えても、次のリクエストでセッションが切れます。 .env で両方の変数を設定し、Dify を再起動してください：
  • COOKIE_DOMAIN：共有するトップレベルドメインを指定します（例：example.com）。先頭のドットは省略可能です。
  • NEXT_PUBLIC_COOKIE_DOMAIN：1 を設定すると、フロントエンドでサブドメイン間の Cookie 共有が有効になります。
Cookie はトップレベルドメインを越えて共有できないため、フロントエンドとバックエンドは同じ登録可能ドメイン内にある必要があります。詳細は 環境変数 を参照してください。

​
Cloudflare などのプロキシ背後で全ユーザーのサインインメールがブロックされる問題

全ユーザーが一斉に、サインインコードやパスワードリセットのメールを受け取れなくなります。表示されるメッセージは「Too many emails have been sent from this IP address recently. Please try again later.」です。1.18.0 以降、同梱の Nginx の前段に Cloudflare やロードバランサーなどのプロキシを置いているデプロイでは、この問題が起こり得ます。 Dify は、各ユーザーの IP アドレスを同梱の Nginx から受け取ります。プロキシの背後では、Nginx にはプロキシのアドレスしか見えません。そのため、プロキシのアドレスに対する制限を全ユーザーで共有することになります。 構成によっては、プロキシが同梱の Nginx を経由せず、api と web のコンテナへ直接転送します。Cloudflare Tunnel や Nginx Proxy Manager の一部の構成がこれに当たります。この場合は以下の手順を飛ばし、代わりに次の点を確認してください：
  • プロキシが X-Forwarded-For を設定していること。設定していないと、すべてのユーザーがプロキシのアドレスからのアクセスとして扱われます。
  • API にはプロキシ経由でしかアクセスできないこと。API に直接アクセスできる人は、Dify が認識するアドレスを自由に指定できてしまいます。
プロキシが同梱の Nginx に転送している場合は、信頼するプロキシを Nginx に設定します：
1

プロキシのアドレスを確認

Nginx のアクセスログ（docker compose logs nginx）では、各行の先頭にプロキシの接続元アドレスが記録されています。プロキシが同じサーバー上にある場合も、127.0.0.1 と仮定せず、ログで確認してください。Cloudflare が Nginx に直接接続している場合、この手順は飛ばしてください。
2

real-ip.conf を作成

構成に合わせて docker/nginx/conf.d/real-ip.conf を作成します。Nginx はこのディレクトリ内の .conf ファイルをすべて読み込むよう設定済みです。作成したファイルは、アップグレード後もそのまま残ります。
X-Forwarded-For を設定するプロキシの場合：
0.0.0.0/0、::/0、および信頼できないマシンも接続しているネットワークは、決して信頼しないでください。信頼すると、Nginx にアクセスできる人なら誰でも、Dify が認識する IP アドレスを自由に指定できてしまいます。
3

Nginx をリロード

これで、docker compose logs nginx に出力される新しい行の先頭が、プロキシではなく各ユーザー自身のアドレスになるはずです。ユーザーはブロックされたアドレスを共有しなくなるため、すぐにメールを再リクエストできます。
最終更新日 2026年10月23日