Feature Request: Bidirectional Git Integration for Dify Workflows

[glatham36]

Self Checks

• I have searched for existing issues search for existing issues, including closed ones.
• I confirm that I am using English to submit this report (我已阅读并同意 Language Policy).
• [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:)
• Please do not modify this template :) and fill in all the required fields.

1. Is this request related to a challenge you're experiencing? Tell me about your story.

Feature Request: Bidirectional Git Integration for Dify Workflows

Problem Statement

Dify currently versions workflows (and other app types — chatflow, agent, completion) using its own internal versioning system, stored in its database. This has several limitations:

• No external audit trail. Version history exists only inside Dify; there's no way to review changes through standard code-review tooling (pull requests, diffs, approvals).
• No portability outside the Dify UI. Workflow changes can't be made, reviewed, or scripted through a normal developer workflow (branching, PRs, CI).
• No single source of truth across environments. Promoting a workflow from a dev/staging Dify instance to production currently relies on manual export/import of DSL files, with no automated, trackable sync path.
• No integration with existing engineering practices. Everything else in the stack (application code, infra config) lives in Git; workflows are the one artifact type that doesn't.

Goal: Allow Dify workflow definitions (and their associated static files) to be stored in GitHub or GitLab, with a two-way sync — edits made in the Dify builder UI propagate to a git repo, and edits made directly to files in the repo propagate back into Dify — so that Dify workflows can be versioned, reviewed, and promoted using standard git workflows.

Current State (What Dify Provides Today)

• Workflow DSL export/import via the console API, producing a self-contained YAML document (graph, nodes, prompts, model configs), with workspace-specific IDs stripped on export.
• No native git awareness, no webhook on save that fires outside Dify's own DB, no CLI/service designed for continuous two-way sync.
• A plugin system, but oriented around tool/model providers and endpoints rather than hooking the builder's save path.

This means any git integration has to be built as an external layer on top of the export/import API, rather than as a modification to how Dify persists changes internally.

Proposed Architecture

Overview

A standalone sync service sits between Dify and the git remote (GitHub/GitLab). It does not require forking or patching Dify core. It has two directions of work:

Dify → Git

1. On workflow save (detected via polling the workflow list/version endpoint, or via a Dify webhook/plugin hook if available), export the DSL.
2. Compare the exported DSL's content hash against the last-synced hash for that app.
3. If changed, write the YAML to a deterministic path in the repo (e.g. workflows/<app_id>/<app_name>.yaml), commit with a descriptive message (app name, editor if available, timestamp), and push.
4. Record the new content hash and commit SHA in the sync service's mapping store.

Git → Dify

1. Repo webhook fires on push to the workflows path.
2. Sync service pulls the changed files, diffs against last-known content hash per app.
3. For each changed file, call the import API against the corresponding Dify app, creating a new internal version.
4. Record the new hash/SHA, so the next Dify-side export doesn't re-trigger a redundant push (loop prevention).

Scope: DSL vs. "all files"

Workflow DSL (YAML) is diffable and git-friendly — this is the primary sync target. Other associated assets (knowledge base documents, uploaded files, plugin bundles) are binary/DB-backed and don't diff meaningfully as text. Recommendation: scope those out of true two-way sync initially; at most, track them as a manifest (filename + hash + storage reference) alongside the DSL so a workflow's git history at least notes what non-DSL assets it depends on, without trying to version their binary content in git itself.

Conflict handling

The hard problem isn't export/import — it's deciding who wins when both sides change:

• Loop prevention: content-hash gating on both directions. A sync only fires if the content actually differs from the last-synced state; an import triggered by git shouldn't immediately re-trigger an export back to git.
• Simultaneous edits: rather than attempting a real three-way merge on structured graph data (node IDs and canvas positions make line-level git merges largely unmergeable by a human anyway), use last-write-wins with a visible conflict flag — if both sides changed since the last sync point, don't silently overwrite; surface a notification (and optionally write both versions to the repo under a conflict path) for a human to resolve.
• Mapping store: a small persistent table (app_id ↔ repo path ↔ last-synced content hash ↔ last commit SHA) is required regardless of which direction initiates a sync.

Where the sync service could live

Implemented as a lightweight standalone service (polling or webhook-driven), independent of Dify's codebase, calling Dify's existing console/export/import APIs and the git provider's REST APIs (GitHub/GitLab). This avoids maintaining a fork of Dify and keeps the integration resilient to Dify version upgrades.

Phased Rollout

Phase 1 — One-way export (Dify → Git), manual trigger
Prove out DSL export, path/naming conventions, and commit formatting. No import path yet; git is a read-only mirror. Low risk, immediately useful as an audit trail.

Phase 2 — Automated one-way export
Move from manual trigger to polling or webhook-driven export on every save. Introduce the mapping store and content-hash gating.

Phase 3 — One-way import (Git → Dify), manual trigger
Allow a human to manually apply a git-side YAML change back into Dify via the sync service, without full automation yet. Validates the import path and surfaces DSL edge cases (schema validation failures, node ID mismatches).

Phase 4 — Full two-way automated sync
Webhook-driven import on push, loop prevention via hash gating, conflict detection and flagging.

Phase 5 — Hardening
Conflict resolution UX, promotion workflows (e.g. dev branch → prod branch triggering import into a different Dify instance/workspace), CI validation (lint/schema-check DSL on PR before merge).

Open Questions

• Does Dify expose a save-event webhook or hook point, or does the sync service need to poll for version changes? Polling interval vs. staleness tradeoff needs to be defined.
• Which git provider(s) need to be supported at launch — GitHub only, GitLab only, or both from Phase 1? (Affects webhook payload handling and API client abstraction.)
• What counts as "all files" in scope — is it strictly workflow DSL, or does it need to include knowledge base documents, custom tool provider configs, or plugin bundles? This significantly changes Phase 1 scope if it's more than DSL.
• Promotion across environments — is the end goal single-repo/single-Dify-instance sync, or does this need to support promoting a workflow from a dev Dify instance to a prod Dify instance via git branches/PRs? This affects the mapping store design (single app_id per repo path vs. app_id-per-environment).
• Conflict UX — is a Slack/notification flag sufficient, or does this need a UI for resolving conflicts?
• Auth model — service account credentials for both the Dify API and the git provider; scope of tokens (repo-level vs. broader) needs a decision before Phase 1 ships to anything beyond a test repo.
• DSL schema stability across Dify upgrades — need a process for validating that DSL export/import still round-trips correctly after Dify version bumps, since the sync service depends entirely on that API surface staying compatible.

2. Additional context or comments

No response

3. Can you help us with this feature?

• I am interested in contributing to this feature.