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.

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 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 remaining variables are not set by the chart; 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.

Agent Configuration

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.

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.

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.

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: