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

Dify とは何か、何を実行することになるのか

Dify は、大規模言語モデルを基盤とするアプリケーションを構築するための、セルフホスト可能なプラットフォームです。チャットアプリ、エージェント、検索パイプラインを設計する Web インターフェース、独自のコードから呼び出すための API、プロンプト、データセット、モデルキーを一元管理する機能を利用できます。小規模なチームが、スクリプトごとに API キーを分散させず、共有するプライベートな基盤上で開発するためのツールです。

自分で運用する場合、複数のコンポーネントを動かす必要があります。Dify は、API サーバー、バックグラウンドワーカー、Web フロントエンド、Postgres データベース、Redis キャッシュ、ベクトルデータベースからなる Docker コンテナ群としてリリースされ、すべて Docker Compose で接続されます。単一のバイナリより構成は大きくなりますが、接続設定は Compose が処理します。数 GB の空き RAM がある VPS なら、無理なく動作します。

その VPS で別のサービスも動かす場合は、公開されている最小要件ではなく、実測値を基準にサイズを決めてください。PhotoPrism と Immich の実際の RAM 最低容量は公開されている最小要件を大きく上回るためです。写真サーバーを同じホストで動かすと、最初に Dify のデータベースとベクトルストアがメモリ不足の影響を受けます。

CPU の競合でも同じ問題が起きます。90 年代のビデオ店風に外観を変更した Jellyfin ライブラリは、アートワークを閲覧しているだけなら配信にほとんど負荷がかかりません。しかし、誰かがトランスコードを開始した瞬間、Dify のワーカーはその処理を待つことになります。

ただし、Dify は構築するアプリの数に関係なく、必要なコンテナ数が固定されています。そのため、AI の同僚ごとに専用コンテナと専用ブラウザーが割り当てられ、新しい同僚を追加するたびに必要メモリが増える OpenBotよりも、コストの増え方は緩やかです。

Dify にはモデル API キーが保存され、多くの場合、検索用に読み込んだ非公開ドキュメントも保存されます。そのため、実行先のサーバーは最初から機密情報を扱う環境として管理してください。このガイドでは Dify をインストールした後、Secret を保持するサービスと同じ方法でセキュリティを強化します。

前提条件

Docker と Docker Compose plugin をインストールした Ubuntu 24.04 の VPS が必要です。また、sudo を持つユーザー、または docker グループに所属するユーザーが必要です。Docker を初めて使う場合は、VPS 上での Docker Compose の基本で、このガイドが前提とするインストール方法と基本コマンドを説明しています。サーバーを指すドメイン名も用意しておくと便利です。Dify の前段には、裸の IP アドレスではなく TLS を配置するためです。

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

Dify の Docker 構成はメインリポジトリに含まれています。リポジトリをクローンし、docker ディレクトリに移動します。

git clone https://github.com/langgenius/dify.git
cd dify/docker
cp .env.example .env

.env ファイルが構成全体を定義します。作業を始める前に内容を確認してください。最初に確認すべきなのは、パスワードと Secret を設定する値です。SECRET_KEY、Postgres のパスワード、Redis のパスワードが該当します。サンプルファイルにはプレースホルダー値が設定されています。これらをそのまま使用すると、自己ホスト型 Dify が侵害される原因になることが最も多くあります。実際の Secret キーを生成します。

openssl rand -base64 42

生成した値を SECRET_KEY に貼り付け、ファイル内の各パスワード項目に、強力で一意の値を設定してください。

手順 2: 起動する

スタックを起動します。

docker compose up -d

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

docker compose ps

すべてのサービスで running を読み取れる必要があります。Dify は、デフォルトでは同梱の nginx コンテナを介してポート 80 で Web インターフェイスを提供します。初めて http://YOUR_SERVER/install にアクセスしたときに、管理者アカウントを作成します。ほかの処理より先に、直ちに作成してください。このアカウントが存在するまで、ページを読み込んだユーザーなら誰でもアカウントを取得し、インスタンスを管理できるためです。

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

ここで多くの簡易インストールは終わりますが、多くのインシデントはここから始まります。Dify 自身の nginx はポート 80 で暗号化されていない HTTP を待ち受け、すべてのインターフェースで接続を受け付けます。管理者ログイン情報やモデルキーを平文の 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 の両方でフィルタリングされていることを確認してください。

TLS では、Dify の Web ポートを loopback にバインドし、その前段で Let's Encrypt 証明書を使用する reverse proxy を実行する構成が最も整理されています。これにより、公開インターネットに公開されるのは HTTPS で通信する proxy だけになります。Dify の .env を使うと公開ポートを変更できます。ポートを 127.0.0.1 にバインドするよう設定し、proxy の転送先に指定します。VPS 上で AI agent を安全に実行するで説明した agent の hardening の考え方も適用できます。各コンポーネントは loopback 上に置き、公開が必要なものだけを公開し、TLS 通信は hardening 済みの単一の入口で受けます。ツールのインターフェースを自分だけが使用し、証明書も必要ない場合は、proxy を使わず SSH tunnel 経由で接続します。open-kritt security scanner を self-hosting するでは、dashboard を loopback にバインドし、公開する代わりに laptop へ転送しています。チーム全体で Dify を使う必要があるものの、公開インターネットには公開したくない場合は、overlay network を使うとこの方法を 1 台の laptop より拡張できます。server の private subnet を tailnet に広告することで、承認済みの各 device が private address 経由で builder にアクセスできます。その間、firewall は SSH 以外のすべての通信を閉じたままにできます。このサーバーを手作業ではなく coding agent で管理する場合は、権限を渡す前に、agent がどこまで無監督で操作できるかを決めてください。Claude Code に設定した permission modeによって、.env の書き換えや stack の再起動前に確認を求めるかどうかが決まるためです。一方の session で container のログを tail し、もう一方で proxy の設定を編集することになった場合は、同じサーバー上の 2 つの session 間でテキストを受け渡すことができます。stack を再起動するたびに terminal 間で出力をコピーするより効率的です。

手順 4: 常にパッチを適用する

Dify は更新が速く、更新にはセキュリティ修正が含まれます。更新は docker ディレクトリで pull と再起動を実行します。

git pull
docker compose pull
docker compose up -d

メジャーバージョンを更新する前に、リリースノートを確認してください。Dify ではリリース間で .env スキーマが変更されることがあり、設定していない新しい変数が原因でコンテナが起動しなくなる場合があります。

手順 5: 再生成できないデータをバックアップする

Dify のサーバーで置き換えがきかないものは 2 つあります。アプリ、ユーザー、設定を保持する Postgres データベースと、アップロードしたドキュメントおよびベクトルインデックスを保存するボリュームです。どちらも docker ディレクトリ配下の Docker ボリュームにあります。スケジュールに従ってスナップショットを作成し、サーバー外にもコピーしてください。モデル API key は再発行できますが、1 週間かけて構築したアプリは再現できません。この考え方は、状態を実行元のマシンより長く保持する必要があるエージェントにも当てはまります。KiroCrew を常時稼働コンテナとして維持するには、次回の再起動で失われるメモリとスケジュールをスナップショットとして保存する必要があります。

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

FAQ

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

Dify は約 6 個のコンテナで構成される Docker Compose スタックとして動作します。そのため、少なくとも 2 GB、できれば 4 GB の空き RAM がある VPS を用意してください。CPU は 2 コア程度とし、アップロードしたドキュメントとベクトルインデックスを保存できる十分なディスク容量も必要です。メモリを消費する主な要因は Dify 自体ではなく、データベースとベクトルストアです。

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

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

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

docker ディレクトリで git pull を実行し、その後 docker compose pull と docker compose up -d を実行して新しいイメージを取得し、再起動します。Dify はバージョン間で新しい .env 変数を追加することがあるため、先にリリースノートを確認してください。変数が不足すると、コンテナが起動しない場合があります。

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

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