Dify セルフホスト完全ガイド2026｜Docker Composeで構築・本番運用・アップグレード

Dify セルフホストは、LLMアプリ開発基盤を「自社の管理下」に丸ごと置くための最短ルートだ。 Difyはクラウド版（dify.ai）もあるが、実務では「顧客データを外部SaaSに置けない」「モデルやコストを自分で握りたい」「社内ネットワーク内で完結させたい」といった理由で、自社サーバに立てたいという需要が非常に大きい。その答えが、Docker Composeを使ったDify セルフホストである。

ただし、Dify セルフホストは「1コンテナをポン」で終わる話ではない。起動すると約11個のコンテナ——アプリ本体・ワーカー・Web UI・プラグインデーモン・PostgreSQL・Redis・ベクトルDB・リバースプロキシ・サンドボックス——が連携して動く、小さな分散システムだ。この記事では、git clone から初期セットアップ、.env の要点、ベクトルDBの選択、リバースプロキシとHTTPS、アップグレードとバックアップ、そして本番公開前のハードニングまでを、公式ドキュメントで裏取りしながら「手を動かせる手順」として解説する。

Difyそのものの全体像（何ができるか・アプリタイプ・RAG・プラグイン）は Dify完全ガイド2026｜オープンソースのLLMOps基盤でAIアプリを構築・自己ホストする をご覧ください。本記事はそのDifyを「Docker Composeで自己ホストする」運用に特化した実践編です。

まず、Dify セルフホストで実際に何が立ち上がるのかを1枚で掴んでおこう。役割ごとに4層で捉えると、後のトラブルシュートや本番設計がぐっと楽になる。

Difyのセルフホストとは——なぜDocker Composeなのか

Dify セルフホストが解くのは、「LLMアプリ基盤を、依存関係ごと自分の環境に再現する」という問題だ。Difyは単体のWebアプリではなく、APIサーバ・非同期ワーカー・Web UI・プラグイン実行環境・リレーショナルDB・キャッシュ・ベクトルDB・リバースプロキシ・コード実行サンドボックスといった複数のコンポーネントが噛み合って動く。これらを個別にインストール・設定するのは骨が折れるが、Docker Composeなら1つの docker compose up -d で全部を正しい順序・正しい接続で立ち上げられる。だから公式もComposeを第一の手段として推している。

自己ホストを選ぶ理由は主に3つだ。① データ主権——顧客データや社内文書を外部SaaSに出さず、自社ネットワーク内に閉じられる。② コストとモデルの制御——利用するLLMやベクトルDBを自分で選び、従量課金の外に置ける。③ カスタマイズ——プラグインや環境変数、前段のプロキシまで自由に手を入れられる。裏返せば、これらの自由と引き換えに運用の責任（アップグレード・バックアップ・監視・セキュリティ）を自分で負うことになる。この記事の後半は、その責任をどう果たすかに紙面を割く。

Dify セルフホストの最短手順——git cloneから初期セットアップまで

まずは最小の立ち上げを通しで確認する。必要なのはDockerとDocker Compose（2.24.0以上）が入った環境だけだ。公式手順はリポジトリを取得し、docker ディレクトリで .env を用意して起動する、というシンプルな流れになっている。

# 1. リポジトリを取得し、docker ディレクトリへ
git clone https://github.com/langgenius/dify.git
cd dify/docker

# 2. 環境変数ファイルを雛形から作成（まずはデフォルトのままでよい）
cp .env.example .env

# 3. 約11コンテナを一括起動（-d はバックグラウンド）
docker compose up -d

起動後、コンテナが全て正常に立ち上がったかを確認する。Difyは api / worker / worker_beat / web / plugin_daemon と、依存する weaviate・db(PostgreSQL)・redis・nginx・ssrf_proxy・sandbox で構成される。

# 状態確認（すべて Up / healthy が理想。Restarting はメモリ不足の疑い）
docker compose ps

# うまく開けないときは api のログを追う
docker compose logs -f api

正常なら、ブラウザで http://localhost/install を開くと初期セットアップ画面が出る。ここで最初の管理者アカウントを作成すると、以降は http://localhost（ポート80）がDifyのコンソールになる。バックエンドAPIは5001番、プラグインデーモンは5003番で動く。ここまでが「立てる」の全工程だ。次からは、この最小構成を実運用に耐える形へ育てていく。

.envの要点とベクトルDBの選択——構成を決める勘所

cp .env.example .env で作った .env は、デフォルトのままでも起動はするが、本番に出す前に必ず見直すべき項目がある。ここは「セルフホストの設計図」だ。

セキュリティ系 — SECRET_KEY はセッションやトークンの署名に使われるため、必ず強固なランダム値に変更する（デフォルトのまま公開するのは危険）。管理者初期化を外部に晒さないよう、公開前にセットアップを済ませておく。

ネットワーク系 — 80番ポートが既存のWebサーバと競合するなら EXPOSE_NGINX_PORT を変更する。HTTPSを前段のプロキシで終端するか、Dify側で扱うかもここで方針を決める。

ベクトルDB系 — DifyはRAGのベクトル検索にベクトルDBを使い、既定はWeaviateだが、VECTOR_STORE を切り替えることで他の選択肢（Qdrant・Milvus・pgvector など）も選べる。すでに社内で運用しているベクトルDBがあるならそれに寄せると、バックアップや監視を既存の仕組みに乗せられる。特にこだわりがなければ既定のWeaviateで十分だ。ベクトル検索とRAGの設計思想は RAG完全ガイド2026 と合わせて考えると、どのベクトルDBが自分の用途に合うか判断しやすい。

ストレージ系 — アップロードした文書やナレッジの実体は storage に保存される。既定はローカルボリュームだが、.env の STORAGE_TYPE をS3互換（Amazon S3・MinIO等）に切り替えることもできる。本番で複数ノードに広げたい、バックアップを既存のオブジェクトストレージ運用に乗せたい、という場合はS3互換に寄せると運用が一段楽になる。単一ノードの小規模ならローカルボリュームのままで問題ない。

ベクトルDBを含むデータ層は、コンテナではなくDockerボリューム（またはS3互換ストレージ）に永続化される。つまりコンテナは使い捨て、データはボリュームで守るという前提で運用設計する。この切り分けが、次のアップグレードとバックアップの土台になる。どのコンポーネントがどこに状態を持つかを最初に把握しておくと、障害時の切り分けが速くなる。

Dify セルフホストの本番化——リバースプロキシ・HTTPS・アップグレード

検証で立てた構成を本番に載せるには、いくつかの「固め」が要る。順に見ていく。全体の運用サイクルは下図のように、初期構築のあとにHTTPS・バックアップ・アップグレードが循環する。

⓪ 規模と処理能力の見積り。 本番化の前に、想定する同時利用者数とドキュメント量をざっくり見積もっておく。Difyの重い処理（RAGのインデックス作成やワークフロー実行）は非同期の worker が担うため、処理が詰まりがちなら worker の並列度やレプリカ数を増やすのが効く。単一ノードのDocker Composeで捌ききれない規模になったら、Kubernetes（Helm）へ移してコンポーネントごとに水平スケールする、という段階的な拡張が現実的だ。最初から作り込みすぎず、ボトルネックが見えてから該当コンポーネントだけ増強するのが、運用コストを抑えるコツになる。

① リバースプロキシとHTTPS。 本番では、前段にnginxやCaddy、あるいはクラウドのロードバランサを置き、TLS証明書で HTTPS化 する。Difyのコンソールとアプリを平文HTTPのまま外部公開してはいけない。プロキシで認証（Basic認証・SSO・IP制限）を挟めば、管理コンソールを不特定多数から隔離できる。

② ファイアウォールとポート。 公開が必要なのは基本的にHTTPS(443)のみで、PostgreSQLやRedis、5001/5003といった内部ポートを外部に開けてはいけない。クラウドならセキュリティグループ、オンプレならファイアウォールで内部ポートを閉じる。

③ アップグレード。 新バージョンは git pull で取得し、docker/ で docker compose down → docker compose pull → docker compose up -d の順で更新する。データはボリュームに残るためコンテナを作り直しても消えないが、メジャー更新では .env.example に新変数が増えることがあるので、更新前に差分を確認して自分の .env に反映する。

# アップグレード手順（docker/ ディレクトリで実行）
git pull                     # 最新のcompose定義と.env.exampleを取得
docker compose down          # 稼働中コンテナを停止・削除（ボリュームは残る）
docker compose pull          # 新しいイメージを取得
docker compose up -d         # 再起動。データはボリュームから復帰

④ バックアップ。 守るべきはコンテナではなくボリュームだ。PostgreSQL（アプリのメタデータ）、ベクトルDB（ナレッジのembedding）、storage（アップロード文書）の3つを定期バックアップする。PostgreSQLは pg_dump、ベクトルDBとstorageはボリュームのスナップショットやファイル同期で退避するのが基本だ。アップグレードの直前には必ずバックアップを取る——これだけで、更新失敗時のリスクが大きく下がる。

⑤ 監視と可観測性。 Difyはコンソール上で、各アプリの実行ログ・トークン消費・レイテンシ・ユーザーからのフィードバックを追える。まずはこの内蔵の監視で、どのプロンプトが遅いか・どこでエラーが出ているかを把握する。さらに踏み込むなら、LangfuseやLangSmithといった外部のLLM可観測性ツールと連携させ、トレースを外部基盤に集約することもできる。本番では「動いているか」だけでなく「いくら使い、どこで詰まっているか」を可視化しておくと、コスト管理と品質改善の両方が回り出す。コンテナ自体の死活は docker compose ps とプロキシのヘルスチェックで監視し、アプリ内部の挙動はDifyの監視で追う、という二段構えが実務的だ。

トラブルシュートとライセンス——公開前に必ず押さえる

最後に、詰まりやすい点と、商用公開で見落とせないライセンスを押さえる。Difyをワークフロー基盤として他ツールと比較したい場合の位置づけも触れておく。

トラブルシュート。 初回起動で http://localhost が開けない原因の大半はポート競合（80番を既存Webサーバが使用）で、docker/.env の EXPOSE_NGINX_PORT を空き番号に変えて起動し直せば解決する。コンテナが Restarting を繰り返すならメモリ不足の疑いが濃く、Docker Desktopのメモリ割当を増やす。個別の原因特定は docker compose logs -f api（または該当サービス名）でログを追うのが定石だ。Difyのファイルアップロードやキュー周りで詰まる既知の事象は Difyのファイルアップロードがキューで詰まる問題の対処 にも整理がある。

ライセンス。 Difyのライセンスは純粋なApache 2.0ではなく Dify Open Source License（Apache 2.0＋追加条項）で、セルフホストでも2つの制限が効く。① マルチテナントSaaS再提供の禁止——書面の許可なく、Difyを複数顧客に貸し出すクラウドサービスとして売ってはいけない。② ロゴ/著作権表示の保持——コンソールやアプリのDifyロゴ・著作権表示を削除・改変してはいけない。判断基準は「あなたの顧客が、Difyの管理画面そのものを触るか？」。顧客が触るのは自社アプリのUIだけで、Difyが裏方に徹しているなら多くの場合セーフだ。自社の業務アプリや社内基盤としての利用は問題ないが、SaaS化を狙うなら公式の商用ライセンスを検討する。

Difyを、n8nやLangflowのようなワークフロー/ノーコード基盤と比較して選びたいなら、AI自動化ツール完全ガイド2026 の俯瞰が役立つ。まずは本記事の手順で docker compose up -d を通し、文書を1つアップロードしてチャットさせるところから始めれば、Dify セルフホストの全体像は自然と手に馴染むはずだ。

参照ソース

・langgenius/dify — GitHub 公式リポジトリ
・Dify 公式ドキュメント（Docker Compose デプロイ）
・Dify docker/.env.example（環境変数リファレンス）
・Dify Open Source License（GitHub LICENSE）