Dify Enterprise staging and production environments

Confirm the promotable app types and nodes with Dify before you commit to an environment model, because the answer decides whether your apps can move from staging to production at all. Apps that depend on knowledge retrieval, agents or human input may need redesign before promotion. Ask Dify for the current list for your release, and test one representative app from each type you plan to run in staging. Treat any app that fails promotion as a design change, not a configuration fix, and record it in your release plan.

Confirm this for your release, because rollback behavior for app configuration and for data is not the same question. Configuration such as prompts, workflow nodes and model parameters is what an app version carries, so restoring a prior version affects that layer. Knowledge base content, usage logs and conversation data sit outside the app version. Test a rollback in a non-production workspace and check what changed in the database and in the knowledge base before you rely on it as a recovery step.

Plan for them to be recreated or re-entered, because the DSL export does not carry them. According to the Dify app management docs, a YAML DSL export includes app configuration, workflow nodes, model parameters, prompts and knowledge base connections, but not third-party API keys, knowledge base content or usage logs. Each environment therefore needs its own credentials, and the knowledge base must be loaded and indexed in production. Document the manual steps and who performs them in each release.

Ask Dify exactly how the licensed CPU quota is counted and what happens when a workspace or environment reaches it. The quota is set by the license, so the number of environments you run and how they share it are a design decision. Confirm whether staging and production draw from one pool, whether runs queue or fail at the limit, and how usage is reported. Test a load that approaches the limit in staging before a production launch.

Confirm compatibility with the exact Dify Enterprise release you run, because environment features and promotion behavior can change between releases. Dify publishes minor releases roughly monthly on its GitHub releases page, so a staging and production pair can drift if they are upgraded on different schedules. Keep both environments on matching versions, follow the upgrade guide for each target version, and back up before every upgrade, as the Docker Compose docs recommend.

Confirm with Dify whether switching between shared and isolated runtime modes is supported on a live environment, and what it does to running apps. The choice affects isolation between staging and production, so changing it late can undo the separation you designed. Ask whether a switch needs a restart, whether it affects credentials and variables, and how to test it in staging first. If the mode cannot be changed safely in place, plan the choice before the first production promotion.

Confirm how Dify records and restricts changes to environment variables and credentials, and define the approval step yourself, because the platform does not decide your change policy. Ask whether audit records show who changed a value and when, and whether roles can limit production edits to named administrators. Pair this with your secrets management process, so that production values are rotated under the same controls you apply to other systems.

Confirm the license terms in writing before you design more than one production-grade environment, since the Community license is limited to a single workspace and the Enterprise terms define what is included. Ask Dify how environments count against your license, whether non-production environments carry the same entitlements, and what changes if you add workspaces. The license terms determine the design, so confirm them before you finalize the environment model.

Cost depends on the number of environments, the platform you deploy onto and how much of the promotion process you want automated. Enterprise Environments are part of the Dify Enterprise edition, which the Dify pricing page describes as custom priced, so there is no published figure to plan against. Your quote should separate the license, the Kubernetes and infrastructure work, the environment design and the first promotion dry run. Ask the vendor which items recur each year, such as license renewal and support, and which are one-time, such as setup and approval workflow design. Each additional environment adds configuration, credential and testing work.

Duration depends mainly on how many environments you need, whether the prerequisites are already in place and how many approvers must sign off on each promotion. The Dify Enterprise resources checklist lists the platform prerequisites: Kubernetes 1.24 or later, Helm 3.14 or later, PostgreSQL 14 or later, Redis 6 or later, a Qdrant vector database and S3-compatible or cloud object storage. Teams that already run these services can move faster. Teams that need to build them first should expect the infrastructure work to dominate the schedule. Ask for a written timeline tied to the agreed scope before work starts.

You need an active Dify Enterprise license, a Kubernetes cluster that meets the resource checklist, and named people who can approve credential, variable and promotion changes. Plan for an engineer who understands Kubernetes namespaces, Helm releases and secret handling, and an application owner who knows which apps and models each environment must reach. Security or compliance staff should review how production credentials are separated from staging. Confirm with the vendor how the license is bound to your cluster before you start, since activation depends on it.

Yes, if your team has Kubernetes and Helm experience and time to work through the Enterprise documentation. The harder parts are usually decisions rather than commands: whether staging shares runtime resources with production, how CPU quotas are divided, who may promote a version and how a failed release is reversed. A partner is useful when those decisions need to be made quickly and documented for auditors. Whichever path you choose, ask for the environment design and rollback procedure as written deliverables.

Rollback depends on what the promotion changed. An app version promoted from staging can be restored to a previous known-good version if your process keeps that version available and records which version production is running. Configuration that lives outside the app, such as environment variables or credentials, must be rolled back separately, which is why keeping them isolated per environment matters. Before go-live, test a rollback in staging, confirm how long it takes and identify who is authorized to trigger it. Confirm with the vendor which app types can be promoted at all, because some app designs need redesign first.

Shared mode lets environments use common runtime resources, which is simpler to run but means a heavy staging workload can affect production. Isolated mode gives each environment its own runtime, which costs more capacity and operational effort but limits cross-environment impact. The choice depends on your risk tolerance, your cluster capacity and whether production data or regulated workloads must be kept apart. Confirm with the vendor how each mode behaves for your app types and how CPU quotas from the license apply to each environment before you decide.

Yes, you should take a backup before any change that touches production data or configuration. The Dify Docker Compose documentation recommends a backup before every upgrade, and the same discipline applies to promotions. Back up the database, file storage and configuration that production depends on, and test that you can restore it in a non-production environment. Ask your vendor to document which items a promotion changes and which backups cover them.