How Dify sends LangSmith traces from your own deployment
A team that runs Dify for workflows and agents often wants LangSmith traces without rebuilding its app flows. Dify has a built-in tracing integration with LangSmith, configured per app, so the existing workflows and chat apps can keep their structure while traces are exported. The important point for a regulated team is that trace content leaves your deployment when the integration is enabled. LangSmith is a hosted service, so the prompts, model inputs, outputs and intermediate node data that Dify sends are stored on the LangSmith side, outside the infrastructure you control.
LangSmith is one of several tracing integrations that Dify lists in its monitoring documentation, alongside Langfuse, Opik, W&B Weave, Arize Phoenix and others. The Dify docs describe LangSmith as a platform for developing, collaborating, testing, deploying and monitoring LLM applications, so its role is observability and evaluation for the application team. Before enabling it, confirm with your data owners which apps handle customer records, employee data or other regulated content, and whether LangSmith's data residency and contract terms match that classification. Check the current setup steps in the Dify docs on LangSmith integration before you plan the rollout, since the configuration fields are defined there rather than in this page.
Treat the decision as a per-app data classification exercise, not a single platform switch. Apps that process only public or synthetic content can use the integration as configured, while apps with sensitive inputs need an explicit approval, a documented data flow and a plan to disable tracing for them. The same decision determines whether a self-hosted tracing backend is a better fit, which the comparison later on this page covers in detail. Record who approved the export and which apps are included, because the change is easy to make in the console and easy to forget during a later review.
What you need before enabling LangSmith tracing in Dify
Tracing from a self-hosted Dify to LangSmith depends on a few pieces working together: a supported Dify baseline, a LangSmith project and key that the team controls, and a network path from the Dify API and worker to LangSmith. Check each one before you enable tracing on any app, because a missing egress rule or an unowned key is easy to miss until traces stop appearing.
Dify version and host baseline
The Docker Compose deployment requires at least 2 CPU cores and 4 GB of RAM, plus Docker Compose 2.24.0 or later. Confirm the host meets these before adding tracing, since the tracing setting runs inside the same api and worker services that already handle every request. Pin the Dify version you tested, and read the upgrade guide for that release before changing it, because minor releases arrive roughly monthly.
LangSmith account and project
Create the LangSmith workspace and a dedicated project for each Dify environment, such as one for staging and one for production. Separate projects keep test prompts out of production dashboards and make retention and access decisions easier to apply. Ask who in your organization will own the account, who receives invitations, and how the account is closed when staff change roles.
Team-owned LangSmith API key
Generate the key under a team or service identity rather than a personal login, so tracing continues when an engineer leaves. Store it in your secret manager and enter it only through Dify's tracing configuration, never in shared notes or app exports. Confirm the current key format and where the key is created in the Dify LangSmith integration docs, rather than assuming the format from another tool.
Outbound HTTPS from the Dify API and worker
Trace export is sent by Dify's backend, so the api and worker containers need outbound HTTPS to the LangSmith endpoint, not the browser. Confirm the exact endpoint hostname in the integration docs, then test egress from inside those containers using the same network path production uses. If your firewall or cloud egress policy allows only named destinations, add the LangSmith host to that list before enabling tracing.
SSRF proxy allowlist for egress
If outbound requests pass through the SSRF proxy, the proxy blocks internal and private IP ranges by design. A public LangSmith hostname should resolve and pass, but a proxy rule, DNS override or corporate egress gateway can still block it. Review the SSRF_PROXY settings with your network team, add only the LangSmith host you verified, and avoid broad allowlists that weaken the proxy's purpose.
Decision on prompt data leaving your network
LangSmith is a hosted SaaS service, so traces carry prompts, inputs, outputs and token counts out of your environment. Before enabling it, get sign-off from security and compliance on what data each app may send, and whether any apps should stay on a self-hosted tracing backend. Record the decision per app so the scope is clear when auditors or data owners ask.
Configuring LangSmith tracing per Dify app, step by step
This sequence connects each Dify app to its own LangSmith project, proves that workflow and chat runs arrive there, and leaves a register that shows which app sends traces where. Each step ends with a check you can record before moving on.
Create the LangSmith project and API key
A team member with administrative rights in your LangSmith organization creates a project for the first Dify app and generates an API key for that integration. Before this step, confirm with your privacy and security owners that prompts, inputs and outputs may leave your network, because LangSmith is a hosted service. Store the key in your secrets manager, record which LangSmith organization and workspace it belongs to, and name a key owner. Done when the project appears in LangSmith and the key is in your secret inventory. Confirm the current key creation steps in LangSmith's own documentation, since its interface changes over time.
Set a project naming rule before tracing
Agree on one naming pattern that ties each LangSmith project to exactly one Dify app and environment, for example a pattern such as support-triage-staging (illustrative). The platform team and the app owners should approve the list before any key is entered into Dify. Done when every planned Dify app has a proposed LangSmith project name, no two apps share a project, and staging and production runs are kept apart. This naming check is what lets you match traces to apps in step 6.
Open the tracing settings for one app
In Dify, open the first app you plan to trace and find its monitoring or tracing settings in the app's configuration. Tracing is set per app, so each app needs its own entry, and a setting on one app does not cover the others. Select LangSmith from the list of tracing integrations. The Dify integration guide for LangSmith is the reference for the exact menu path in your version: Dify's LangSmith integration guide. Done when the LangSmith settings form is open for that app. If the option is missing, check your Dify version against the Dify releases page before continuing.
Enter the project name and key, then save
Paste the API key from step 1 and the project name from step 2 into the LangSmith form, and use the endpoint that the Dify integration guide specifies. Save the settings and enable tracing for this app. Done when the saved form shows the project name and a masked key, and the key is not written into any file you share. Dify's export of an app as a YAML DSL file excludes third-party API keys, so the key must be recovered from your secret store, not from an export. Also confirm that the api and worker containers can reach the LangSmith endpoint through your outbound proxy configuration, since the SSRF proxy blocks private address ranges and must still allow this public destination.
Run one workflow test and one chat session
Run one workflow test from the editor and one chat session from the app's preview. Use synthetic test inputs with no customer or patient data, and write down the exact input text and the time of each run. The workflow run exercises node-level tracing, while the chat session exercises message-level tracing, so both are needed. Done when Dify reports both runs as completed without errors in its own logs. If a run fails, fix the app or model configuration before judging the tracing itself, because a failed run can look like a missing trace.
Confirm both traces in the matching project
Open the LangSmith project whose name matches this app and locate the workflow run and the chat run from step 5. Check that the workflow trace shows the node sequence, that the chat trace shows the input and output messages, and that token counts appear where Dify sends them. If Dify exposes a trace or run identifier for a run, confirm the same identifier appears in LangSmith. If it does not, match the runs by input text and timestamp. If a run lands in a different project or does not appear, check the project name, the key and the outbound path before retrying.
Repeat per app and keep a tracing register
Repeat steps 3 to 6 for each remaining app, one app at a time, so a failure is easy to trace to a single configuration. Keep a register with the Dify app name, environment, LangSmith project, key owner, and the date each trace was last verified. Done when every app has a verified trace in its own project and the app owner and platform team have signed off the register. Review the register after each Dify upgrade, because upgrade notes and new environment variables can change the surrounding configuration, and take a backup before upgrading.
Which Dify trace fields map to LangSmith runs
This table maps the main Dify trace objects to the project, run and metadata concepts LangSmith uses. Read the right-hand column as a verification checklist, since the supplied sources do not confirm every field name, nesting level or export. The main takeaway is that prompts, outputs and error text leave your network with each trace, so confirm every field in a test trace before production traffic is sent.
| Dify object | Likely LangSmith concept | What to confirm in a test trace |
|---|---|---|
| Dify app | One LangSmith project per app, if the Dify docs confirm per-app configuration | Project name and API key scope for each app in a test workspace |
| Workflow or chatflow run | Top-level run within the project | Whether the root run name matches the app name and run type |
| Message (chat conversation) | Metadata or grouping on the root run, tied to a conversation | Whether the conversation identifier is exported and how it is grouped |
| Node execution | Child runs nested under the root run | Nesting depth, node titles and execution order |
| Model input and output | Inputs and outputs on the LLM child run | Whether full prompt text, variable substitution and completions are captured |
| Token usage | Usage values on the LLM run, if exported | Not confirmed by the supplied sources; check whether Dify exports token counts at all |
| Error information | Error field on the failing node run or root run | Force a failing node on purpose and confirm the error text appears |
| Workspace and end-user identifiers | Metadata or tags on the run, if exported | Whether user or workspace IDs leave Dify, since they may be absent or hashed |
When LangSmith fits and when self-hosted tracing is the better choice
If your data policy allows prompts, model outputs and retrieved document text to be sent to a hosted service under a reviewed contract, LangSmith is a straightforward option to evaluate. Dify's monitoring docs list LangSmith as a platform for developing, collaborating, testing, deploying and monitoring LLM applications, alongside tracing integrations such as Langfuse, Opik, W&B Weave, Arize and Phoenix. Choosing LangSmith means your team accepts a SaaS operating model: the vendor runs the trace store, and your team manages projects, keys and access rather than databases.
- Operations load: Your platform team does not run a trace database, its backups or its upgrades. The cost is a dependency on the vendor's availability and retention terms.
- Data flow: Traces carry the content of prompts and responses, so the data processing terms, region and sub-processors matter as much as the feature list.
- Key management: Each Dify app's tracing configuration holds a LangSmith API key. Assign keys per project and rotate them on a schedule your security team sets.
- Access review: Confirm who in your organization can open traces, export them and invite people to the LangSmith workspace.
- Procurement: Ask the vendor for its current pricing and plan limits in writing, because hosted trace volume usually drives the bill.
Before approving this path, confirm the contract terms, data region and retention settings with the vendor and your legal and privacy teams.
If your policy keeps prompt data, retrieved content and user identifiers inside your own network, a SaaS tracing service is usually not an option. In this case, the tracing backend should run in infrastructure you control. Dify's tracing list includes self-hosted choices such as Langfuse, Arize Phoenix and Opik, and each one needs its own evaluation against your environment. The trade-off is operational: you take on the hosting, storage sizing, backups and upgrades that a SaaS vendor would otherwise run.
- Data location: Self-hosted tracing keeps trace payloads on your servers, which simplifies residency and deletion requests but makes your team responsible for both.
- Operations load: Plan for database storage, retention jobs, access control and version upgrades for the tracing service, in addition to Dify itself.
- Feature depth: Feature sets differ between tools. Compare how each handles the trace fields Dify exports, such as node-level data, token counts and errors, using a test app rather than assumptions.
- Network path: Your Dify instance must reach the tracing endpoint, and that path should be internal. Confirm any outbound allowlisting in the SSRF proxy configuration.
- Staffing: Name an owner for the tracing service before go-live, including who responds when traces stop arriving.
Ask each candidate vendor which deployment methods it supports and how it documents upgrades, then test the chosen tool with synthetic prompts before real data is sent.
Some organizations allow certain applications to use a hosted tracing service while requiring others to stay internal. This split works when the classification of each Dify app is clear and recorded. A marketing assistant that handles public product text may fit the SaaS path, while an internal policy assistant with employee or customer records may not. The design work is in drawing that boundary and enforcing it in configuration, not in the tool selection alone.
- Classification first: Assign each Dify app a data class before choosing a tracing backend, and record the decision in your application inventory.
- Separate projects: Use distinct tracing projects and keys for each class so that an app's traces cannot be sent to the wrong backend by accident.
- Review on change: When an app's inputs change, such as adding a knowledge base with customer records, repeat the classification and move its tracing if needed.
- Two operating models: Your team may need to support both a hosted service and a self-hosted tool, which increases training and access reviews.
- Consistent fields: Standardize which trace fields your teams rely on so that dashboards and investigations work across both backends.
Write the split as a rule your reviewers can apply to a new app, and test that a sensitive app's traces never reach the hosted endpoint.
Controls for API keys, prompt data and egress
Tracing sends prompts, outputs and metadata from your Dify apps to a LangSmith project, so the controls sit in three places: where the LangSmith key lives, what data leaves the Dify instance, and which outbound paths the Dify containers can reach. The cards below cover each control and the points to confirm with the vendor and in your own environment.
Keys stored per app in Dify
Tracing credentials are entered in each Dify app's monitoring settings, so the LangSmith key is held by Dify rather than in your repository or .env files. Decide whether each app or each environment gets its own LangSmith key, so one leaked credential does not expose every project. Confirm with Dify where the key is stored at rest and who in the workspace can view or change it, since workspace roles govern access to app settings.
Rotation and revocation plan
Plan how a LangSmith key is replaced without breaking traces. Create the new key in LangSmith, update the app's tracing configuration in Dify, confirm new traces arrive, then revoke the old key. Record which apps use which key so a rotation does not miss one. Confirm with LangSmith how keys are created, scoped and revoked in your plan, because the Dify documentation does not describe a rotation procedure.
Least-privilege LangSmith project access
Give the tracing key access only to the LangSmith project that receives that app's traces, and keep developer and reviewer access separate from that key. Restrict who in your organization can read traces, since a trace can contain full prompts and retrieved document text. Confirm the LangSmith role model and whether key scopes can be limited to a single project before you rely on that boundary.
Redaction and exclusion decisions
Decide before go-live which inputs must not leave your network in a trace, such as personal data in user messages, retrieved records or credentials pasted into prompts. Options include changing the app's inputs, limiting what knowledge is retrieved, or redacting at the source. Dify's tracing docs do not describe field-level redaction for LangSmith, so confirm with the vendor and test with sample data in a non-production app.
SECRET_KEY and stored credentials
The Dify environment reference says SECRET_KEY signs session cookies and JWTs and encrypts OAuth credentials, and that changing it after deployment logs out all users. Treat the value as a managed secret, set it before first use, and plan a maintenance window if it must change. Stored tracing keys are a different question, so confirm with Dify how they are encrypted before assuming SECRET_KEY protects them.
Egress allowlisting and the SSRF proxy
Dify's SSRF_PROXY settings route outbound requests through a proxy that blocks internal and private IP ranges, which protects against requests into your network. Tracing traffic goes to the LangSmith endpoint, so the firewall rule for the Dify host should allow that destination explicitly and deny other egress. Confirm the LangSmith hostnames and ports with the vendor, and test the path from the Dify containers before go-live.
Why LangSmith traces are missing or mislinked
Why do my Dify traces never appear in LangSmith?
The most common cause is a wrong API key or project name in the app's tracing settings, so the traces are sent but rejected or filed elsewhere. Open the app's monitoring settings in Dify, confirm the LangSmith key is the one created for the workspace you are checking, and confirm the project name matches the LangSmith project exactly. Then run one test message in the app and look for a new run in that project within a few minutes. If nothing arrives, check the Dify API logs for authentication or 4xx responses from the LangSmith endpoint, since those usually name the rejected key or the failing call.
Can the SSRF proxy or a firewall block LangSmith traces?
Yes. Dify sends outbound requests through the SSRF proxy configured by the SSRF_PROXY settings, and that proxy is built to block internal and private address ranges. If the proxy path or your egress firewall does not allow the LangSmith API host over HTTPS, the trace export fails without any message in the chat. Test egress from the API container with the same proxy settings Dify uses, confirm the LangSmith hostname resolves and is reachable, and ask your network team whether any allowlist applies to containers that reach SaaS endpoints. Check the proxy and firewall logs for denied requests at the time of a test message.
Why do traces show up in a different LangSmith project?
Traces land in an unexpected project when the project name is set per app but one app still points to a project left over from testing, or when two apps share a key and a default project. Compare each app's tracing configuration with the project list in LangSmith and note which project receives its runs. Use one project per app or per environment, name them consistently, and record the mapping so that a reviewer can trace each production app to exactly one project. Move any misdirected runs by fixing the configuration, since the existing runs are not re-filed automatically.
Why are workflow runs missing when the chat looks fine?
Runs executed by background workers may be recorded differently from interactive requests, so a successful chat response does not prove that every node or asynchronous task was exported. Trigger the same workflow from the same path your users take, such as a scheduled or webhook run, then compare the LangSmith run tree with the Dify run history for that execution. If the worker-side runs are absent, check that the worker containers share the same environment and tracing settings as the API service, then review worker logs during the test. Confirm the exact behavior for your Dify version in the Dify documentation before you rely on it for audit evidence.
What happens to traces when I rotate a LangSmith API key?
Rotating the key in LangSmith without updating every Dify app stops exports from those apps, and the failures are easy to miss because the chat still works. Each app stores its own tracing configuration, so a single key change in one place does not reach the others. Before rotating, list every app with tracing enabled and plan the update as a change ticket. After rotating, update each app, send a test message from each one, and confirm a new run appears in its project. Keep the old key active until that check is complete, and revoke it only after every app has been verified.
Why does a LangSmith trace show incomplete prompt or token data?
Missing fields usually come from the way a node or model call reports its data, not from LangSmith itself. Compare a trace with the Dify run log for the same message. If a node is present but its inputs, outputs or token counts are empty, check whether that model provider returns usage data for the call and whether the node type is one that Dify reports to the tracing integration. Treat LangSmith as a view of what Dify sent, and validate the exported fields on a known test input before you use them for cost or quality reporting.
Who should own tracing configuration after the first setup?
The team that operates the Dify deployment should own it, with a named owner for each app's tracing destination. Without that owner, keys drift, projects multiply and rotations are missed. Record the app name, the LangSmith project, the key's owner and the rotation date in your configuration register. Review the register whenever an app is published, cloned or retired. If your organization cannot keep this current internally, confirm with a partner what ongoing support would cover before the engagement starts, since the scope and recurring cost depend on how many apps and environments are involved.
Can a LangSmith integration failure break my Dify app?
A tracing export failure should not stop the app from answering, but it can add latency or leave runs unrecorded, so test it rather than assume it. Run a load test against a staging copy with tracing on and off, and compare response times and error rates. If responses slow down when LangSmith is slow or unreachable, consider this during design and confirm the behavior in your Dify version. Keep tracing settings in staging and production separate so that test traffic does not flood production projects.
Common LangSmith tracing failures and fixes
This table lists common LangSmith tracing failures in self-hosted Dify, with the likely cause and a check you can run. Read each row from the symptom to the fix, starting with the tracing settings in each app before moving to the api and worker container logs. Most failures come from per-app settings, outbound network access or the API key itself.
| Symptom | Likely cause | Check or fix |
|---|---|---|
| No traces appear in LangSmith | Tracing is off for the app, or the settings were not saved | Confirm tracing is enabled on that app, save, then send a new test message and check LangSmith again. |
| No traces, errors in api logs | The api container cannot reach the LangSmith endpoint | Test outbound access from the api container, then review SSRF_PROXY allowlisting, firewall rules and api log entries for connection errors. |
| Traces appear in the wrong project | The project name in the app's tracing settings points elsewhere | Compare each app's project name with the LangSmith project list, correct it and send a new test run. Earlier traces stay where they were. |
| Authentication errors in logs | The API key is missing, revoked, mistyped or from another workspace | Verify the key in LangSmith, paste it without leading or trailing spaces, and confirm it belongs to the workspace that holds the project. |
| Trace shows only the top-level run | Node runs were not exported, often because a run failed before export | Re-run the workflow, compare its node list in Dify run history with the LangSmith run tree, and search worker logs for export errors. |
| Token counts or model fields are empty | The model provider returned no usage data, or the node type does not report it | Compare the same run's usage in the provider's own records. Confirm exported fields against the Dify LangSmith integration page. |
| Background runs missing or late | The worker container is unhealthy or lacks the same outbound access as the api | Check worker container status and logs, then confirm it has the same egress path and key configuration as the api container. |
| Settings change has no effect | Environment changes were not loaded after a container restart | After editing .env, restart the api and worker containers, then send a fresh request. Confirm the new settings in the app before testing. |
| Prompt data reaches LangSmith unexpectedly | Tracing was enabled on an app that handles regulated or sensitive data | Audit which apps have tracing on, disable it where the data owner has not approved it, and record the decision before re-enabling. |
Questions teams ask before connecting Dify to LangSmith
How much effort does connecting Dify to LangSmith involve?
Effort grows with the number of Dify apps you trace, the workspaces and environments behind them, and how much trace detail your team needs to interpret. Tracing is set up in the Dify console, and the Dify docs on LangSmith describe the steps. The sources behind this page do not give a duration, so ask for an effort figure tied to a written list of apps, environments and LangSmith projects. Cost has two parts: the one-time work to configure and verify each app, and the recurring work of keeping keys, upgrades and trace reviews running. LangSmith's own plan charges are separate and set by LangSmith, so confirm them with that vendor.
Can our own team connect Dify to LangSmith without a partner?
Yes, if the people doing the work have administrator access to the Dify console and a LangSmith account that can create a project and an API key. The configuration steps are documented by Dify, so the harder work is design: which apps send traces, which LangSmith project each one uses, who holds the keys, and who reviews the traces. Teams without a named Dify administrator or a clear owner for keys usually find these gaps when they verify traces, so settle the ownership questions before setup begins.
What does a partner engagement for this work include?
Most DeployOpen engagements are fixed-scope, with the scope, deliverables and timeline agreed in writing before work starts. For tracing, a typical written scope covers an inventory of the apps to trace, creating the LangSmith projects and keys the agreed design requires, configuring tracing per app, checking the trace fields against what your team needs, documenting the runbook, and handing it over. Ask the partner to list what is excluded, such as LangSmith plan changes, custom dashboards or evaluation design. Ongoing support and trace review can be covered by a retainer.
Does prompt data leave our network when Dify sends traces to LangSmith?
Yes, for whatever trace content Dify exports. A hosted tracing service receives the run data it is sent, and traces can include prompts, model outputs and node inputs. The sources behind this page do not state where LangSmith stores data, which regions it uses, how long it keeps traces, or whether it offers a self-hosted option. Request those answers in writing from LangSmith before approving use with regulated data. If the answers do not fit your policy, compare self-hosted tracing backends that Dify also lists, including Langfuse, Arize Phoenix and Opik.
What recurring work follows after LangSmith tracing goes live?
Three recurring tasks follow. First, upgrades: Dify minor releases arrive roughly monthly, with 1.16.0 on July 17, 2026, 1.17.0 on August 25, 2026 and 1.17.1 on September 10, 2026 according to the Dify releases page. Follow the upgrade guide for each target version, back up before each upgrade, check .env.example for new variables, and retest tracing afterward. Second, key rotation: rotate LangSmith API keys on your schedule and update each app's tracing settings. Do not treat this as the same task as changing SECRET_KEY, which logs out all users. Third, trace review: someone should confirm that traces still carry the fields you need and that retained data follows your policy.
What makes the scope of a LangSmith tracing project grow?
Scope grows with the number of apps and workflows to trace, the number of workspaces, the number of environments that each need their own keys, and any custom trace metadata you want. Edition matters too: the self-hosted Community edition is free and limited to a single workspace, while the Enterprise edition adds multiple workspaces and is custom priced, according to the Dify pricing page. Work on the LangSmith side, such as dashboards, evaluations or alerting, adds further scope. Each item you add should appear in the written scope with its own acceptance check.
What should a written quote for this work include?
A usable quote lists the work it covers so you can compare it with your own team's effort. Ask for the app inventory with names and counts, the Dify edition and workspaces in scope, the environments covered, the LangSmith projects and who owns each key, and the verification steps with acceptance criteria. Also ask for the assumptions about Dify versions and upgrades, the data handling notes, the explicit exclusions, the handover documentation, and whether any retainer for upgrades and trace review is priced separately with its own term.
What happens to tracing when LangSmith is unreachable?
The sources behind this page do not describe how Dify behaves when the LangSmith endpoint cannot be reached, so confirm it before go-live. Ask Dify and LangSmith whether a workflow still completes and whether traces are dropped or queued. Test this in a non-production environment by blocking outbound access to the endpoint and recording what happens to app responses and traces. Also confirm the outbound path. The environment reference describes the SSRF_PROXY settings as blocking internal and private IP ranges, so a self-hosted tracing backend on an internal host would need explicit confirmation before you choose it.
How DeployOpen scopes and supports tracing integrations
DeployOpen plans and implements the LangSmith tracing setup as a fixed-scope piece of work agreed in writing before anything is configured. DeployOpen is a Chainscore Labs company. It plans, implements, integrates, hardens and documents self-hosted open-source platforms inside the client's own cloud accounts, data centers or air-gapped networks. For this integration, the written scope should name each Dify app that will send traces, the LangSmith project and API key ownership for each one, where the key is stored in your secrets system, how trace content is reviewed against your data handling rules, and how the result will be tested. Ask for the scope to state which of these items are included and which remain with your team, so the quote follows from the actual work.
A scope note should also say who approves sending prompts and outputs to LangSmith, since that is the decision that determines whether this integration fits your environment at all. If your rules do not allow prompt data to leave your network, the written scope is the place to record that the work is a comparison or a move toward a self-hosted tracing backend instead. DeployOpen does not issue audit reports or certifications for this work. Where you need evidence for an assessment, the scope can define what records and configuration exports are produced for your independent auditor to review.
After go-live, Dify changes often enough that tracing needs ongoing attention. Dify 1.17.0 was released on August 25, 2026, and 1.17.1 on September 10, 2026, so minor releases arrive roughly monthly. Each upgrade should be retested to confirm trace fields and the integration still behave as expected. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, which can cover this regression check alongside the rest of your Dify estate. Confirm with DeployOpen what a retainer includes for tracing specifically, and check the vendor's current integration documentation at Dify docs: Integrate with LangSmith before each upgrade window.
