dify

Dify 1.19.0 brings nested workflow tracing to your observability tools. Follow a workflow into the Workflow Tools it calls, inspect the steps inside each invocation, and keep the LLM context alongside the execution tree.

This release also makes Workflow Tools portable with App packages, adds Skill Hub automation, and makes Agent files easier to upload and preview. The bundled plugin daemon is upgraded to 0.6.14-local.

[Release highlights](#user-content-release-highlights) · [Upgrade guide](#user-content-upgrade-guide) · [Detailed changes](#user-content-detailed-changes)

Release highlights

Nested workflow tracing

See what happens inside a Workflow Tool, all the way down to its LLM calls.

Building on the Console drilldown introduced in 1.18.0, new external traces now include the persisted execution steps inside called Workflow Tools. Child steps appear beneath the Tool span that invoked them, preserving the hierarchy across nested and repeated calls. (#44673)

Langfuse trace tree showing a workflow, nested Middle and Child Workflow Tools, and the selected LLM call with formatted prompts and responses

*From the outer workflow to a nested LLM call: the execution tree and formatted messages, together in Langfuse. Screenshot from #44673.*

• Follow the hierarchy. Expand called Workflow Tools to see their internal execution steps under the invoking Tool span.
• Understand each invocation. Repeated calls and failures retain their place in the trace.
• Keep the LLM context. Inspect formatted prompts and responses, token usage, and project, trace, and observation links.

> [!NOTE]

> Your saved provider settings continue to work. The richer hierarchy applies to new executions; historical traces are not backfilled. Independently nested workflow runs remain separate traces linked by parent identifiers. For rolling deployments, follow the [tracing queue transition](#user-content-upgrade-guide) below.

Take Workflow Tools with your apps

Export an app and bring the workflows behind its Workflow Tools with it. .ifpkg packages include those workflows at their bound versions, including transitive dependencies. Import reuses tools already in the destination workspace and recreates, publishes, and registers missing ones, remapping their references. (#44592)

All Dify app exports now use package format v2, including apps without Workflow Tools. Existing v1 imports and explicit YAML export remain supported. See the [upgrade guide](#user-content-upgrade-guide) before importing new packages into older installations. (#45353)

Upload together. Preview in place.

Select or drop multiple Agent configuration files and upload them in parallel. Successful uploads are bound in one atomic batch, concurrent Composer saves preserve the latest files, and Prompt uploads keep the cursor position while inserting multiple references. (#44947)

Read PDFs inline, inspect source files with syntax highlighting, and see when text has been truncated. Previews cover configured files, Skill members, and working-directory files, with a download action when a PDF cannot be loaded. (#45032, #45045)

See Agent file uploads and previews

Inline PDF preview in Agent files, with the research brief and file list

*Read a PDF directly in the Agent file preview and switch between project files.*

Agent batch upload dialog with a PDF, Python source file, and Markdown guidelines selected

*Select several files and upload them together.*

Syntax-highlighted Python source in the Agent file preview

*Inspect source files with syntax highlighting and line numbers.*

Developer spotlight

Manage workspace Skills through OpenAPI and difyctl. Find and inspect Skills, export a draft or published version, import local files, and publish a new version from the command line. (#44941)

The six Skill commands

| Command | Capability |

| --- | --- |

| difyctl get skill | List Skills, with keyword and tag filters. |

| difyctl describe skill | Read details, the draft hash, and latest published version. |

| difyctl get skill version | List published versions. |

| difyctl export skill | Export the draft or a selected published version as ZIP. |

| difyctl import skill --files | Create a Skill or replace an existing Skill's draft from local files. |

| difyctl publish skill | Publish the draft as a new version. |

These operations require an account caller, the corresponding workspace permissions, and Skills to be enabled. Import does not publish. Importing over an existing Skill is classified as destructive; the operation catalog and CLI help distinguish read, write, and destructive operations. (#44941, #45314, #44587)

---

Upgrade guide

> [!IMPORTANT]

> Read the upgrade guide before deploying. Docker Compose now requires v2.35.0 or later. Preserve existing environment files, upgrade the Dify components together, and use the new tracing queue during rolling deployments. New App packages use format v2 and require a compatible destination importer. The bundled plugin daemon moves to 0.6.14-local.

Compatibility and rollout

• Back up first. Retain the database, vector-store data, uploaded files, Agent snapshot/workspace storage, deployment secrets, and environment files. Use a maintenance window for a single-stack upgrade.
• Upgrade the components together. Use matching 1.19.0 API, worker, web, Agent Backend, and Local sandbox images, with plugin daemon 0.6.14-local. Keep the existing Local sandbox authentication token and any configured PASSWORD_PEPPER unchanged. If upgrading from before 1.18.0, also follow the 1.18.0 upgrade guide.
• Use Docker Compose 2.35.0 or later. This is the minimum supported version for root .env overrides to take precedence when Compose resolves service defaults. Check your installed version with docker compose version. (#45359)
• Keep tracked defaults separate from local overrides. Bundled docker/envs/**/*.defaults files load automatically. Customize a service through its matching local .env file, using the override path documented in the defaults file; root docker/.env holds deployment inputs and explicit overrides. Preserve existing .env files and edit them in place. Review accidentally empty assignments and values pinned by older template copies before upgrading. (#45359, #45376)
• Existing shared.env files remain supported. Common API, worker, and Beat customizations now belong in docker/envs/core-services/api-worker.env. Compose still reads legacy docker/envs/core-services/shared.env first, then api-worker.env, so api-worker.env wins when both set conflicting values. Root docker/.env takes precedence over both. An unchanged copy of api-worker.defaults preserves existing shared.env customizations. See the Docker configuration guide. (#45376)
• Separate tracing queues during a rolling upgrade. New tasks default to OPS_TRACE_QUEUE=ops_trace_v2; API, workers, and Beat must agree. Custom CELERY_QUEUES, CELERY_WORKER_QUEUES, or --queues lists must include the new queue. Keep old tracing workers on ops_trace until old producers and all their queued, active, reserved, scheduled, and retry work have finished. Do not purge the old queue or ask the new retired handler to export legacy messages. See the tracing rollout guide. (#44673)
• Upgrade package destinations before importing new App packages. New app packages always use format v2. Older importers, including builds with the earlier strict v2 rule, may reject them. Version 1 imports remain supported on 1.19.0. Explicit YAML export remains available, but does not carry bundled Workflow Tool dependencies. (#44592, #45353)

Deployment instructions · Docker Compose, source, and difyctl

Docker Compose

Once the 1.19.0 release tag and images are published, stop a single-stack deployment gracefully, switch to the release, retain and review configuration, then pull and start the new images:

cd dify/docker
docker compose stop -t -1
git fetch --tags
git checkout 1.19.0
# Merge required configuration changes into existing env files here.
docker compose pull