Migrate from Dify Cloud to self-hosted Dify

The number of apps and how complex their workflows are usually matters most. Each app needs its DSL exported, imported, and checked node by node, because exports carry workflow nodes, model parameters, prompts and knowledge base connections but not third-party API keys. A workflow with branches, code nodes, tool calls and sub-workflows takes longer to verify than a single-prompt chat app. Ask the partner to list apps by workflow complexity and to state which apps are in scope for the first cutover.

Knowledge base content is not included in a DSL export, so every knowledge base must be rebuilt from its source documents. The effort depends on how many documents still exist, how many are in formats that need cleanup, and how many datasets reference the same material. Where source files have been lost, the team must recover them from document owners or accept a gap. Ask for a count of datasets, documents and their original locations, and confirm whether re-indexing cost is included in the quote or billed separately.

Third-party API keys are not carried in DSL exports, so each model provider, tool and external connection must be re-entered and tested in the self-hosted console. The work grows with the number of providers, the number of workspaces that hold them, and how many people hold the original keys. Credential rotation also needs a decision: reusing keys that were shared in the cloud account may conflict with your secrets policy. Confirm who can issue new keys and where they will be stored.

Every MCP server, service API key and calling client is a separate change. MCP servers must be recreated on the self-hosted instance, API keys must be issued again because they belong to the deployment, and each client needs its base URL and key updated. The effort rises with the number of products and pipelines that call Dify and with how many teams own them. Build an inventory of callers before the move, and plan a window where old and new endpoints can run side by side.

Yes. The Community edition of self-hosted Dify is free and limited to a single workspace, according to the Dify pricing page. Multiple workspaces, SSO with identity providers such as Microsoft Entra ID, Okta or GitHub, and advanced security are listed for the self-hosted Enterprise edition, which is custom priced. If your Cloud usage spans several workspaces or needs corporate sign-in, the licensing decision and the SSO design become part of the scope, and the Enterprise deployment on Kubernetes adds infrastructure work.

A fully prepared target lowers the effort, and a missing one raises it. The Docker Compose deployment requires at least 2 CPU cores, 4 GB of RAM and Docker Compose 2.24.0 or later, and it runs PostgreSQL, Redis, Weaviate, Nginx and other services. Production use often adds external storage, TLS, backups and monitoring, which the client's own platform team may already provide. Confirm which of these exist, who owns them, and whether the partner will build or only integrate them.

Validation depth sets how much testing is done before cutover: spot checks of a few apps, or full comparison of outputs, retrieval results and API responses for every app. Deeper validation takes more time but reduces the chance of silent quality drops. The migration itself is a one-time cost. Hosting, backups, security patches and the upgrades that Dify releases roughly monthly, according to the GitHub releases page, recur. Ask a quote to separate one-time migration work from ongoing support and to name the acceptance tests.

The cost depends on the scope agreed in writing, not on a standard package. The main components are the infrastructure you run (compute, PostgreSQL, Redis, object storage, a vector store and backups), the staff time spent exporting apps, rebuilding knowledge bases and re-entering credentials, and the engineering effort to cut over API clients. Infrastructure and model provider charges recur, while the migration work is one-time. Ask any quote to separate these lines, to state which apps and knowledge bases are in scope, and to say who holds each credential. Dify's own pricing page lists Cloud Professional at 590 US dollars per year and Team at 1,590 US dollars per year, which is a useful baseline for the subscription you may stop paying after cutover, while the self-hosted Community edition is free and limited to a single workspace.

Duration depends on inventory more than on the platform itself. Count the apps, the workflow complexity, the number of knowledge bases and the total size of their source documents, the number of provider and tool credentials to re-enter, the MCP servers and API keys to recreate, and the number of external API clients that must switch endpoints. Rebuilding knowledge bases from source files usually takes the most time, because re-indexing depends on document volume and the embedding model in use. Before you commit to a timeline, ask for a written inventory of each item and a plan for the parallel run. No duration is given here because none is supplied for this migration.

Three groups of people carry most of the work. Credential holders must supply or re-issue model provider keys, tool credentials and OAuth secrets, because DSL exports do not include third-party API keys. Source document owners must provide the original files for each knowledge base, since Dify knowledge base content is not carried in an app export. API client owners must confirm which products call each Dify app and schedule the switch to new endpoints and new service API keys. Name one person per group before the work starts, and agree who approves each cutover step.

Yes, a capable team can move simple apps by exporting each one as a YAML DSL file and importing it into the self-hosted instance, following the app management documentation. The export covers app configuration, workflow nodes, model parameters, prompts and knowledge base connections. It does not cover third-party API keys, knowledge base content or usage logs, so those steps remain manual. Your team will need to test each imported workflow, reconnect knowledge bases, and verify model behavior. Teams without Docker Compose, PostgreSQL, storage and secrets experience often ask for a partner to handle the platform side, the verification plan and the cutover.

Neither moves automatically. The DSL export excludes knowledge base content and usage logs, so the original documents must be re-uploaded from their source systems and re-indexed in your deployment. Usage logs stay in Dify Cloud, so decide before cutover which logs you need to keep and export them through the platform's own tooling if available. Confirm this with your Dify account contact, because the export behavior is documented for apps rather than for every data type. Plan retention for any logs that contain personal or regulated data before you export them.

Keep the Cloud subscription active until every app, knowledge base and API client has been verified on the self-hosted instance and traffic has moved. Running both environments in parallel means paying for Cloud and for your own infrastructure at the same time, so set an explicit end date tied to the cutover checklist. Cancel or downgrade only after the rollback window has closed. Check your contract for notice periods and data retention after cancellation, and export anything you need before the subscription ends. Confirm these terms with Dify directly, since this page does not set them.

The highest risks are silent changes to app behavior and broken credentials. An imported workflow can run without errors while using a different model or missing a tool connection, so test outputs against known cases. Credentials that were not re-entered will fail only when a path is executed, which can happen weeks later. Knowledge base retrieval quality can also shift if chunking or the index method differs from the original. Build a verification list per app, keep the Cloud environment available for rollback, and keep your SECRET_KEY and backups documented from day one.