Dify Enterprise Edition Deployment Guide (AWS)

This document describes how to deploy Dify Enterprise Edition in an AWS cloud environment. You can choose any of the following methods to complete the deployment:

Via Terraform (Recommended)
Via CDK
Manually create infrastructure and deploy (Not recommended)

Option 1: Build via Terraform

Please contact the Dify technical support team to obtain Terraform-related scripts and documentation.

Prerequisites

kubectl, helm, and aws cli are installed locally.
An AWS account with permissions to create the following resources.

Terraform will automatically create the following cloud resources to support Dify Enterprise Edition deployment. You can modify the Terraform configuration files in advance to adjust resource specifications.

AWS EKS (Elastic Kubernetes Service): For deploying Dify core services; nodes need internet access or NAT Gateway configuration
AWS S3 (Simple Storage Service): For persistent storage
AWS ECR (Elastic Container Registry): For Dify plugin installation; can also host Dify images and Helm Charts
AWS RDS Aurora Postgres: Relational database for storing application data and audit records
AWS OpenSearch: Vector database for RAG (Retrieval Augmented Generation) related features
Amazon ElastiCache: Managed Redis caching service for accelerating data access

Option 2: Build via CDK

Please refer to AWS CDK Deployment.

Option 3: Manually Create Infrastructure and Deploy

1. Create Infrastructure

Please refer to the recommended configurations in the table below and create infrastructure according to your actual needs. (Replace content in double brackets with actual values)

Version note (important): The versions in the table below are provided as “available ranges/version families” for reference. Before deployment, please make sure to verify in the AWS Console of your target AWS Region (or via AWS CLI) which versions are currently supported (EKS Kubernetes, Aurora PostgreSQL, OpenSearch, ElastiCache Redis, etc.) to avoid resource creation failures caused by regional differences or version deprecations.

Testing Environment Infrastructure Configuration Reference

Note: If enabling the unstructured service on a single node, increase disk capacity to 40 GB.

Component Type	Configuration Item	Specification	Description
EKS Cluster	Cluster Name	`dify-{your_custom_deployment_id}-eks-cluster`	Custom naming
	Kubernetes Version	1.2x–1.3x (subject to what EKS supports in the target Region)	Pre-launch check: EKS Kubernetes version support list for the target Region
	Node Instance Type	m7a.xlarge (amd64) / m7g.xlarge (arm64)	4 vCPU, 16GB RAM
	Node Count	1-2 (desired: 1)	Minimum cost configuration
	Node Disk Size	40 GB	gp3, encrypted
	AMI Type	AL2023_x86_64 / ARM_64_STANDARD	Amazon Linux 2023
S3 Bucket	Bucket Name	`dify-{your_custom_deployment_id}-storage`	Custom naming
	Versioning	Enabled	File version management
	Encryption	AES256	Server-side encryption
	Public Access	Fully blocked	Security configuration
	Storage Capacity Planning	100GB	Testing environment capacity
RDS (Aurora Serverless v2)	Cluster Identifier	`dify-{your_custom_deployment_id}-aurora-postgres`	Custom naming
	Engine Version	Aurora PostgreSQL (PostgreSQL 14+ compatible, subject to target Region support)	Pre-launch check: available Aurora PostgreSQL engine versions in the target Region
	Instance Count	1	Single instance, cost optimized
	Instance Type	db.serverless	Serverless v2 dedicated
	Min/Max Capacity	1 - 8 ACU	Auto scaling
	Storage Encryption	Enabled	At-rest encryption
	Backup Retention	7 days	Automatic backup
	Performance Insights	Disabled	Cost optimization
	Create Databases	dify, enterprise, audit, dify_plugin_daemon	4 databases
OpenSearch	Domain Name	`dify-{your_custom_deployment_id}-opensearch`	Custom naming
	Engine Version	OpenSearch 2.x (subject to target Region support)	Pre-launch check: supported engine versions for Amazon OpenSearch Service
	Instance Type	t3.medium.search	2 vCPU, 4 GB RAM
	Instance Count	1	Single node
	Storage Type/Size	EBS gp3 / 100 GB	Testing environment (single node)
	Security Features	At-rest encryption, node-to-node encryption, HTTPS enforced	Comprehensive security
ElastiCache (Redis)	Replication Group ID	`dify-{your_custom_deployment_id}-redis`	Custom naming
	Engine Version	Redis 7.x (subject to what ElastiCache supports in the target Region)	Pre-launch check: supported engine versions for ElastiCache for Redis
	Node Type	cache.t4g.small	2 vCPU, 1.37 GB RAM
	Cache Node Count	1	Single node mode
	Multi-AZ	Disabled	Single AZ deployment
	Snapshot Retention	0 days	No backup
IAM Roles	EKS Cluster Role	`dify-{your_custom_deployment_id}-cluster-role`	AmazonEKSClusterPolicy
	EKS Node Group Role	`dify-{your_custom_deployment_id}-node-group-role`	Worker + CNI + ECR policies
	S3 Access Role	`dify-{your_custom_deployment_id}-s3-role`	S3 full access
	S3+ECR Access Role	`dify-{your_custom_deployment_id}-s3-ecr-role`	S3 + ECR full access
	ECR Pull Role	`dify-{your_custom_deployment_id}-ecr-pull-role`	ECR read-only access
Other Resources	ECR Repository	2 (main app + plugins)	Image storage
	Secrets Manager	1	RDS credentials

Production Environment Infrastructure Configuration Reference

Component Type	Configuration Item	Specification	Description
EKS Cluster	Cluster Name	`dify-{your_custom_deployment_id}-eks-cluster`	Custom naming
	Kubernetes Version	1.2x–1.3x (subject to what EKS supports in the target Region)	Pre-launch check: EKS Kubernetes version support list for the target Region
	Node Instance Type	m7a.xlarge (amd64) / m7g.xlarge (arm64)	4 vCPU, 16GB RAM
	Node Count	6-10 (desired: 6)	Production environment configuration
	Node Disk Size	20 GB	gp3, encrypted
	AMI Type	AL2023_x86_64 / ARM_64_STANDARD	Amazon Linux 2023
S3 Bucket	Bucket Name	`dify-{your_custom_deployment_id}-storage`	Custom naming
	Versioning	Enabled	File version management
	Encryption	AES256	Server-side encryption
	Public Access	Fully blocked	Security configuration
	Storage Capacity Planning	512GB	Production environment capacity
RDS (Aurora Serverless v2)	Cluster Identifier	`dify-{your_custom_deployment_id}-aurora-postgres`	Custom naming
	Engine Version	Aurora PostgreSQL (PostgreSQL 14+ compatible, subject to target Region support)	Pre-launch check: available Aurora PostgreSQL engine versions in the target Region
	Instance Count	1	Single instance, cost optimized
	Instance Type	db.serverless	Serverless v2 dedicated
	Min/Max Capacity	4 - 8 ACU	Auto scaling
	Storage Encryption	Enabled	At-rest encryption
	Backup Retention	30 days	Automatic backup
	Performance Insights	Enabled	Recommended to enable in production
	Create Databases	dify, enterprise, audit, dify_plugin_daemon	4 databases
OpenSearch	Domain Name	`dify-{your_custom_deployment_id}-opensearch`	Custom naming
	Engine Version	OpenSearch 2.x (subject to target Region support)	Pre-launch check: supported engine versions for Amazon OpenSearch Service
	Instance Type	r5.large.search	2 vCPU, 16 GB RAM (per node)
	Instance Count	3	3-node cluster, total 6 vCPU, 48 GB RAM
	Storage Type/Size	EBS gp3 / 30 GB	30 GB per node
	Security Features	At-rest encryption, node-to-node encryption, HTTPS enforced	Comprehensive security
ElastiCache (Redis)	Replication Group ID	`dify-{your_custom_deployment_id}-redis`	Custom naming
	Engine Version	Redis 7.x (subject to what ElastiCache supports in the target Region)	Pre-launch check: supported engine versions for ElastiCache for Redis
	Node Type	cache.t4g.medium	~2 vCPU, ~3 GB RAM
	Cache Node Count	2	Primary + read replica
	Auto Failover	Enabled	High availability
	Multi-AZ	Enabled	Cross-AZ deployment
	Snapshot Retention	7 days	Automatic backup
IAM Roles	EKS Cluster Role	`dify-{your_custom_deployment_id}-cluster-role`	AmazonEKSClusterPolicy
	EKS Node Group Role	`dify-{your_custom_deployment_id}-node-group-role`	Worker + CNI + ECR policies
	S3 Access Role	`dify-{your_custom_deployment_id}-s3-role`	S3 full access
	S3+ECR Access Role	`dify-{your_custom_deployment_id}-s3-ecr-role`	S3 + ECR full access
	ECR Pull Role	`dify-{your_custom_deployment_id}-ecr-pull-role`	ECR read-only access
Other Resources	ECR Repository	2 (main app + plugins)	Image storage
	Secrets Manager	1	RDS credentials

Additionally, you need to create appropriate Virtual Private Cloud (VPC) and Security Groups (SG) to ensure infrastructure security.

2. Configure values.yaml

After creating the database, S3, and other infrastructure, please refer to the following example to configure values.yaml (replace content in double brackets with actual values). Before this, you need to create four databases in the database: dify, enterprise, audit, dify_plugin_daemon, and replace the corresponding configuration items such as rds_main_database_name in values.yaml.

###################################
# Persistence Configration
###################################
persistence:
  type: "s3"
  s3:
    endpoint: "{s3_endpoint}"
    accessKey: ""
    secretKey: ""
    region: "{region}"
    bucketName: "{s3_bucket_name}"
    addressType: ""
    useAwsManagedIam: true
    useAwsS3: true

###################################
# External postgres
###################################
externalPostgres:
  enabled: true
  address: "{rds_address}"
  port: 5432
  credentials:
    dify:
      database: "{rds_main_database_name}"
      username: "postgres"
      password: "{rds_password}"
      sslmode: "require"
    plugin_daemon:
      database: "{rds_plugin_daemon_database_name}"
      username: "postgres"
      password: "{rds_password}"
      sslmode: "require"
    enterprise:
      database: "{rds_enterprise_database_name}"
      username: "postgres"
      password: "{rds_password}"
      sslmode: "require"
    audit:
      database: "{rds_audit_database_name}"
      username: "postgres"
      password: "{rds_password}"
      sslmode: "require"

###################################
# External Redis
###################################
externalRedis:
  enabled: true
  host: "{redis_address}"
  port: 6379
  username: ""
  password: ""
  useSSL: false

###################################
# External Vector Database
###################################
vectorDB:
  useExternal: true
  externalType: "opensearch"
  externalOpenSearch:
    host: "{opensearch_address}"
    port: 443
    user: "{opensearch_user}"
    password: "{opensearch_password}"
    useTLS: true

3. Configure S3 and ECR Permissions

To ensure Dify services start properly and the plugin system functions correctly, the api, worker, workerBeat, plugin_daemon, and plugin_connector services require S3 access permissions, and the plugin_connector service also requires ECR access permissions. The specific reasons why the plugin_connector service needs these permissions will be explained in detail later. You can configure permissions in one of the following two ways:

IRSA Mode: IAM Roles for Service Accounts, enabling secure and fine-grained permission control (Recommended)
Access Key (AK/SK) Mode: Provide credentials via environment variables

IRSA Mode Configuration

Dify recommends using IRSA to configure ServiceAccount permissions. You can contact the Dify technical support team for one-click IRSA deployment scripts. IRSA establishes a trust relationship between the EKS cluster and IAM through an OIDC Provider, allowing Pods to securely obtain AWS permissions via ServiceAccounts without configuring Access Keys in the Pod. The overall architecture is as follows:

┌─────────────────────┐
│   OIDC Provider     │
└────────┬────────────┘
         │ (Federated Trust)
         ▼
┌────────────────────────────────────────────────────────────┐
│  Role: S3 Access Role                                      │
│  ├─ Policy: S3 Policy (s3:*)                               │
│  └─ SA: dify-api-sa, dify-plugin-connector-sa              │
├────────────────────────────────────────────────────────────┤
│  Role: S3+ECR Access Role                                  │
│  ├─ Policy: S3 Policy (s3:*)                               │
│  ├─ Policy: ECR Policy (ECR read/write/push + CloudTrail)  │
│  └─ SA: dify-plugin-crd-sa                                 │
├────────────────────────────────────────────────────────────┤
│  Role: ECR Pull Role                                       │
│  ├─ Policy: ECR Pull-Only Policy (ECR pull only)           │
│  └─ SA: dify-plugin-runner-sa                              │
└────────────────────────────────────────────────────────────┘

Below are the ServiceAccount permission descriptions required by Dify Enterprise Edition:

Service Account	Component	Permission Description	Scope
`dify-enterprise`	Enterprise service	Has `get`, `list`, `watch` permissions for `namespaces`, used to retrieve and watch namespace information.	`Role` (namespace level)
`dify-plugin-sa`	Plugin Controller	Has full management permissions for `difyplugins` (CRD) and their `finalizers`/`status`, `leases`, `events`, `services`, `configmaps`, `deployments`, `jobs`, `ingresses`, and other resources.	`Role` (plugin namespace)
`dify-plugin-connector-sa`	Plugin Connector & Daemon	Inherits permissions from `dify-plugin-connector-role` (same as `dify-plugin-sa`).	`Role` (plugin namespace)
Custom Service Account	Various service components	Empty by default (uses `default` service account), can be configured via `values.yaml`.	As configured
`customServiceAccount`	Plugin custom service account	For custom permissions during plugin runtime, empty by default, can be specified via configuration.	As configured
`runnerServiceAccount`	Plugin Runner service account	Dedicated service account for plugin runner, empty by default, can be specified via configuration.	As configured

💡 Special Note About CRD Installation Dify Enterprise Edition only requires namespace-level permissions during installation. However, since CRD itself is a cluster-level resource, appropriate cluster permissions are required during installation. If you don’t have cluster-level permissions, you can install the CRD separately first, then install the remaining components. The CRD itself is just an API structure declaration registered in Kubernetes. When its corresponding Controller is namespace-level, it cannot access or modify resources across namespaces.

Step 1: Verify IAM OIDC Provider

Before configuring IRSA, ensure the cluster has IAM OIDC Provider enabled. If the cluster was created manually, it’s recommended to enable or verify using the eksctl command-line tool. The IAM OIDC Provider establishes a trust relationship that allows the EKS cluster to prove Pod identity to IAM, enabling Pods to securely obtain AWS permissions.

eksctl utils associate-iam-oidc-provider --cluster <your-cluster-name> --approve

IRSA configuration requires creating AWS Roles and Policies, as well as cluster ServiceAccounts. When creating ServiceAccounts, it’s recommended to keep the default names to avoid permission assignment failures due to conflicts with Helm configurations.

Step 2: Create AWS IAM Policies

You need to create the following three IAM policies: Policy 1: S3 Access Policy (name is customizable, e.g. DifyS3Policy)

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "s3:*",
            "Resource": "arn:aws:s3:::{your-s3-bucket}/*"
        }
    ]
}

Policy 2: ECR Full Access Policy (name is customizable, e.g. DifyECRPolicy) Used for plugin image push and management, including ECR authentication, repository management, image push, and audit logging permissions:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "ECRAuthAndDiscovery",
            "Effect": "Allow",
            "Action": [
                "ecr:GetAuthorizationToken",
                "ecr:DescribeRepositories",
                "ecr:DescribeImages",
                "ecr:GetRepositoryPolicy",
                "ecr:GetLifecyclePolicy",
                "ecr:GetLifecyclePolicyPreview"
            ],
            "Resource": "*"
        },
        {
            "Sid": "ECRRepoManagement",
            "Effect": "Allow",
            "Action": [
                "ecr:CreateRepository",
                "ecr:TagResource"
            ],
            "Resource": "*"
        },
        {
            "Sid": "ECRImagePush",
            "Effect": "Allow",
            "Action": [
                "ecr:BatchCheckLayerAvailability",
                "ecr:CompleteLayerUpload",
                "ecr:InitiateLayerUpload",
                "ecr:UploadLayerPart",
                "ecr:PutImage"
            ],
            "Resource": "arn:aws:ecr:{region}:{account_id}:repository/{your_ecr_repo_prefix}*"
        },
        {
            "Sid": "AuditLogging",
            "Effect": "Allow",
            "Action": "cloudtrail:LookupEvents",
            "Resource": "*"
        }
    ]
}

{your_ecr_repo_prefix} is the name prefix of your ECR repositories. For example, if you configure imageRepoPrefix in Step 5 as 123456789.dkr.ecr.us-east-1.amazonaws.com/dify-ee, then the ECR repository prefix here is dify-ee, and the Resource should be arn:aws:ecr:us-east-1:123456789:repository/dify-ee*.

Policy 3: ECR Pull-Only Policy (name is customizable, e.g. DifyECRPullOnlyPolicy) Used only for pulling plugin runtime images:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "ECRAuth",
            "Effect": "Allow",
            "Action": "ecr:GetAuthorizationToken",
            "Resource": "*"
        },
        {
            "Sid": "ECRImagePull",
            "Effect": "Allow",
            "Action": [
                "ecr:BatchGetImage",
                "ecr:GetDownloadUrlForLayer",
                "ecr:DescribeImages"
            ],
            "Resource": "arn:aws:ecr:{region}:{account_id}:repository/{your_ecr_repo_prefix}*"
        }
    ]
}

Step 3: Create AWS IAM Roles

Create the following three roles and attach the policies from Step 2 to the corresponding roles (role names can be customized):

Role Name (Example)	Attached Policies	Purpose
`DifyS3Role`	S3 Access Policy	S3 storage access
`DifyS3ECRRole`	S3 Access Policy + ECR Full Access Policy	S3 + ECR image push/management
`DifyECRPullRole`	ECR Pull-Only Policy	ECR image pull

Obtain the corresponding role ARNs:

DIFY_EE_S3_ROLE_ARN=arn:aws:iam::{account_id}:role/{your_s3_role_name}
DIFY_EE_S3_ECR_ROLE_ARN=arn:aws:iam::{account_id}:role/{your_s3_ecr_role_name}
DIFY_EE_ECR_PULL_ROLE_ARN=arn:aws:iam::{account_id}:role/{your_ecr_pull_role_name}

Each role’s Trust Policy needs to be configured for OIDC Provider federated authentication. Below is the Trust Policy template:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Federated": "arn:aws:iam::{account_id}:oidc-provider/oidc.eks.{region}.amazonaws.com/id/{oidc_id}"
            },
            "Action": "sts:AssumeRoleWithWebIdentity"
        }
    ]
}

Replace {oidc_id} with the OIDC Provider ID of your EKS cluster. You can obtain it with the following command:
aws eks describe-cluster --name <cluster-name> --query "cluster.identity.oidc.issuer" --output text | cut -d '/' -f 5

Step 4: Bind Roles to EKS ServiceAccounts

ServiceAccount (SA) is a mechanism that allows Pods in EKS to obtain specific AWS permissions to access cloud resources (such as S3).

Create the following four ServiceAccounts and add the corresponding role ARN to the eks.amazonaws.com/role-arn annotation:

ServiceAccount	Namespace	Bound Role	Effective Permissions
`dify-api-sa`	dify	S3 Access Role	S3 access
`dify-plugin-crd-sa`	dify	S3+ECR Access Role	S3 + ECR push/pull
`dify-plugin-runner-sa`	dify	ECR Pull Role	ECR pull only
`dify-plugin-connector-sa`	dify	S3 Access Role	S3 access (auto-assigned by Helm)

Example commands to create ServiceAccounts (replace $DIFY_EE_* with the role ARNs obtained in Step 3):

kubectl create serviceaccount dify-api-sa -n dify
kubectl annotate serviceaccount dify-api-sa -n dify \
  eks.amazonaws.com/role-arn=$DIFY_EE_S3_ROLE_ARN

kubectl create serviceaccount dify-plugin-crd-sa -n dify
kubectl annotate serviceaccount dify-plugin-crd-sa -n dify \
  eks.amazonaws.com/role-arn=$DIFY_EE_S3_ECR_ROLE_ARN

kubectl create serviceaccount dify-plugin-runner-sa -n dify
kubectl annotate serviceaccount dify-plugin-runner-sa -n dify \
  eks.amazonaws.com/role-arn=$DIFY_EE_ECR_PULL_ROLE_ARN

kubectl create serviceaccount dify-plugin-connector-sa -n dify
kubectl annotate serviceaccount dify-plugin-connector-sa -n dify \
  eks.amazonaws.com/role-arn=$DIFY_EE_S3_ROLE_ARN

Step 5: Configure ServiceAccount in values.yaml

Modify Helm’s values.yaml and add the following configuration (only ServiceAccount and ECR-related configurations are shown below, other configurations are omitted). imageRepoPrefix can be customized:

api:
  serviceAccountName: "dify-api-sa"
worker:
  serviceAccountName: "dify-api-sa"
workerBeat:
  serviceAccountName: "dify-api-sa"
plugin_connector:
  imageRepoSecret: "image-repo-secret" # Note: Even when using IRSA mode, you need to create this Secret, which can contain any content.
  customServiceAccount: "dify-plugin-crd-sa"
  runnerServiceAccount: "dify-plugin-runner-sa"
  imageRepoPrefix: "{account_id}.dkr.ecr.{region}.amazonaws.com/dify-ee" 
  imageRepoType: ecr
  ecrRegion: "{region}"

‼️ dify-plugin-connector-sa will be automatically assigned to the plugin_connector service through Helm Chart templates; dify-plugin-crd-sa and dify-plugin-runner-sa will be used for Pods that build and run plugins.

Access Key Mode Configuration

Step 1: Prepare Credentials

Create an IAM user with only S3 and ECR permissions, and obtain its Access Key and Secret Key.

Step 2: Create Kubernetes Secret

kubectl create secret generic image-repo-secret --from-file=<path to .aws/credentials>

This Secret needs to be configured for the plugin_connector service via imageRepoSecret in values.yaml in the next step.

Step 3: Configure values.yaml

persistence:
  type: "s3"
  s3:
    endpoint: "https://s3.{region_code}.amazonaws.com"
    region: "{region_code}"
    bucketName: "your_bucket_name"
    useAwsS3: true
    useAwsManagedIam: false
    accessKey: "{your access key}"
    secretKey: "{your secret key}"

plugin_daemon:
  enabled: true
  replicas: 1
  apiKey: "dify123456"

plugin_connector:
  apiKey: "dify123456"
  imageRepoSecret: "image-repo-secret"
  imageRepoPrefix: "{account_id}.dkr.ecr.{region}.amazonaws.com/dify-ee"
  imageRepoType: ecr
  ecrRegion: "us-west-2"

4. Install AWS ALB (Application Load Balancer)

To make Dify Enterprise Edition accessible via domain name, you need to install AWS ALB (Application Load Balancer). You can also choose to use Nginx Ingress Controller or other Ingress Controllers. AWS ALB is recommended because it integrates seamlessly with Dify Enterprise Edition and provides better performance and scalability. Please visit https://docs.aws.amazon.com/eks/latest/userguide/lbc-manifest.html for the AWS ALB installation guide.

If you cannot install AWS ALB, you can use Nginx Ingress Controller as an alternative:
kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/main/deploy/static/provider/kind/deploy.yaml

After AWS ALB installation is complete, you can confirm whether the service is running properly with the following command:

kubectl get deployment -n kube-system aws-load-balancer-controller

After installation, configure Ingress in values.yaml:

ingress:
  enabled: true
  className: "alb"  # Use AWS ALB Ingress Controller
  annotations: {
    kubernetes.io/ingress.class: alb,
    alb.ingress.kubernetes.io/scheme: internet-facing,
    alb.ingress.kubernetes.io/target-type: ip,
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}, {"HTTPS": 443}]',
    alb.ingress.kubernetes.io/ssl-redirect: '443',
    alb.ingress.kubernetes.io/certificate-arn: 'arn:aws:acm:{region}:{account_id}:certificate/{cert_uuid}', # You can fill in the domain certificate AWS ACM certificate
  }

*To publish Dify Enterprise Edition service via SSL certificate, configure the certificate in the ALB annotations and enable TLS in the global configuration. You can verify the domain and create a certificate through AWS Certificate Manager.

global:
  appSecretKey: 'owb3+S+C3b/4iG6YNAiWGIY4kOuX4MnUWHjcPxzyPKvGyxlQUISAWOmi'
  consoleApiDomain: "console.dify.yourdomain.com"
  consoleWebDomain: "console.dify.yourdomain.com"
  serviceApiDomain: "api.dify.yourdomain.com"
  appApiDomain: "app.dify.yourdomain.com"
  appWebDomain: "app.dify.yourdomain.com"
  filesDomain: "upload.dify.yourdomain.com"
  enterpriseDomain: "enterprise.dify.yourdomain.com"
  useTLS: true

5. Execute Installation

Please visit https://langgenius.github.io/dify-helm/#/ for detailed installation instructions.

‼️ It is not recommended to install Dify in the default namespace.

6. Verify Service Status

Update kubectl access credentials:

aws eks update-kubeconfig --region $AWS_REGION --name $CLUSTER_NAME

Verify EKS nodes are running properly:

kubectl get nodes

Verify Dify service status:

kubectl get pods -n {your namespace}

Confirm ALB is working properly:

aws elbv2 describe-load-balancers --output json

‼️ Please configure the DNSName from the above command output as a CNAME record, resolving to the various domains required by Dify.

7. Initialize Service

Installation is now complete. Please visit enterprise.dify.yourdomain.com to log in to the Dify Enterprise Edition admin console for further configuration and usage.

​Dify Enterprise Edition Deployment Guide (AWS)

​Option 1: Build via Terraform

​Prerequisites

​Option 2: Build via CDK

​Option 3: Manually Create Infrastructure and Deploy

​1. Create Infrastructure

​Testing Environment Infrastructure Configuration Reference

​Production Environment Infrastructure Configuration Reference

​2. Configure values.yaml

​3. Configure S3 and ECR Permissions

​IRSA Mode Configuration