DifyをVPSにDocker Composeでセルフホストする方法

Dify の概要と、実行することになる構成

Dify は、大規模言語モデル上にアプリケーションを構築するためのセルフホスト型プラットフォームです。チャットアプリ、エージェント、検索パイプラインを設計する Web インターフェース、独自のコードから呼び出す API、プロンプト、データセット、モデルキーを一元管理する機能を利用できます。小規模なチームが、スクリプトごとに API キーを分散させず、共有するプライベートな基盤上で全員が開発するためのツールです。agent、tool call、retrieval pipeline などの意味がまだ曖昧であれば、まず これらの概念を基礎から学ぶことで、Dify のビルダー画面を、ラベルのないスイッチが並ぶ画面ではなく、見慣れた設定項目として理解できます。

自分で運用する場合、多くのコンポーネントを管理する必要があります。2026 年 10 月時点で、Dify のドキュメントに記載されたデフォルト構成では、常時稼働するコンテナが 15 個起動し、ファイル権限を設定して終了する 1 回限りのタスクも実行されます。Dify 独自のサービスは 7 個です。API サーバー、websocket サーバー、バックグラウンドワーカー、スケジューラー、Web フロントエンド、プラグインデーモン、エージェントバックエンドです。残りの 8 個は依存サービスです。Postgres データベース、Redis キャッシュ、Weaviate ベクトルデータベース、外部接続の入口となる nginx、2 個のコードサンドボックス、2 個の SSRF プロキシで構成されます。Docker Compose がこれらをすべて接続しますが、実際の構成は大規模です。Dify が示す最小要件は、RAM 4 GiB と CPU 2 コアです。この VPS で別のサービスも実行する場合は、公称値ではなく実測値に基づいて容量を決めてください。PhotoPrism と Immich の実際の RAM 下限は公開されている最小要件を大きく上回るためです。同じサーバーでフォトサーバーを運用すると、最初に Dify のデータベースとベクトルストアがメモリ不足になります。CPU の競合も同様です。90 年代のビデオ店風にした Jellyfin ライブラリは、アートワークを閲覧するだけならほとんど負荷がありません。しかし誰かがトランスコードを開始すると、Dify のワーカー処理はその処理の後ろで待機します。Dify は構築するアプリ数にかかわらずコンテナ数が固定されるため、運用コストの増加は比較的緩やかです。AI の同僚ごとに専用コンテナと専用ブラウザーが割り当てられる OpenBotとは異なり、新しい同僚を追加するたびに必要なメモリが増えることもありません。

Dify はモデル API キーに加えて、検索用に読み込んだ非公開ドキュメントを保持することもあります。そのため、実行するサーバーは最初から機密性の高い環境として扱ってください。このガイドでは Dify をインストールした後、Secret を保持する他のサービスと同じようにセキュリティを強化します。

前提条件

Ubuntu 24.04 を実行する VPS が必要です。RAM は 4 GiB 以上、CPU は 2 コア以上を用意してください。Docker と Docker Compose plugin もインストールします。Dify には Compose 2.24.0 以降が必要です。また、sudo を持つユーザー、または docker group のメンバーシップが必要です。以下の clone コマンドでは git、curl、jq も使用します。Docker を初めて使用する場合は、VPS での Docker Compose の基本で、このガイドが前提とするインストール方法と基本コマンドを確認できます。サーバーを指す domain name も用意しておくと便利です。Dify の前段には bare IP address ではなく TLS を配置するためです。

Step 1: Dify と Compose ファイルを取得する

Dify の Docker 構成はメインリポジトリにあります。開発ブランチではなく最新リリースを clone し、docker ディレクトリに移動します。

git clone --branch "$(curl -s https://api.github.com/repos/langgenius/dify/releases/latest | jq -r .tag_name)" https://github.com/langgenius/dify.git
cd dify/docker
cp .env.example .env

clone 時に「Remote branch null」エラーが表示される場合、GitHub API の検索結果が空です。releases ページからバージョンを選び、--branch に手動で指定してください。

.env ファイルが基本設定です。作業を始める前に内容を確認してください。最初に確認する重要な値は、パスワードと Secret を設定する項目です。SECRET_KEY、Postgres のパスワード、Redis のパスワードが該当します。SECRET_KEY は空の状態で提供されます。このままにすると、Dify が鍵を生成し、ストレージディレクトリに保存します。パスワードは別に扱う必要があります。サンプルファイルでは、Postgres と Redis の両方に同じ difyai123456 を設定し、code sandbox、plugin daemon、Weaviate には固定された公開済みの鍵を設定しています。これらを初期値のままにすることが、セルフホストの Dify が侵害される最も一般的な原因です。独自の Secret key を設定する場合は、次のコマンドで生成します。

openssl rand -base64 42

生成した値を SECRET_KEY に貼り付け、ファイル内のすべてのパスワードと鍵の項目に、強度が高く一意の値を設定してください。Redis のパスワードは CELERY_BROKER_URL 内にも記載されているため、そちらも変更してください。変更しないと worker が Redis に接続できません。

ステップ 2: 起動する

スタックを起動します。

docker compose up -d

初回起動では複数のイメージを取得し、データベースを初期化します。完了まで 1 分ほど待ちます。コンテナが正常な状態か確認します。

docker compose ps

長時間実行する各サービスは running を読み取る必要があります。1 回限りの権限設定タスクは、処理が完了すると終了します。Dify は、デフォルトでポート 80 の組み込み nginx コンテナを介して Web インターフェースを提供します。初回に http://YOUR_SERVER/install へアクセスしたら、管理者アカウントを作成します。ほかの処理がポートへ到達する前に、直ちに作成してください。このアカウントが存在するまでは、ページを開いた誰でもアカウントを取得し、インスタンスを管理できるためです。

ステップ 3: そのまま公開しない。前段に TLS とファイアウォールを配置する

ここで多くの簡易インストールが止まり、多くのインシデントが始まります。Dify 自身の nginx はポート 80 で暗号化されていない HTTP を待ち受け、すべてのインターフェースで接続を受け付けます。また、ポート 443 も公開します。管理者ログイン情報やモデルキーを平文の HTTP で送信したくはありません。内部サービスを外部から到達可能にすることも避ける必要があります。

SSH と Web トラフィックだけを許可する、デフォルト拒否のファイアウォールでサーバーを保護します。

sudo ufw default deny incoming
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

IPv4 だけを対象にしたファイアウォールでは、IPv6 で同じポートが開いたままになることがあります。これは、多くのセルフホスト環境で問題になる IPv6 ファイアウォールの抜け穴です。IPv4 と IPv6 の両方でフィルタリングされていることを確認してください。また、Docker が公開するポートは ufw ではなく、Docker 独自のファイアウォールルールで処理される点にも注意してください。デフォルト構成では、プラグインデーモンのデバッグ用ポート 5003 がすべてのインターフェースで公開されます。別のマシンからプラグインをデバッグする必要がない限り、EXPOSE_PLUGIN_DEBUGGING_PORT を .env で 127.0.0.1:5003 に設定してください。

TLS には、Dify の Web ポートを loopback にバインドし、その前段で Let's Encrypt 証明書を使用するリバースプロキシを稼働させる構成が最も簡潔です。これにより、公開インターネットに接続するのは HTTPS を話すプロキシだけになります。Dify の .env で公開ポートを変更できます。これを 127.0.0.1 にバインドするよう設定し、プロキシの転送先をそこに指定してください。EXPOSE_NGINX_SSL_PORT も同じように設定します。Dify の nginx はデフォルトでホスト側のポート 443 を使用するため、プロキシがそのポートを必要とするからです。VPS で AI エージェントを安全に実行するで説明したエージェントのハードニング方針もここで適用できます。各要素を loopback 上に置き、公開が必要なものだけを外部公開し、TLS 接続は 1 つの強化された入口で受け付けてください。ツールのインターフェースを自分だけが使い、証明書も不要であれば、プロキシを使わず SSH トンネル経由で接続します。open-kritt セキュリティスキャナーをセルフホストする構成では、ダッシュボードを loopback にバインドし、公開する代わりにノート PC へ転送しています。Dify をチーム全体で利用し、公開インターネットからのアクセスは不要な場合は、オーバーレイネットワークによってこの構成を 1 台のノート PC の範囲から拡張できます。サーバーのプライベートサブネットを tailnet に広告することで、許可したデバイスからプライベートアドレス経由で builder に接続でき、ファイアウォールは SSH 以外を閉じたままにできます。このサーバーを手作業ではなくコーディングエージェントで管理する場合は、キーを渡す前に、エージェントが監視なしで実行できる範囲を決めてください。Claude Code に設定する権限モードによって、.env の書き換えや stack の再起動の前に確認を求めるかどうかが決まるためです。一方のセッションでコンテナログを監視し、別のセッションでプロキシ設定を編集する場合は、同じサーバー上の 2 つのセッションでテキストを受け渡すことができます。stack を再起動するたびに、ターミナル間で出力をコピーするよりも効率的です。

手順 4: パッチを適用した状態を維持する

Dify は更新が速く、更新にはセキュリティ修正が含まれます。リリースタグを clone したため、更新時はブランチを pull するのではなく、次のタグを checkout します。最初にデータベースをバックアップしてから、docker ディレクトリで次を実行します。

docker compose down
git fetch --tags
git checkout NEW_VERSION
docker compose pull
docker compose up -d

データベースのマイグレーションは起動時に自動実行されます。一部のマイグレーションは元に戻せないため、先にバックアップを取得します。メジャーアップデートに限らず、アップグレードの前には毎回リリースノートを確認してください。Dify によると、リリース間で必要なアップグレード手順は異なります。例えば 1.17.1 のリリースノート（2026 年 9 月）では、既存データがある状態で同梱の Weaviate を使用している場合、そのバージョンへ直接更新せず、各マイナーリリースを順に適用するよう説明されています。Dify はリリース間で .env スキーマも変更します。そのため、新しいタグを checkout したら .env.example と .env を比較し、変更内容を移行してください。設定していない新しい変数があると、コンテナの起動に失敗することがあるためです。

手順 5: 再生成できないものをバックアップする

Dify のサーバーで代替できないものは 2 つあります。アプリ、ユーザー、設定を保持する Postgres データベースと、アップロードしたドキュメントおよびベクトルインデックスを保存するボリュームです。どちらも docker ディレクトリ内の Docker ボリュームにあります。スケジュールを設定してスナップショットを作成し、スナップショットをサーバー外にもコピーしてください。これらのスナップショットには、すべてのモデルキーとアップロード済みドキュメントが 1 つのファイルに含まれます。そのため、サーバー外へ移す前に暗号化してください。これは、堅牢なパスワードサーバーでも Vaultwarden のバックアップが弱点になる場合があるのと同じ理由です。モデル API キーは再発行できますが、1 週間かけて構築したアプリは再発行できません。この考え方は、実行するマシンより長く状態を保持する必要があるエージェントにも当てはまります。KiroCrew を常時稼働するコンテナとして動かし続けるには、次回の再起動で失われるメモリとスケジュールをスナップショットとして保存する必要があります。

ここで構築したエージェントから自分のデータセットの外部にある情報へアクセスし、リアルタイムの Web を検索したい場合は、自己ホストした SearXNG インスタンスを指定することで、検索クエリの流れを自分で管理するハードウェア上に保持できます。ただし、有効化する前に、そこで発生するプロンプトインジェクションの攻撃面を確認してください。より自律的にコードを実行するエージェントについては、Agent Zero を自己ホストするを参照してください。また、VPS 上で独自の AI エージェントを構築するでは、これらすべての基盤を説明しています。

FAQ

Dify をセルフホストするためのシステム要件は何ですか？

Dify では、最低 4 GiB の RAM、2 個の CPU コア、Docker Compose 2.24.0 以降が必要です。これは、2026年10月時点で、デフォルト構成が常時稼働する 15 個のコンテナと、初回のみ実行する初期化タスクで構成されるためです。アップロードするドキュメントとベクトルインデックスを保存するために、十分なディスク容量も確保してください。同じサーバーで他の処理も実行する場合は、メモリを追加してください。

Dify をポート 80 に直接公開しても安全ですか？

いいえ。Dify に同梱されている Web サーバーは平文 HTTP で待ち受け、管理者ログインとモデル API key を公開する入口になります。前段に Let's Encrypt 証明書を設定したリバースプロキシを置き、Dify 自身のポートは loopback にバインドしてください。インターネットに公開するのは HTTPS プロキシだけにします。IPv4 と IPv6 の両方を対象にしたデフォルト拒否のファイアウォールも設定してください。

セルフホストした Dify を更新するにはどうすればよいですか？

データベースをバックアップしてから、docker ディレクトリで docker compose down、git fetch --tags、git checkout 新しいリリースタグ、docker compose pull、docker compose up -d を実行します。リリースノートを先に確認してください。リリースによって更新手順が異なり、マイグレーションを元に戻せない場合があるためです。また、Dify が新しい .env 変数を追加することがあり、変数がないとコンテナが起動しない場合があります。

Dify のインストール後、最初に行うことは何ですか？

/install にアクセスし、すぐに管理者アカウントを作成してください。そのアカウントが存在するまでは、ページに到達できる誰でも管理者アカウントを取得できます。コンテナが正常な状態になったら直ちに設定し、ファイアウォールをインターネット全体に開放する前に完了してください。