Dify 1.19.0 adds nested workflow tracing and portable tools

Dify 1.19.0, released on November 4, 2026, makes it easier to inspect the work happening inside a Workflow Tool and move that tool with the app that uses it. The tagged GitHub release also adds Skill Hub automation and Agent file improvements. For operators, the main checks are the receiving app importer, Docker Compose version and tracing queue transition.

The most useful change is visibility into a call that previously looked like one step from the outside. A support workflow might invoke a reusable tool that retrieves documents, calls a model and formats an answer. When that tool fails, knowing its name is less helpful than seeing which internal step went wrong.

Trace the steps inside a Workflow Tool

The tracing implementation exports persisted execution steps beneath the Tool span that invoked them. Nested calls, repeated invocations and failures keep their place in that hierarchy. Formatted prompts, responses and token usage remain available alongside the execution records. Existing saved Langfuse settings continue working without reentering credentials or toggling tracing.

This applies to new executions. Historical exports do not gain missing nested spans after an upgrade. Separately executed nested workflow runs also remain separate traces, connected through parent identifiers. That distinction matters when investigating an older incident: updating the platform cannot recreate detail that was never exported.

The provider contract also distinguishes a retryable delivery failure from an uncertain result. If a backend may already have accepted a trace, the exporter drops that unit rather than risking a duplicate. Background publishing has bounded buffering, and a crash can lose events that have not yet been published. More detailed traces should therefore support investigation without being mistaken for a guaranteed complete audit record.

Before enabling broader collection, decide who may read prompts and responses and how long they should remain in the destination. For another approach to the same visibility question, ByteForward’s Claude Platform tracing guide explains the difference between application and provider tracing.

App packages carry their Workflow Tool dependencies

The packaging change addresses a concrete portability problem. Previously, an exported app could retain a tool identifier from its original workspace without bringing the underlying workflow. Importing it elsewhere could leave a reference that failed when called.

Packages now include the workflows at the versions their tools use, including dependencies called by those workflows. Import reuses tools already present in the destination. Missing ones are recreated, published and registered, with references redirected to them. This means importing a package can create additional apps and publish tool workflows, so the person importing needs tool management permission and enough app quota.

The release sets a default limit of 20 bundled tool workflows. Packages requiring DSL version confirmation are rejected in this import flow. Explicit YAML export remains available, but it does not bundle these dependencies. For a handoff between teams, agree on the receiving workspace and permissions before treating an export as ready to run.

Check the importer even for a simple app

A later compatibility change makes every new App package use format v2, including packages without Workflow Tools and nested app packages. That supersedes the earlier implementation’s split between v1 for simple packages and v2 for tool bundles.

An older importer can reject the new package even when it contains no Workflow Tool. Builds using the previous strict v2 validation rule also need the importer update. Dify 1.19.0 continues to accept v1 imports. The separate roster Agent package format is outside this change.

For teams moving apps between development and production, upgrade or verify the destination importer first. A successful export only establishes that the sending installation produced a package. It does not establish compatibility with the receiving installation.

Skills and files need fewer manual steps

The new workspace Skill operations let an account caller list, inspect, export, import and publish Skills through OpenAPI and difyctl. Access still depends on workspace permissions and Skills being enabled. Importing an existing Skill replaces its draft. Publishing remains a separate operation with a separate permission.

That separation is useful for a review process. A team can prepare a draft before deciding which version should become available. Teams should still coordinate simultaneous changes and retain a known published version before replacing a draft.

Agent configuration also gains parallel file uploads with one batch binding step. Failed individual uploads do not prevent successfully uploaded files from being eligible for binding. Concurrent Composer saves preserve the server’s latest configured files. Text previews gain syntax highlighting, while PDF previews and truncation notices make it clearer what the preview actually contains. These are editing conveniences, not evidence that the Agent has understood every file.

Plan the upgrade around configuration and queues

The tagged Docker guide requires Docker Compose 2.35.0 or later so root environment overrides take precedence when service defaults are resolved. Preserve existing environment files and edit them in place. Check for accidental empty assignments and old pinned values instead of replacing local configuration with a fresh template.

The release upgrade guide calls for matching 1.19.0 application components and plugin daemon 0.6.14-local. Back up the database, stored files, vector data, Agent storage and configuration. Keep existing sandbox authentication and password pepper values unchanged, and apply the complete migration chain.

One migration removes duplicate tracing configurations, retaining the newest row for each app and provider. Reversing the new index does not restore removed rows, so a database backup matters.

For a rolling deployment, the tracing change puts new work on ops_trace_v2. API, workers and Beat must agree, and custom worker subscriptions must include it. Keep old tracing workers isolated on ops_trace until old producers and queued, active, reserved, scheduled and retry work have drained. Do not purge that queue to finish faster.

A useful acceptance check is a small workflow that calls the same Workflow Tool twice, with an intentional failure in one invocation. Confirm that the external trace preserves the two calls and shows the expected failing step. Separately, import a representative app into a compatible test workspace and confirm that its recreated tools resolve correctly.

ByteForward has reviewed the release notes and implementation documentation, not run a Dify upgrade or reproduced these workflows. The release is most relevant to teams already relying on reusable Workflow Tools. Its value is easier diagnosis and more complete app transfers, provided the deployment and importer checks are handled first.