Dify Cloud、Dify Docker (Compose)、Kubernetes の各デプロイモードの比較と、エンタープライズ向け設定のアドバイス。

Dify デプロイモード徹底解説

Dify には、ニーズに合わせて選べる 3 つのコアな利用モードがあります。

Dify Cloud (SaaS 版)：すぐに利用可能で、メンテナンス不要。
Docker Compose によるプライベートデプロイ：中小規模のプロジェクトや POC 段階に最適。
Kubernetes (Helm) による大規模クラスターデプロイ：高可用性が求められる大規模な本番環境に最適。

3 つのモードの比較

評価項目	Dify Cloud (SaaS)	Docker Compose (Private)	Kubernetes (Enterprise)
適用シーン	迅速な POC、非機密業務、運用チームなし	内部ツール、データプライバシー重視、中小規模生産	大規模パブリックサービス、高可用性、マルチテナント
データ主権	Dify マネージドクラウドに保存	データを完全にローカル化	データを完全にローカル化
インフラコスト	従量制 / サブスクリプション	自社サーバーリソースが必要	クラスターおよびクラウドサービスが必要
運用複雑度	ゼロ運用	中程度（単一マシン管理）	高い（K8s の専門知識が必要）
拡張性	プラットフォーム枠に依存	単一マシンの物理的限界に依存	ネイティブな弾力性スケーリング (HPA)
コンプライアンス	SOC2 (プラットフォーム依存)	完全制御、GDPR/等保に容易に対応	完全制御、複雑なネットワーク隔離に対応

詳細な違いと価格については、こちらを参照してください：Dify Pricing

1. Dify Cloud (SaaS 版) の利用

プライベートデプロイを決定する前に、クラウド版（dify.ai）を試してみるのが良い選択です。Dify Cloud はオープンソース版と同じ機能を提供しつつ、インフラの保守負担をゼロにします。

使い方は非常に簡単です：

dify.ai にアクセスし、Get Started をクリックします。
メールアドレス、Google、または GitHub でログインできます。
ログイン後、すぐにワークスペースに入り、Dify の旅を始めることができます。

2. Docker Compose によるプライベートデプロイ

技術的なスキルを持つ開発者や、データを自社サーバーで管理したいプロジェクトにとって、Docker Compose によるデプロイは標準的かつ効率的な選択肢です。

2.1 インフラ準備と環境の最適化

Dify はメモリを多く消費するコンポーネントを含んでいます。リソースが不足すると、OOM（メモリ不足）によるクラッシュが発生しやすくなります。

2.1.1 ハードウェアリソースの基準

CPU：最低 2 vCPU。本番環境では 4 vCPU 以上を推奨。
メモリ：最低 4GB RAM。ローカルベクトルデータベースを使用する場合は 8GB RAM 以上を推奨。
ディスク：SSD を推奨。ルートパーティションに少なくとも 50GB の空き容量を確保してください。

2.1.2 ソフトウェアの依存関係

Docker Engine：バージョン 19.03 以上。
Docker Compose：必ず V2（コマンドは docker compose）を使用してください。
システムパラメータ：ベクトルデータベースなどのために vm.max_map_count を調整します。
```
sysctl -w vm.max_map_count=262144
echo "vm.max_map_count=262144" >> /etc/sysctl.conf
```

2.2 デプロイの全フロー

ステップ 1：ソースコードの取得とバージョンの固定 本番環境では、安定性を確保するために最新の Tag バージョンをチェックアウトしてください。

Release Tag

git clone https://github.com/langgenius/dify.git
cd dify/docker
latest_tag=$(curl -s https://api.github.com/repos/langgenius/dify/releases/latest | jq -r .tag_name)
git checkout $latest_tag

ステップ 2：環境変数の設定

cp .env.example .env

デプロイ時に注意すべき主要な環境変数のリストは以下の通りです：

モジュール	変数名	推奨設定
セキュリティ	`SECRET_KEY`	高リスク。セッションとデータベースの暗号化に使用。`openssl rand -base64 42` で生成。漏洩するとシステム全体のセキュリティが失われます。
Web アクセス	`APP_WEB_URL`	フロントエンドの完全な URL（例：`https://ai.corp.com`）。OAuth や共有リンクに使用。設定ミスは SSO 失敗や画像表示不可を招きます。
Web アクセス	`COOKIE_DOMAIN`	異なるサブドメイン間で Cookie を共有する場合、トップレベルドメイン（例：`.corp.com`）を設定します。
データベース	`DB_HOST`	デフォルトは `db`（コンテナ名）。外部 RDS の場合は IP またはドメインを入力。
Redis	`REDIS_PASSWORD`	デフォルトは空。本番環境では必ず強固なパスワードを設定してください。
ベクトルDB	`VECTOR_STORE`	デフォルトは `weaviate`。`milvus` に変更可能。変更時は `docker-compose.yaml` で不要なコンテナを停止してください。
最適化	`GUNICORN_WORKERS`	API ワーカープロセス数。デフォルトは 1。`CPUコア数 * 2 + 1` を推奨。
最適化	`CELERY_WORKER_AMOUNT`	非同期タスクの同時実行数。値を増やすとインポートが速まりますが、メモリ消費も増えます。
ストレージ	`STORAGE_TYPE`	デフォルトは `local`。本番環境では `s3` への変更を強く推奨します。

必要に応じて .env ファイル内のデータベース、Redis、ストレージ設定を編集します。

ステップ 3：起動とヘルスチェック

docker compose up -d
docker compose ps

api、worker、db コンテナの状態に注意してください。トラブルシューティングの際はログを確認します：docker compose logs -f api

2.3 エンタープライズ向けの高度な設定：ミドルウェアの外出し

本番環境では、ステートフルなサービス（データベースなど）をコンテナの外に出すのがベストプラクティスです。

2.3.1 外部の PostgreSQL および Redis への接続

.env ファイルを修正して、既存の高可用性クラスターを指定します。Dify 起動時に flask db upgrade が自動的に実行されます。

2.3.2 S3 オブジェクトストレージの設定（永続化の鍵）

STORAGE_TYPE を s3 に設定し、S3 互換の情報を入力します。これによりアプリケーションが「ステートレス」になり、スケーリングや移行が容易になります。

3. Kubernetes によるエンタープライズクラスターデプロイ

数千人規模のユーザーへの拡張や 99.9% の SLA が必要な場合は、Kubernetes (K8s) が推奨されます。

3.1 アーキテクチャの計画

ステートレスサービス (Deployments)：dify-api、dify-worker、dify-web。HPA（水平ポッドオートスケーラー）の設定を推奨します。
ステートフルサービス (External)：本番環境では K8s 内部でコアデータベースを運用するのは避けてください。クラウドベンダーの RDS、ElastiCache、マネージドベクトル検索サービスを利用することを強くお勧めします。

3.2 Helm Chart によるデプロイ

helm repo add dify https://borispolonsky.github.io/dify-helm
helm repo update

values.yaml のカスタマイズ： production-values.yaml を作成し、内蔵データベースを無効にして外部のインスタンスに接続するように設定します。また、リソース制限とオートスケーリングを設定してください。

デプロイと初期化：

helm upgrade --install dify dify/dify -f production-values.yaml --namespace dify-prod --create-namespace

デプロイ後、手動でデータベースのマイグレーションを実行します：

API_POD=$(kubectl get pods -n dify-prod -l app.kubernetes.io/component=api -o jsonpath='{.items.metadata.name}')
kubectl exec -it $API_POD -n dify-prod -- flask db upgrade

付録：Dify のマイクロサービスアーキテクチャ

Dify のコアは、以下のようなマイクロサービス群で構成されています：

API Service (Flask)：プラットフォームの「脳」。リクエスト処理、ロジック、LLM との対話を担当。
Worker Service (Celery)：プラットフォームの「筋肉」。ドキュメント解析、ベクトルの埋め込み、Agent の推論などの非同期タスクを担当。
Web Service (Next.js)：ユーザーインターフェース。
Redis：メッセージブローカーおよびキャッシュ。
PostgreSQL：メタデータ（アプリ設定、ログ、ユーザーデータ）を保存。
Vector Database：高次元ベクトルデータの保存（Weaviate、Qdrant など）。
Object Storage (S3)：非構造化データ（画像、ドキュメント原本）の保存。
Sandbox：ユーザーコードを安全に実行するための環境。

Dify デプロイガイド：Dify Docker、Cloud、Kubernetes の完全比較