Difyをdocker-composeで起動すると、.envには数百の環境変数が並びます。ほとんどは既定値のままで問題ありませんが、「アップロードできるファイルの上限を変えたい」「招待メールが届かない」「本番運用では保存先をS3にしたい」といった要件は、初回構築時によく突き当たる壁です。本記事では、この3点に絞って設定項目を整理します。前回のBedrock設定に続き、Dify 1.x（2026年8月時点のリポジトリ構成）を前提にしています。
1. .envファイルが分割されている理由
現在のDifyは、必須変数だけをdocker/.env（.env.exampleをコピーしたもの）に置き、任意設定はdocker/envs/配下の*.env.exampleに分けています。
# 任意設定を有効化する例：メール関連の設定ファイルをコピーする
cd dify/docker
cp envs/core-services/shared.env.example envs/core-services/shared.env本記事で扱うアップロード制限・メール・ストレージの変数は、いずれもenvs/core-services/shared.env.exampleにまとまっています。docker/.envに同名の変数を書けばそちらが優先されるので、既存の.envだけで管理している場合はそのまま追記しても構いません。
2. アップロードできるファイルを制御する
ナレッジ（RAG）用の文書や、チャットでの添付ファイルには既定でサイズ・件数の上限があります。
| 変数 | 既定値 | 内容 |
|---|---|---|
UPLOAD_FILE_SIZE_LIMIT | 15 | 1ファイルあたりの上限（MB） |
UPLOAD_FILE_BATCH_LIMIT | 5 | 一度にアップロードできるファイル数 |
UPLOAD_FILE_EXTENSION_BLACKLIST | 空 | アップロードを禁止する拡張子（カンマ区切り） |
KNOWLEDGE_UPLOAD_FILE_SIZE_LIMIT_FOR_PAID_PLAN | 15 | ナレッジ文書の上限（MB） |
たとえば議事録PDFが数十MBになる部署がある場合、次のように上限を引き上げます。
# 1ファイル50MB、拡張子.exeと.batのアップロードを禁止する
UPLOAD_FILE_SIZE_LIMIT=50
UPLOAD_FILE_EXTENSION_BLACKLIST=exe,bat上限を上げるほど、後述のファイルストレージの消費量とサンドボックスのメモリ消費が増える点は意識しておく必要があります。値を変更したらdocker compose up -dで該当コンテナを再起動しないと反映されません。
3. 招待メール・通知メールを飛ばせるようにする
Difyはメンバー招待やパスワードリセットの際にメールを送信します。既定のMAIL_TYPEはresend（Resend社のAPI経由）ですが、社内のメールサーバーを使う場合はsmtpに切り替えます。
# 社内SMTPサーバー経由でメールを送る設定
MAIL_TYPE=smtp
MAIL_DEFAULT_SEND_FROM=<送信元に使うメールアドレス>
SMTP_SERVER=mail.example.co.jp
SMTP_PORT=587
SMTP_USERNAME=dify-noreply
SMTP_PASSWORD= # ここに平文で書きたくない場合は Secrets 管理の仕組みを検討する
SMTP_USE_TLS=true
SMTP_OPPORTUNISTIC_TLS=falseSMTP_USE_TLSとSMTP_OPPORTUNISTIC_TLSは組み合わせに注意が必要です。465番ポート（SMTPS）ならSMTP_USE_TLS=true、587番ポート（STARTTLS）を使うならSMTP_OPPORTUNISTIC_TLS=trueにしてSMTP_USE_TLSはfalseのままにする、という使い分けが公式ドキュメントの想定です。両方trueにすると接続に失敗するケースがあるため、ポート番号と設定の対応をまず確認してください。
MAIL_TYPEには他にsendgridもあり、SENDGRID_API_KEYを設定するだけで使えます。社外SaaSへの依存を避けたいならSMTP、運用の手間を減らしたいならSendGridやResendという選び方になります。
4. ファイルの保存先を切り替える（ローカル → S3）
アップロードしたファイルやナレッジの原本は、既定ではSTORAGE_TYPE=opendal・OPENDAL_SCHEME=fsにより、apiコンテナ内のstorage/ディレクトリに保存されます。この方式はコンテナを作り直すとファイルごと消えるため、検証以外の用途では保存先を外部に出すのが定石です。
AWS上で動かしているなら、STORAGE_TYPE=s3に切り替えて次の変数を設定します。
# ファイルの保存先をS3に切り替える設定例
STORAGE_TYPE=s3
S3_BUCKET_NAME=dify-storage-example
S3_REGION=ap-northeast-1
# EC2のIAMロールをそのまま使う場合はtrue（アクセスキーの発行が不要になる）
S3_USE_AWS_MANAGED_IAM=trueS3_USE_AWS_MANAGED_IAM=trueにすると、boto3がEC2のインスタンスメタデータから認証情報を取得します。これは前回記事で扱ったBedrockのIAMロール認証と同じ考え方で、アクセスキーを発行・ローテーションする手間を避けられます。オンプレミスや手元のPCから接続する場合はこの方式が使えないため、S3_ACCESS_KEY・S3_SECRET_KEY・S3_ENDPOINTを明示的に指定する構成になります。
もう一点、Difyのソースコード上の挙動として押さえておきたいのが指定したバケットが存在しない場合、Dify自身が起動時にCreateBucketを試みることです。IAMポリシーでs3:CreateBucketを許可していないと、バケット未作成の状態で起動に失敗します。バケットの命名や権限をあらかじめ運用ルールで決めている環境では、Dify側に作らせず、事前に用意したバケット名を指定したうえでs3:CreateBucketは許可しない、という運用にした方が安全です。
【追記】この章の内容は、その後AWS上で実際に構築して動作を確認しました。 CloudFormationでのバケットとIAMポリシーの定義、稼働中の環境への反映手順、動作確認の方法はDifyのファイルストレージをS3にするにまとめています。
検証してわかった点を2つ補足します。ひとつは、IAMポリシーはバケットへの操作とオブジェクトへの操作でResourceを分ける必要があることです。s3:ListBucketはarn:aws:s3:::バケット名を、s3:GetObjectはarn:aws:s3:::バケット名/*を対象にするため、1つにまとめると片方が通りません。
もうひとつは、上に書いたs3:CreateBucketの件です。バケットをあらかじめ用意しておけば、s3:CreateBucketを許可しなくてもDifyは正常に起動します。 事前にバケットを作り、作成権限は渡さない運用で問題ありませんでした。
5. まとめ
Dify docker-composeの.envのうち、実務で触ることになりやすい3点を整理しました。
- 任意設定は
docker/envs/配下にファイルが分かれている。使う設定だけ.env.exampleをコピーして有効化する - アップロード制限は
UPLOAD_FILE_SIZE_LIMITなど4つの変数で調整できる。上限を上げるとストレージ消費も増える - 招待メールは
MAIL_TYPE=smtpで社内メールサーバーに向けられる。ポート番号とTLS設定の組み合わせに注意する - ファイルストレージは
STORAGE_TYPE=s3でS3に切り替えられ、S3_USE_AWS_MANAGED_IAM=trueならBedrockと同様にIAMロール認証が使える
いずれの設定も、変更後は関連コンテナの再起動が必要です。要件に合わせて.envを組み立て、検証環境で一通り動作を確認してから本番に適用してください。
次回は、Difyのナレッジ（RAG）機能を使ったAWS社内文書検索アプリの構築について解説します。
コメント