DifyをHelm chartでAWS EKSに構築する手順｜コミュニティ版0.39.0のvalues設定と落とし穴

無償のコミュニティ版Dify向けには、公式のHelm chartは提供されていません。docs.dify.ai には Docker Compose やソースコード起動、AWS向けなどの手順がありますが、無償版をHelmで導入する場合に使うのはコミュニティが保守するHelm chartです。この記事では、2026年10月15日公開の安定版 chart 0.39.0（Dify 1.17.0）を Amazon EKS で本番運用するための values.yaml と、EKS でつまずく箇所を説明します。設定値は chart を helm template（Helm 4.3.1 と 3.22.1）で描画し、生成されたマニフェストの設定値を確認しました。検証範囲はテンプレート描画で、EKS上での起動・疎通確認は含みません。

まとめ：DifyをHelmでEKSに載せるときの要点

既定値のまま helm install すると、EKSでは PVC が Pending のまま止まります。0.39.0 は既定で PVC を4つ作り、そのうち2つが ReadWriteMany です。S3 に2つのバケットを指定すると RWX の2つは消えますが、Dify Agent 用の local sandbox が使う ReadWriteOnce の2つは残ります。

Dify用Helm chartの2系統と選び方

Dify の公式デプロイ案内は Docker Compose を起点にしており、Kubernetes については「Dify Enterprise なら高可用構成で Kubernetes にデプロイできる」という案内しかありません。無償のコミュニティ版を Kubernetes に載せる公式手段は無く、選択肢は次の2系統です。Helm自体の用語（chart・リポジトリ・リリース）はHelmとは？チャート・リポジトリ・リリースの基本とhelm repo addなど主要コマンド解説で整理しています。

コミュニティ版 BorisPolonsky/dify-helm の版とDify本体のずれ

BorisPolonsky/dify-helm はMITライセンスのchartで、リポジトリURLは https://borispolonsky.github.io/dify-helm です。README の前提は Kubernetes 1.23以上、Helm 3.12以上です。Dify の旧READMEにはほかに LeoQuote 版（douban/charts）も並んでいましたが、こちらは2026年10月時点でも chart 0.10.0＝Dify 1.13.3 で止まっています。ここで比較した2つのコミュニティchartでは、BorisPolonsky版がDify 1.17.0に対応しています。

Dify 本体は 2026-09-10 に 1.17.1、2026-10-23 に 1.18.0 が出ていますが、どちらにも対応する安定版 chart はまだありません。chart には Dify 本体と同じ版のイメージ一式が組み込まれています。0.39.0 のプラグインデーモンは 0.6.10-local です（0.38.0 は 0.6.3-local）。image.api.tag だけを上げると周辺コンポーネントとの組み合わせがずれるので、本番では chart の版ごと上げてください。

0.39.0で増えたエージェント用の部品とPVC

Dify 1.16.0 で「Dify Agent」（Beta）が入り、chart にも agent backend（ポート5050）と local sandbox（ポート5004）の2つの Deployment が加わりました。どちらも既定で有効です。local sandbox はエージェントがシェルやコードを実行する Linux 環境で、1.16.0 のリリースノートは「信頼できる利用者にだけ提供する」よう警告しています。

0.39.0 では local sandbox に /home/dify と /workspace を永続化する ReadWriteOnce・5Gi の PVC が2つ追加されました（0.38.0 には無し）。エージェントのホームのスナップショットもこの /home/dify/.snapshots に保存されます。Deployment は1 Pod 固定で、更新方式は Recreate です。EBS の gp3 で動きますが、storageClass を空のままにすると既定の StorageClass が無い EKS では Pending になります。エージェント機能を使わないなら、agentBackend.enabled: false と localSandbox.enabled: false で両方を外せます。後述のS3外部化済みvaluesにこの指定を加えると、独立したPVCマニフェストは0個になり、api の設定から AGENT_BACKEND_BASE_URL も消えました。0.39.0 では E2B のクラウドサンドボックスへ実行先を移す externalE2bSandbox も選べます。

Enterprise版chart（langgenius.github.io/dify-helm）との違い

「dify enterprise helm」で見つかるのは、LangGenius 社が配布する Dify Enterprise 用の chart です。リポジトリは https://langgenius.github.io/dify-helm で、2026年10月24日に helm search repo で引くと最新は chart 3.13.1（appVersion 1.17.1・2026-10-16公開）でした。Enterprise ドキュメント（3.12.x）の「本番環境へのデプロイ」に書かれた要件は、Kubernetes 1.24以上、Helm 3.14以上です。values.yaml のイメージは langgenius/dify-ee-api・dify-ee-agent-runtime などの Enterprise 専用品で、商用ライセンスの検証が前提です。既定値は licenseMode: "online"（検証先 licenseServer: "https://licenses.dify.ai/server"）で、オフライン検証の設定もあります。

両方の手順書が helm repo add dify … と同じ登録名を使っている点にも注意してください。コミュニティ版を dify で登録した状態で Enterprise 版を同名で追加すると、Helm 4.3.1 では repository name (dify) already exists で止まります。--force-update を付けると登録先が上書きされます。dify-community のように登録名を分けておくと取り違えません。

EKS側で先に用意するもの（StorageClass・CSIドライバ・ALB）

クラスタの作り方は割愛します。2026年10月時点で EKS の標準サポート対象は Kubernetes 1.34〜1.37、1.31〜1.33 は延長サポートです。EKS のノード提供形態と料金体系はAmazon EKSとは？仕組み・ノード提供形態と料金モデル・ECSとの使い分けを実装者目線で解説にまとめています。

既定StorageClass不在への対処とgp3の作成

AWS の EKS 1.30 リリースノートには「Starting with 1.30, Amazon EKS no longer includes the default annotation on the gp2 StorageClass resource applied to newly created clusters」とあります。1.30以降に新規作成したクラスタではgp2に既定の注釈が付かないため、storageClassName を省いた PVC は動的プロビジョニングされません。Amazon EBS CSI driver アドオン（IAM 権限付き）を入れたうえで、gp3 の StorageClass を明示的に作ります。

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: gp3
provisioner: ebs.csi.aws.com
volumeBindingMode: WaitForFirstConsumer
parameters:
  type: gp3
  encrypted: "true"

EKS Auto Mode のクラスタでは provisioner が ebs.csi.eks.amazonaws.com に変わり、ALB も IngressClassParams で設定します。この記事の例はマネージドノードグループにアドオンを入れた構成が前提です。Auto Mode と Fargate の制約の違いはEKS Auto ModeとEKS on Fargateの違い｜制約一覧・料金の分岐点・併用時の落とし穴で比べています。

ReadWriteManyのPVCをEBSで満たせない問題

chart 0.39.0 を既定値のまま描画すると、PVC が4つ生成されます。RWX の2つは、api・worker が共有する /app/api/storage 用と、プラグインデーモンの /app/storage 用です。values.yaml のコメントにも「ReadWriteMany access mode required for `api` and `worker`」と明記されています。EBS の gp3 は単一ノードにしかアタッチできないため、この2つには使えません。

• S3に逃がす（推奨）：externalS3.bucketName.api と bucketName.pluginDaemon の両方を指定すると、RWX の PVC は作られなくなります。pluginDaemon を空欄にすると、プラグインデーモン用だけが残ります。
• EFSを使う：Amazon EFS CSI driver の StorageClass を api.persistence.persistentVolumeClaim.storageClass と pluginDaemon.persistence.persistentVolumeClaim.storageClass の両方に指定します。Fargate ノードでは動的プロビジョニングができず、静的プロビジョニングだけになります。

ALBでの公開とアップロード上限

Ingress から ALB を作るには AWS Load Balancer Controller が要ります。入れないまま type: LoadBalancer の Service を作ると、Kubernetes 同梱の旧クラウドプロバイダーが Classic Load Balancer を作ります。ALB には異なる AZ のサブネットが2つ以上必要です。chart の Ingress は Dify 内蔵の nginx（dify-proxy）に向くため、パス振り分けは nginx 側で済んでおり、ALB に書くルールは / の1本で足ります。0.39.0 には Ingress の代わりに Gateway API の HTTPRoute を作る httproute.enabled もあります（既定は無効）。

内蔵 nginx の client_max_body_size は既定で 15m です。ナレッジに大きなPDFを入れる運用では、proxy.clientMaxBodySize と Dify の UPLOAD_FILE_SIZE_LIMIT をそろえて上げてください。

EKS本番向けvalues.yaml（RDS・ElastiCache・S3・ALB）

次の values で chart 0.39.0 を描画すると、PVC は local sandbox の2つ（ReadWriteOnce・storageClassName: gp3）だけになり、Ingress は1つです。WeaviateのStatefulSetにはPVCを作る volumeClaimTemplates が残ります。api の ConfigMap には STORAGE_TYPE: s3 と S3_USE_AWS_MANAGED_IAM: "true" が入ります。Helm 4.3.1 と 3.22.1 のどちらでも同じ種類・数のリソースが出力されました。ホスト名・ARN・バケット名は例です。RDSとElastiCacheのパスワードには接続先に設定した認証情報を入れ、Difyの秘密値は次の章の手順で生成します。

global:
  appSecretKey: "REPLACE_WITH_openssl_rand_base64_42"
postgresql:
  enabled: false
redis:
  enabled: false
externalPostgres:
  enabled: true
  address: dify.xxxxxxxx.ap-northeast-1.rds.amazonaws.com
  port: 5432
  username: dify
  password: "REPLACE_ME"
  database:
    api: dify
    pluginDaemon: dify_plugin
externalRedis:
  enabled: true
  host: master.dify.xxxxxx.apne1.cache.amazonaws.com
  port: 6379
  password: "REPLACE_ME"
  useSSL: true
externalS3:
  enabled: true
  endpoint: "https://s3.ap-northeast-1.amazonaws.com"
  region: ap-northeast-1
  bucketName:
    api: example-dify-files
    pluginDaemon: example-dify-plugins
  useIAM: true
api:
  auth:
    internalApiKey: "REPLACE_ME_1"
  serviceAccount:
    create: true
    name: dify-api
    annotations:
      eks.amazonaws.com/role-arn: arn:aws:iam::111122223333:role/dify-s3
worker:
  serviceAccount:
    create: true
    name: dify-worker
    annotations:
      eks.amazonaws.com/role-arn: arn:aws:iam::111122223333:role/dify-s3
pluginDaemon:
  auth:
    serverKey: "REPLACE_ME_2"
  serviceAccount:
    create: true
    name: dify-plugin-daemon
    annotations:
      eks.amazonaws.com/role-arn: arn:aws:iam::111122223333:role/dify-s3
sandbox:
  auth:
    apiKey: "REPLACE_ME_3"
agentBackend:
  auth:
    apiToken: "REPLACE_ME_4"
    serverSecretKey: "REPLACE_ME_5"
    shellctlAuthToken: "REPLACE_ME_6"
localSandbox:
  persistence:
    home:
      persistentVolumeClaim:
        storageClass: gp3
    workspace:
      persistentVolumeClaim:
        storageClass: gp3
weaviate:
  storage:
    storageClassName: gp3
ingress:
  enabled: true
  className: alb
  annotations:
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS":443}]'
    alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:ap-northeast-1:111122223333:certificate/example
  hosts:
    - host: dify.example.com
      paths:
        - path: /
          pathType: Prefix

同梱の Weaviate を残す場合、StatefulSet の volumeClaimTemplates は ReadWriteOnce・32Gi なので EBS の gp3 で動きます。Weaviate を運用したくない場合は、weaviate.enabled: false と externalPgvector で RDS 上の pgvector に寄せる方法もあります。こうしたAWS側の基盤設計から相談したい場合は、AWS・Google Cloud・Azureのインフラ構築支援でも対応しています。

同梱PostgreSQL・Redisを本番で使わない理由

chart 0.39.0 が同梱する依存chartのイメージは、0.38.0 と同じ bitnamilegacy/postgresql:15.3.0-debian-11-r7 と bitnamilegacy/redis:7.0.11-debian-11-r12 です。Bitnami は2025年8月28日にカタログを変更し、旧イメージを bitnamilegacy へ移しました。Bitnami の告知には「This legacy catalog will receive no further updates or support and should only be used for temporary migration purposes」とあります。セキュリティ更新の止まったDBを本番データの置き場にしないため、RDS for PostgreSQL と ElastiCache に外出しします。

RDS 側では、api が使う dify データベースを作成時に用意しておきます。プラグインデーモンは接続先のDBが無いと pg_database を確認して CREATE DATABASE を実行するため、ユーザーに CREATEDB 権限があれば dify_plugin は自動で作られます。ElastiCache で転送中の暗号化を有効にした場合は useSSL: true が必要です（chart の既定は false）。

S3をIAMロール（IRSA）で使う設定

useIAM: true にすると、chart は api・worker・プラグインデーモンに S3_USE_AWS_MANAGED_IAM=true を渡し、アクセスキーをSecretに書きません。Dify の aws_s3_storage.py はこの値が真のとき boto3.Session() の既定の認証チェーンでクライアントを作るので、IRSA のトークンもこの経路で拾われます。chart は ServiceAccount を既定で作らない（serviceAccount.create: false）ため、3コンポーネントそれぞれで作成とロールARNの注釈が要ります。事前にクラスタのIAM OIDCプロバイダーを登録し、ロールの信頼ポリシーで dify 名前空間の dify-api・dify-worker・dify-plugin-daemon による AssumeRoleWithWebIdentity を許可したうえで、次の権限ポリシーを関連付けます。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": [
        "arn:aws:s3:::example-dify-files",
        "arn:aws:s3:::example-dify-plugins"
      ]
    },
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:PutObject", "s3:DeleteObject"],
      "Resource": [
        "arn:aws:s3:::example-dify-files/*",
        "arn:aws:s3:::example-dify-plugins/*"
      ]
    }
  ]
}

起動時に api は head_bucket を呼び、404ならバケットを作成し、403なら何もせずに続行します。HeadBucketの403だけでは起動が止まらないため、PodがReadyでもS3操作権限が十分とは限りません。PutObject権限が不足していれば、アップロード時にAccessDeniedになる可能性があります。Docker Compose 構成での S3 切り替えと .env の優先順位はDifyのストレージをAmazon S3に切り替える設定手順と.envの優先順位で扱っています。

chartの既定に残る固定の秘密値5つ

chart の values.yaml には、chart を使う全員が同じ値を持つ秘密値が5つあります。0.38.0 と 0.39.0 で値は同じです。

落とし穴は global.internalApiKey です。コメントには「コンポーネント間の内部API呼び出しの共通キー」とありますが、テンプレートは各コンポーネントの値が空のときだけこれを使います。--set global.internalApiKey=… だけで描画すると、置き換わったのは既定が空の agentBackend.auth.apiToken だけで、上の表の api・プラグインデーモン・サンドボックスの値は既定のまま出力されました。上の values.yaml のように、項目ごとに書き換えてください。値は openssl rand -base64 42 で作ります（serverSecretKey は chart のコメントどおり python -c 'import secrets; print(secrets.token_urlsafe(32))'）。

もう1つ、agentBackend.auth.shellctlAuthToken は既定が空で、共通キーへの代替もありません。Dify 1.18.0 のアップグレードガイドは local sandbox に空でない認証トークンを必須にしたので、今のうちに値を入れておくと次の chart へ上げるときに詰まりません。平文で values に書きたくない場合は、externalSecret で External Secrets Operator 経由の参照に切り替えられます。

helmでのインストールから動作確認まで

helm repo add dify-community https://borispolonsky.github.io/dify-helm
helm repo update
helm search repo dify-community/dify --versions | head -4
# 反映前に描画して、PVC が local sandbox の2個だけか確かめる
helm template dify dify-community/dify --version 0.39.0 -n dify -f values-eks.yaml > rendered.yaml
awk '/^---/{p=0} /^kind: PersistentVolumeClaim$/{p=1} p' rendered.yaml | grep -E 'name: dify|storageClassName|ReadWrite'
helm upgrade --install dify dify-community/dify --version 0.39.0 \
  -n dify --create-namespace -f values-eks.yaml
kubectl -n dify get pods
kubectl -n dify get ingress dify
# 付属のRedisテストはTLS非対応のため、この構成では実行しない

リリース名を dify にすると、Deployment は dify-api・dify-worker・dify-beat・dify-web・dify-plugin-daemon・dify-agent-backend・dify-local-sandbox・dify-proxy などの名前で作られます。chart には helm test 用の接続確認Jobがありますが、0.39.0 でも Redis 確認の redis-cli に --tls が付かないため、TLS 必須の ElastiCache では正常な構成でもタイムアウトします。代わりに、api・worker の Pod が Ready になり、kubectl -n dify logs deploy/dify-worker に DB・Redis の接続エラーが出ていないことで疎通を確かめます。続けて ALB ターゲットの正常性を確認し、kubectl get ingress の ADDRESS 欄に出る ALB の DNS 名へ dify.example.com のレコードを向けます。最後に HTTPS で /install を開き、管理者アカウントを作成します。

アップグレードとロールバックで壊さないための注意

0.38.0以前のvaluesを再利用して0.39.0へ更新する場合は、global.edition を COMMUNITY に変更します。External Secrets Operatorを使う場合は、externalSecret.agentBackend.remoteRefs.DIFY_AGENT_SHELLCTL_AUTH_TOKEN を externalSecret.agentBackend.remoteRefs.DIFY_AGENT_LOCAL_SANDBOX_AUTH_TOKEN に変更してください。

• DBマイグレーションはロールバックされない：api は MIGRATION_ENABLED: "true" で起動時にスキーマを更新します。helm rollback で戻るのはマニフェストだけです。RDS のスナップショットを取ってから helm upgrade してください。
• 1.18.0 はエージェント部品を同時に上げる：1.18.0 のアップグレードガイドは、API・worker・Agent Backend・Agent runtime のイメージを一緒に更新するよう求めています。Agent Backend の /runs は新しい形式しか受け付けず、1.17.1 の runtime イメージは新しい --require-auth-token に対応しません。image.api.tag だけを 1.18.0 に上げる運用はこの点でも壊れます。
• Weaviateの版：0.39.0 の同梱 Weaviate は 1.27.27 のままです。Dify 1.17.1 の Docker Compose は 1.39.2 へ上げており、公式の移行手順は既存データをマイナー版ごとに1段ずつ上げるよう求めています。chart がこの更新に追随したときは、Weaviate のバックアップを取ってから段階的に上げる前提で計画します。
• PASSWORD_PEPPER は空のまま：1.18.0 では既存環境が pepper を未設定なら空のままにするよう指示があり、途中で設定するとパスワードの再設定が必要になります。
• 版の固定：--version を付けずに upgrade すると、helm repo update 時点の最新 chart が入ります。本番では chart の版を必ず固定してください。
• uninstall後に残るもの：PVC には helm.sh/resource-policy: keep が付いているため、helm uninstall しても消えません。入れ直す前に残ったPVCを確認します。

つまずきやすい症状と確認箇所

画面に「このコンポーネントのレンダリング中に予期しないエラーが発生しました。」と出るのは、Dify の web が例外を受け止めたときの汎用の表示です（日本語UIの errorBoundary.message）。この文言だけでは原因は分かりません。ブラウザの開発者ツールで失敗したAPI呼び出しとコンソールの例外を確かめ、values で image.web.tag と image.api.tag を別々の版にしていないかも確認します。

api のログは kubectl -n dify logs deploy/dify-api で見られます。起動直後に DB 接続で落ちる場合は、RDS のセキュリティグループがノード（または Pod）のセキュリティグループからの 5432 を許可しているかを確認します。プラグインのインストール失敗では、chart側のストレージ・権限に加え、Dify側の署名検証やサイズ上限も確認します。Dify側の手順はDifyのプラグインがインストールできない原因と対処法｜bad signature・依存エラー・容量【1.17.1対応】を参照してください。

EKSでDifyを動かすべきでない場面

利用者が数十人規模で、止めてよい時間帯を確保できるなら、EKS は選ばないほうが得策です。EC2 1台の Docker Compose なら、公式手順どおりに版を上げられます。EKS ではクラスタ料金に加え、CSIドライバ・Load Balancer Controller・IRSA の管理が増えます。chart の追随を待つ期間もあり、1.17.0 は本体公開（2026-08-25）から安定版 chart まで約7週間かかりました。EC2 で組む手順はDifyをAWS EC2に構築しBedrockへIAMロール接続する手順【2026年8月版】で解説しています。

EKS に載せる価値が出るのは、api と worker を autoscaling で水平に増やしたい場合や、既存の Kubernetes 基盤と GitOps でまとめて管理したい場合です。ただし local sandbox は1 Pod 固定なので、エージェント機能の実行部分は水平に増えません。SSO・マルチワークスペース・ベンダーのサポートが要件に入るなら、コミュニティ chart で自作せず Enterprise の見積もりを取るほうが確実です。

よくある質問

DifyにHelm chartの公式版はありますか？

無償のコミュニティ版Dify向けの公式chartはありません。LangGenius 社が配布する chart は商用ライセンスが前提の Enterprise 版です。コミュニティ版を Kubernetes で動かす場合、この記事では Dify 1.17.0 に対応する BorisPolonsky/dify-helm の安定版 0.39.0 を採用しています。

dify enterprise helmとコミュニティ版chartは何が違いますか？

Enterprise 版は langgenius.github.io/dify-helm で配布され、dify-ee-* イメージと商用ライセンスを前提にしています。ライセンス検証にはオンラインとオフラインの設定があります。コミュニティ版は borispolonsky.github.io/dify-helm で配布され、公開イメージの langgenius/dify-api などを使います。どちらも chart 名が dify なので、helm repo add の登録名を分けてください。

DifyをKubernetes（k8s）で動かすのにHelmは必須ですか？

必須ではありません。マニフェストを自分で書いて kubectl apply しても動きます。現実的なのは、helm template で chart からマニフェストを出力し、kubectl apply や Argo CD で管理する方法です（この場合 Helm はリリース管理に使いません）。ただし Dify の版を上げるたびにマニフェストを作り直す手間を考えると、values.yaml だけを管理する Helm のほうが追随しやすくなります。

EKS以外（AKS・GKE・minikube）でも同じvaluesで動きますか？

Dify 本体の設定（外部DB・Redis・秘密値）はそのまま使えます。違うのはストレージと公開部分です。StorageClass 名、S3 の代わりのオブジェクトストレージ（externalAzureBlobStorage・externalGCS など）、Ingress の className とアノテーションを環境に合わせて書き換えます。既定の StorageClass があるクラスタなら、local sandbox の storageClass 指定は不要です。

Difyのバージョンを上げるにはどうすればよいですか？

helm repo update で新しい chart を取得し、appVersion を確認してから helm upgrade --version <chart版> を実行します。事前に RDS のスナップショットを取っておきます。マイグレーションはロールバックできないためです。1.18.0 対応の chart が出たら、上の注意（Agent部品の同時更新・認証トークン・Weaviate）を先に確認してください。

関連記事

• Helmとは？チャート・リポジトリ・リリースの基本とhelm repo addなど主要コマンド解説
• Amazon EKSとは？仕組み・ノード提供形態と料金モデル・ECSとの使い分けを実装者目線で解説
• DifyのストレージをAmazon S3に切り替える設定手順と.envの優先順位
• DifyをAWS EC2に構築しBedrockへIAMロール接続する手順【2026年8月版】
• Difyのプラグインがインストールできない原因と対処法｜bad signature・依存エラー・容量【1.17.1対応】