--- title: "DifyをHelm chartでAWS EKSに構築する手順｜コミュニティ版0.39.0のvalues設定と落とし穴" url: "https://www.issoh.co.jp/tech/details/7097/" published: 2025-06-04 updated: 2026-10-24 categories: ["Dify"] publisher: "株式会社一創" --- # 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に載せるときの要点 | 判断項目 | 結論 | | ---------------- | ---------------------------------------- | | 使うchart | コミュニティ版 dify-helm 0.39.0（Dify 1.17.0） | | Enterprise版chart | 商用ライセンス前提。無償版の代わりにならない | | ファイル保存 | S3（api用とプラグイン用の2バケット） | | エージェント用PVC | RWO 2個が残るのでgp3を明示する | | DB・Redis | RDS for PostgreSQLとElastiCacheへ外出し | | 公開 | AWS Load Balancer ControllerのALB Ingress | | 秘密値 | 既定で固定の5項目をすべて置き換える | 既定値のまま `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 の公式デプロイ案内](https://docs.dify.ai/en/self-host/deploy/overview)は Docker Compose を起点にしており、Kubernetes については「Dify Enterprise なら高可用構成で Kubernetes にデプロイできる」という案内しかありません。無償のコミュニティ版を Kubernetes に載せる公式手段は無く、選択肢は次の2系統です。Helm自体の用語（chart・リポジトリ・リリース）は[Helmとは？チャート・リポジトリ・リリースの基本とhelm repo addなど主要コマンド解説](/tech/details/7694/)で整理しています。 ### コミュニティ版 BorisPolonsky/dify-helm の版とDify本体のずれ [BorisPolonsky/dify-helm](https://github.com/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に対応しています。 | chart | Dify（appVersion） | 公開日 | 区分 | | ---------- | ---------------- | ---------- | ------ | | 0.39.0 | 1.17.0 | 2026-10-15 | 最新安定版 | | 0.39.0-rc1 | 1.17.0 | 2026-08-28 | リリース候補 | | 0.38.0 | 1.16.1 | 2026-08-26 | 旧安定版 | | 0.37.0 | 1.14.2 | 2026-07-11 | 旧安定版 | Dify 本体は 2026-09-10 に 1.17.1、[2026-10-23 に 1.18.0](https://github.com/langgenius/dify/releases/tag/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）の「本番環境へのデプロイ」](https://enterprise-docs.dify.ai/ja/3.12.x/deploy/test-production/production-deployment)に書かれた要件は、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 の標準サポート対象](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html)は Kubernetes 1.34〜1.37、1.31〜1.33 は延長サポートです。EKS のノード提供形態と料金体系は[Amazon EKSとは？仕組み・ノード提供形態と料金モデル・ECSとの使い分けを実装者目線で解説](/tech/details/15437/)にまとめています。 ### 既定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の違い｜制約一覧・料金の分岐点・併用時の落とし穴](/tech/details/4524/)で比べています。 ### 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のインフラ構築支援](/service/system/aws/)でも対応しています。 ### 同梱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 の告知](https://github.com/bitnami/containers/issues/83267)には「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の優先順位](/tech/details/4131/)で扱っています。 ## chartの既定に残る固定の秘密値5つ chart の values.yaml には、chart を使う全員が同じ値を持つ秘密値が5つあります。0.38.0 と 0.39.0 で値は同じです。 | キー | 既定値（先頭） | 用途 | | --------------------------------- | ------------ | ---------------------- | | global.appSecretKey | sk-9f73s3lj… | Cookie署名・DB上の暗号化 | | api.auth.internalApiKey | QaHbTe77… | api・worker と内部呼び出し元の認証 | | pluginDaemon.auth.serverKey | lYkiYYT6… | プラグインデーモンの認証 | | sandbox.auth.apiKey | dify-sandbox | コード実行サンドボックスの認証 | | agentBackend.auth.serverSecretKey | MDEyMzQ1… | Agent Stub用トークンの暗号化 | 落とし穴は `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 へ上げており、[公式の移行手順](https://docs.dify.ai/en/self-host/deploy/troubleshooting/weaviate-server-migration-path)は既存データをマイナー版ごとに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を確認します。 ## つまずきやすい症状と確認箇所 | 症状 | 主な原因 | 確認先 | | ---------------------------- | ---------------------- | ------------------------ | | PVCがPendingのまま | 既定StorageClass無し／RWX要求 | kubectl describe pvc | | local-sandboxのPVCだけPending | storageClass未指定 | localSandbox.persistence | | apiがCrashLoopBackOff | RDSのSG未許可・DB未作成 | dify-apiのログ | | アップロードだけ失敗 | IAMポリシー不足 | AccessDeniedのログ | | 413 Request Entity Too Large | 内蔵nginxの15m上限 | proxy.clientMaxBodySize | | Redis接続タイムアウト | TLS設定の不一致 | externalRedis.useSSL | | 画面にレンダリングエラー | web側の例外（原因は別） | ブラウザのコンソール | 画面に「このコンポーネントのレンダリング中に予期しないエラーが発生しました。」と出るのは、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対応】](/tech/details/7098/)を参照してください。 ## 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月版】](/tech/details/2725/)で解説しています。 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 ` を実行します。事前に RDS のスナップショットを取っておきます。マイグレーションはロールバックできないためです。1.18.0 対応の chart が出たら、上の注意（Agent部品の同時更新・認証トークン・Weaviate）を先に確認してください。 ## 関連記事 - [Helmとは？チャート・リポジトリ・リリースの基本とhelm repo addなど主要コマンド解説](/tech/details/7694/) - [Amazon EKSとは？仕組み・ノード提供形態と料金モデル・ECSとの使い分けを実装者目線で解説](/tech/details/15437/) - [DifyのストレージをAmazon S3に切り替える設定手順と.envの優先順位](/tech/details/4131/) - [DifyをAWS EC2に構築しBedrockへIAMロール接続する手順【2026年8月版】](/tech/details/2725/) - [Difyのプラグインがインストールできない原因と対処法｜bad signature・依存エラー・容量【1.17.1対応】](/tech/details/7098/) --- 出典: [DifyをHelm chartでAWS EKSに構築する手順｜コミュニティ版0.39.0のvalues設定と落とし穴]()（株式会社一創）