Dify x SLS: Build a highly available production-grade AI architecture

Business context

By default, Dify stores workflow execution logs in PostgreSQL. In large-scale production environments, these logs typically consume significant database storage space, leading to connection pool exhaustion and scaling difficulties. The database's built-in search capabilities also struggle to meet multi-dimensional analysis requirements. Workflow logs are inherently write-once-read-many, schema-volatile, and high-throughput time-series data — characteristics that make a dedicated log storage system a more suitable storage layer. After migrating to SLS, PostgreSQL can focus on core business operations, while SLS provides elastic scaling, high-compression-ratio tiered storage, and a built-in analytics engine to retain and extract value from logs with lower storage costs.

Solution overview

Dify abstracts workflow log reads and writes through a standard Repository interface. SLS implements this interface as a plugin to replace the default storage driver. The plugin automatically handles the difference between SLS's append-only writes and workflow state transitions (recording multiple versions and reading the latest version on query), and automatically synchronizes indexes at startup with no additional configuration required.

Prerequisites

• Dify v1.12.0 or later.

Step 1: Prepare SLS resources and credentials

• Log on to the Simple Log Service console and create a project. We recommend selecting the same region as your Dify deployment.

You do not need to manually create a LogStore or indexes. After Dify starts, the plugin automatically detects and creates them.

• Obtain an AccessKey ID and AccessKey Secret with SLS read and write permissions. You can grant AliyunLogFullAccess, or configure least privilege permissions as needed. For more information about permissions configuration, see Use RAM for access control.

  Minimum permissions include: create/view Project, create/view LogStore, create/update/view indexes, write logs, and query logs.

Step 2: Configure environment variables for Dify

In the .env or docker-compose.yaml file of your Dify project, modify the following configuration items.

Set the Repository driver to the SLS plugin:

CORE_WORKFLOW_EXECUTION_REPOSITORY=extensions.logstore.repositories.logstore_workflow_execution_repository.LogstoreWorkflowExecutionRepository
CORE_WORKFLOW_NODE_EXECUTION_REPOSITORY=extensions.logstore.repositories.logstore_workflow_node_execution_repository.LogstoreWorkflowNodeExecutionRepository
API_WORKFLOW_NODE_EXECUTION_REPOSITORY=extensions.logstore.repositories.logstore_api_workflow_node_execution_repository.LogstoreAPIWorkflowNodeExecutionRepository
API_WORKFLOW_RUN_REPOSITORY=extensions.logstore.repositories.logstore_api_workflow_run_repository.LogstoreAPIWorkflowRunRepository

Add SLS connection configuration:

ALIYUN_SLS_ACCESS_KEY_ID=your_access_key_id
ALIYUN_SLS_ACCESS_KEY_SECRET=your_access_key_secret
ALIYUN_SLS_ENDPOINT=cn-hangzhou.log.aliyuncs.com  # Use internal endpoint for same-region deployments
ALIYUN_SLS_REGION=cn-hangzhou
ALIYUN_SLS_PROJECT_NAME=your_project_name
ALIYUN_SLS_LOGSTORE_TTL=365   # Log retention period in days

Step 3: Configure migration switches (for existing users)

To facilitate a smooth upgrade for existing PostgreSQL users, the plugin provides dual-write and dual-read switches:

LOGSTORE_DUAL_WRITE_ENABLED=false   # Dual-write, disabled by default
LOGSTORE_DUAL_READ_ENABLED=true     # Dual-read fallback, enabled by default

Recommended migration sequence:

1. For new deployments, keep the defaults (dual-write disabled, dual-read enabled).

2. For existing users migrating from PostgreSQL, enable dual-write (LOGSTORE_DUAL_WRITE_ENABLED=true) first for grayscale verification.

3. After verifying that logs are successfully written to SLS, disable dual-write once confirmed.

Step 4: Verify the integration

After configuration is complete, verify the integration by following these steps:

1. Restart Dify with the new configuration.

2. Confirm that the LogStore and indexes have been automatically created under your specified SLS project.

3. Run a workflow in Dify.

4. In the Dify console, open the log detail page and verify that the workflow record is displayed. Data is now read from SLS.

5. In the SLS console, open the corresponding LogStore and verify that logs have been written.

After integration, the log query and monitoring chart experience in the Dify console remains unchanged, while the underlying storage is switched to SLS.

Log analysis with SLS

After integration, in addition to viewing logs in the Dify console, you can perform more in-depth search, analysis, visualization, and alerting directly in the SLS console. The following examples use an e-commerce AI customer service assistant application.

Arbitrary field search: SLS supports full-text index and arbitrary key-value combination queries for fast and precise retrieval of logs with specific characteristics.

Business trend analysis (visualization): Analyze the PV trend of intent categories recognized by the "user intent recognition" node over time to support operational decisions:

* and title: user_intent_recognition and intent
| select json_extract(outputs, '$.intent') as "User Intent",
         date_trunc('minute', __time__) t,
         count(1) as pv
group by "User Intent", t
order by t
limit all

Anomaly diagnosis (funnel analysis): Observe the failure rate at each intermediate workflow node to identify high-anomaly areas:

status:succeeded
| select title, count(distinct workflow_run_id) cnt
group by title
order by cnt desc

Cost and risk control (real-time alerting): Configure alerting rules to monitor LLM node token consumption. When consumption exceeds a preset threshold, trigger notifications through instant messaging or phone calls.

Data pipeline (ETL and transformation): Use data transformation and scheduled SQL to clean, desensitize, and normalize workflow inputs and outputs, building continuously updated evaluation and training datasets.