Skip to main content
Dify Enterprise deploys with Helm. Most variables are configured through your values.yaml file. The Helm chart writes a fixed set of variables into the API, web, worker, and enterprise ConfigMaps (with defaults drawn from values.yaml), and exposes the rest of the Dify application’s variables through the extraEnv field on each service.
The variables listed here are for reference. The Dify application reads many more variables than the Helm chart sets directly. For the complete application-level list, see the upstream .env.example. Any variable that is not set in values.yaml can be added through extraEnv (see FAQs). If you cannot find a variable in values.yaml, set it through extraEnv.
A default value listed as (Helm default) is the value the chart writes into the ConfigMap from values.yaml. All other defaults are the Dify application’s built-in defaults, which apply when the variable is not set through extraEnv.

Common Variables

These URL variables configure the public addresses of Dify’s services. The Helm chart derives them from the domain settings in values.yaml (global.consoleApiDomain, global.consoleWebDomain, and so on), so you normally set the domains rather than the variables directly.

CONSOLE_API_URL

Default: derived from global.consoleApiDomain The public URL of Dify’s backend API. Used to construct OAuth authorization callbacks (GitHub, Google login), Notion integration, and any plugin that requires OAuth. Also determines whether secure (HTTPS-only) cookies are used. Example: https://api.console.dify.ai

CONSOLE_WEB_URL

Default: derived from global.consoleWebDomain The public URL of Dify’s console frontend. Used to build links in all system emails (invitations, password resets, notifications) and to redirect users back to the console after OAuth login. Also serves as the default CORS allowed origin if CONSOLE_CORS_ALLOW_ORIGINS is not set. Example: https://console.dify.ai

SERVICE_API_URL

Default: derived from global.serviceApiDomain The API Base URL shown to developers in the Dify console: the URL they copy into their code to call the Dify API. Set this to ensure a consistent URL when your server is reachable through multiple addresses. Example: https://api.dify.ai

APP_API_URL

Default: derived from global.appApiDomain The backend API URL for the WebApp frontend (published apps). This variable is used by the web frontend container, not the Python backend. Example: https://api.app.dify.ai

APP_WEB_URL

Default: derived from global.appWebDomain The public URL where published WebApps are accessible. Required for the Human Input node in workflows: form links in email notifications are built as {APP_WEB_URL}/form/{token}. If empty, Human Input email delivery will not include valid form links. Example: https://app.dify.ai

TRIGGER_URL

Default: derived from global.triggerDomain The publicly accessible URL for webhook and integration trigger endpoints. External systems use this address to invoke your workflows. Dify builds trigger callback URLs like {TRIGGER_URL}/triggers/webhook/{id} and displays them in the console. For triggers to work, this must point to a public domain or IP that external systems can reach.

FILES_URL

Default: derived from global.filesDomain The base URL for file preview and download links. Dify generates signed, time-limited URLs for all files (uploaded documents, tool outputs, workspace logos) and serves them to the frontend and multi-modal models. To prevent forgery, file URLs are signed and expire (see FILES_ACCESS_TIMEOUT). Example: https://upload.example.com

INTERNAL_FILES_URL

Default: (empty; falls back to FILES_URL) The file access URL used for communication between services inside the cluster (for example, the plugin daemon and document extractors). Internal services may not be able to reach the external FILES_URL if it routes through an ingress or public domain. Set this through extraEnv when internal services can’t reach the external URL. Example: http://dify-api-svc:5001

FILES_ACCESS_TIMEOUT

Default: 300 (5 minutes) How long signed file URLs remain valid, in seconds. After this time, the URL is rejected and the file must be re-requested. Increase for long-running processes; decrease for tighter security.

Server Configuration

Logging

General

SECRET_KEY

Default: set by the chart (see your deployment’s secret configuration) Used for session cookie signing, JWT authentication tokens, file URL signatures (HMAC-SHA256), and encrypting third-party OAuth credentials (AES-256). The Helm chart manages this through a secret.
Changing this key after deployment will immediately log out all users, invalidate all file URLs, and break any plugin integrations that use OAuth, since their encrypted credentials become unrecoverable.

KEY_PROVIDER_TYPE

Default: local Choose where Dify keeps the keys used to encrypt workspace credentials, such as model-provider and tool secrets:
  • local: stores each workspace’s RSA private key in the configured STORAGE_TYPE backend.
  • azure-keyvault: keeps workspace RSA keys in Azure Key Vault. The private key stays in the vault; authentication uses Azure DefaultAzureCredential.
Choose the provider before creating credentials. Changing providers on an existing installation makes existing credentials unreadable with the new provider; it does not migrate them.
Keep KEY_PROVIDER_TYPE and, for Azure, AZURE_KEYVAULT_VAULT_URL consistent across the Dify application services and plugin_manager. Set them through api.extraEnv, worker.extraEnv, workerBeat.extraEnv, and plugin_manager.extraEnv. For each entry in additionalWorkers, also set these variables in its own extraEnv; it does not inherit worker.extraEnv. For azure-keyvault, configure these variables:

Token & Request Limits

Worker Configuration

The Helm chart manages worker counts through values.yaml rather than environment variables. serverWorkerAmount controls API Gunicorn workers, and celeryWorkerAmount controls Celery workers per worker deployment. Set them in values.yaml.

API Tool Configuration

Database Configuration

The Helm chart configures the main database connection (host, port, credentials, database name) through values.yaml and the shared database ConfigMap, not through individual DB_* variables. The variables below tune the application’s connection pool and can be set through extraEnv.

Redis Configuration

The Helm chart configures Redis connectivity through values.yaml (the shared Redis configuration). The application supports standalone, Sentinel, and Cluster modes. The variables below are the application-level knobs; in a Helm deployment, prefer the chart’s Redis settings, and use extraEnv for tuning.

Redis SSL Configuration

Only applies when REDIS_USE_SSL=true.

Redis Connection Resilience

Celery Configuration

The Helm chart manages the Celery broker connection through values.yaml and the shared Celery secret. The variables below are application-level tuning knobs.

CORS Configuration

Controls cross-domain access policies for the frontend. The chart writes these only when set in values.yaml.

File Storage Configuration

Configure where Dify stores uploaded files, dataset documents, and encryption keys. Each storage type has its own credential variables; configure only the one you use. In Helm deployments, set these through extraEnv unless the chart already exposes them.

STORAGE_TYPE

Default: opendal Selects the file storage backend. Supported values: opendal, s3, azure-blob, aliyun-oss, google-storage, huawei-obs, volcengine-tos, tencent-cos, baidu-obs, oci-storage, supabase, clickzetta-volume, local (deprecated; internally uses OpenDAL with the filesystem scheme).
Default storage backend using Apache OpenDAL, a unified interface supporting many storage services. Dify automatically scans environment variables matching OPENDAL_<SCHEME>_* and passes them to OpenDAL. For example, with OPENDAL_SCHEME=s3, set OPENDAL_S3_ACCESS_KEY_ID, OPENDAL_S3_SECRET_ACCESS_KEY, etc.For all available schemes and their configuration options, see the OpenDAL services documentation.
ClickZetta Volume reuses the CLICKZETTA_* connection parameters configured in the Vector Database section.

Archive Storage

Separate S3-compatible storage for archiving workflow run logs. Used to archive workflow runs older than the retention period to JSONL format.

Vector Database Configuration

Configure the vector database used for knowledge base embedding storage and similarity search. Each provider has its own set of credential variables; configure only the one you use.

VECTOR_STORE

Default: weaviate Selects the vector database backend. If a dataset already has an index, the dataset’s stored type takes precedence over this setting. Supported values: weaviate, oceanbase, seekdb, qdrant, milvus, myscale, relyt, pgvector, pgvecto-rs, chroma, opensearch, oracle, tencent, elasticsearch, elasticsearch-ja, analyticdb, couchbase, vikingdb, opengauss, tablestore, vastbase, tidb, tidb_on_qdrant, baidu, lindorm, huawei_cloud, upstash, matrixone, clickzetta, alibabacloud_mysql, iris, hologres.
seekdb is the lite version of OceanBase and shares the same connection configuration.

Knowledge Configuration

Annotation Import

Model Configuration

Multi-modal Configuration

Sentry Configuration

Sentry provides error tracking and performance monitoring. In Helm deployments, enable Sentry per service through values.yaml (api.sentry, worker.sentry, web.sentry).

Notion Integration Configuration

Connect Dify to Notion as a knowledge base data source. Get integration credentials at https://www.notion.so/my-integrations.

Mail Configuration

Dify sends emails for account invitations, password resets, login codes, and Human Input node notifications. Configure one of the three supported providers. Email links require CONSOLE_WEB_URL to be set (see Common Variables).
Three TLS modes: implicit TLS (SMTP_USE_TLS=true, SMTP_OPPORTUNISTIC_TLS=false, port 465), STARTTLS (SMTP_USE_TLS=true, SMTP_OPPORTUNISTIC_TLS=true, port 587), or plain (SMTP_USE_TLS=false, port 25).
For more details, see the SendGrid documentation.

Others Configuration

Indexing

Token & Invitation

All token expiry variables control how long a one-time-use token stored in Redis remains valid. After expiry, the user must request a new token.

Code Execution Sandbox

The sandbox is a separate service that runs Python, JavaScript, and Jinja2 code nodes in isolation. The chart sets CODE_EXECUTION_ENDPOINT automatically to the in-cluster sandbox service.

Workflow Runtime

Workflow Tracing

These settings apply to workflow tracing integrations in the API and workers, separately from OpenTelemetry instrumentation. With unified tracing enabled, keep OPS_TRACE_PARENT_CONTEXT_TTL_SECONDS at least OPS_TRACE_RETRYABLE_DISPATCH_MAX_RETRIES multiplied by OPS_TRACE_RETRYABLE_DISPATCH_DELAY_SECONDS. A lower value fails application configuration validation. The retry delay defaults to 5 seconds and can be changed through extraEnv. With the default retry count and delay, the minimum parent-context TTL is 780 × 5 = 3900 seconds.

Workflow Storage Repository

These select which backend implementation handles workflow execution data. The default SQLAlchemy repositories store everything in the database.

GraphEngine Worker Pool

Workflow Log Cleanup

The chart enables this through workerBeat.enableWorkflowLogCleanup, which sets WORKFLOW_LOG_CLEANUP_ENABLED on the beat ConfigMap. The chart does not set the remaining variables; configure them through extraEnv on the worker and beat services.

HTTP Request Node

These configure the HTTP Request node used in workflows to call external APIs.

Webhook

SSRF Protection

All outbound HTTP requests from Dify (HTTP nodes, image downloads, etc.) are routed through a proxy that blocks requests to internal/private IP ranges, preventing Server-Side Request Forgery (SSRF) attacks. The chart sets SSRF_PROXY_HTTP_URL and SSRF_PROXY_HTTPS_URL automatically when the SSRF proxy is enabled. For Helm deployments, configure SSRF proxy policies in values.yaml:
  • Use ssrfProxy.squidConf for Code node sandboxes. API and worker requests routed through the same proxy share this policy.
  • Use sandboxGateway.ssrfProxy.squidConf for the separate policy applied to Agent sandboxes managed through Sandbox Gateway.
Adding the two Docker Compose allowlist variables to ssrfProxy.extraEnv does not change the proxy policy.

Agent Configuration

UPLOAD_SKILL_FILE_SIZE_LIMIT

Default: 50 Maximum size in MiB for a .zip or .skill package imported into the skill library or uploaded to an agent as an embedded skill. Set it through api.limits.uploadSkillFileSize.

Dify CLI and Programmatic API

Web Frontend Service

These variables are used by the Next.js web frontend container only, and do not affect the Python backend.

Enterprise-Specific Configuration

These variables apply only to Dify Enterprise. The Helm chart sets them on the API and worker ConfigMaps when enterprise.enabled is true.
Dify Enterprise 3.13.0 replaces the ENTERPRISE_ENABLED variable with DEPLOYMENT_EDITION (ENTERPRISE or COMMUNITY). The chart sets the new variable automatically; when upgrading, update any extraEnv entries, custom overlays, or automation that still reference ENTERPRISE_ENABLED.

Deployed Environments (App Runner)

These variables configure deployed environments that you create under Environments in the Enterprise Dashboard and deploy apps to. The Enterprise service runs each environment’s apps in App Runner workloads that it creates in Kubernetes. An environment in Shared mode gets one workload for all its apps, and in Isolated mode each app gets its own. The chart writes these variables to the enterprise ConfigMap and Secret. They don’t affect Studio runs or an app’s built-in environment, which serves what you publish. Those run on the API and workers and follow the rest of this page. Before you install or upgrade, replace the #REPLACE_ME# placeholders in enterprise.appRunner.controlSigningKey and enterprise.webappPassportSigningKey with your own secret values. If you use ExternalSecret, add both to the remote secret named in global.externalSecret.remoteKey (dify by default), as properties enterprise.appRunner.controlSigningKey and enterprise.webappPassportSigningKey.
Two settings limit how long a run can take, and they cover different runs:
  • Runs in deployed environments: enterprise.workflowMaxExecutionTimeSeconds, 1200 seconds (20 minutes) by default.
  • Studio runs and built-in environments: api.workflowMaxExecutionTimeSeconds, 3600 seconds (60 minutes) by default.
Both appear as WORKFLOW_MAX_EXECUTION_TIME, but in different ConfigMaps, and changing one doesn’t change the other. Because the defaults differ, a workflow that finishes in Studio can still stop mid-run once it’s deployed.Test long-running workflows in a deployed environment before relying on them there.
The chart generates these variables, and they need no configuration:

App Runner Telemetry

The chart sets these variables only when both global.otel.enabled and enterpriseCollector.enabled are true, as they are by default. With either one off, App Runner workloads send no telemetry.

Enterprise Telemetry

OpenTelemetry export for enterprise audit and tracing. The chart enables these when both enterprise.enabled and global.otel.enabled are true, wiring the endpoint to the in-cluster enterprise collector.

ModelProvider & Tool Position Configuration

Customize which tools and model providers are available in the app interface and their display order. Use comma-separated values with no spaces between items. The chart writes these from api.positionTool and api.positionProvider in values.yaml.

Plugin Daemon Configuration

The plugin daemon is a separate service that manages plugin lifecycle (installation, execution, upgrades). The chart sets the daemon URL, key, and marketplace settings automatically when the plugin daemon is enabled.

Agent Backend Configuration

These variables are set on the agent-backend service, which powers the Agent feature. See Agent Sandbox Deployment for the full setup.

Agent Snapshot and File Transfer Timeouts

These timeouts control request and transfer waits separately from the Agent run execution deadline. All values are in seconds and must be greater than 0; higher values allow longer waits before a timeout. Keep DIFY_AGENT_BINDING_FILE_DOWNLOAD_COMMAND_TIMEOUT_SECONDS above the CLI upload deadline of 180 seconds and below AGENT_BACKEND_BINDING_FILE_DOWNLOAD_TIMEOUT_SECONDS.

Agent Backend HTTP Clients

These settings apply to the Agent backend’s HTTP clients for the Dify API and plugin daemon. Each client has its own connection pool, shared across the Agent runs that use it. Longer timeouts allow slower operations and delay timeout errors. Raising connection limits can reduce waits for a free connection but increases concurrent load on the target service. Keeping more idle connections or retaining them longer improves reuse but holds resources.

OTLP / OpenTelemetry Configuration

Application-level OpenTelemetry instrumentation (distinct from the enterprise telemetry above). When enabled, Dify instruments Flask and exports telemetry to an OTLP collector.

Miscellaneous

Scheduled Tasks Configuration

Dify uses Celery Beat to run background maintenance tasks on configurable schedules. For conversation cleanup, set workerBeat.conversationCleanup.enabled to enable or disable the task, workerBeat.conversationCleanup.intervalMinutes for the interval, and workerBeat.conversationCleanup.batchSize for the batch size. The chart applies these values to the API, all workers, and Celery Beat.

Record Retention & Cleanup

Aliyun SLS Logstore Configuration

Optional integration with Aliyun Simple Log Service for storing workflow execution logs externally instead of in the database.

Event Bus Configuration

Redis-based event transport between API and Celery workers.

Plugin Daemon Storage Configuration

The plugin daemon can store plugin packages in different storage backends. Configure only the provider matching PLUGIN_STORAGE_TYPE.

FAQs

How do I set a variable that is not in values.yaml?

Add it through the extraEnv field for the service that needs it (api, worker, or web). For example, to set two variables on the API service:
The same pattern applies to worker.extraEnv and web.extraEnv. Set the variable on every service that reads it.

How do I configure HTTP_PROXY and HTTPS_PROXY?

For security reasons, you may need to route the Dify API service’s outbound traffic through a proxy. Use the extraEnv field: