Dify high availability guide

Why Dify high availability needs more than a bigger server

If Dify already runs your internal AI apps and those apps now need to survive a node, database or vector store failure, the high availability path the vendor documents is Dify Enterprise on Kubernetes with Helm, backed by external services. Dify's own deployment overview positions Kubernetes as the high availability option and the Community edition as a way to run Dify anywhere Docker runs, so a bigger Docker host is not the route to an availability target. The Community Docker Compose stack is a single-host deployment, and the Community edition is limited to one workspace. Compose is a sound way to evaluate Dify and to run a single team's workload, but it places the api, worker, web, plugin daemon, PostgreSQL, Redis, Weaviate, Nginx and the sandbox services on one machine. Losing that host takes every app down at once. Before you set an availability target, confirm with your own architects which of these services you are willing to rebuild from backup and how long that restore has to take.

What makes this harder than it looks is that Dify is several services with different roles, not one application. The api serves requests, the worker runs background jobs such as document indexing, and the plugin daemon and sandbox handle extensions and code execution. Each can be scaled or restarted on its own, but each also depends on shared state. Scaling the web or api tier without addressing that state simply moves the single point of failure somewhere else. The state sits in several places. Application metadata lives in the metadata database, which defaults to PostgreSQL. Caching and task coordination depend on Redis. Knowledge base vectors live in the vector store, which defaults to Weaviate. Uploaded files and documents go to file storage, which can be S3-compatible or another object store. A failure in any one of these affects different features, so your recovery plan must cover each store separately rather than treating Dify as a single database.

One setting deserves early attention. SECRET_KEY signs session cookies and JWTs and encrypts OAuth credentials, and changing it after deployment logs out all users. In a multi-node deployment, every api and worker instance must share the same value, or sessions and encrypted credentials will fail inconsistently across nodes. Make sure the key is generated once, stored in your secrets manager, injected identically into every replica, and included in your backup and restore procedure, because a restored database is unusable if the key that encrypted its credentials is lost.

Teams usually need this when Dify moves from an experiment to a business-critical workflow: a customer-facing assistant, an internal process that depends on a shared knowledge base, or an app that other teams have been told they can rely on. Once you commit to a service level for internal users, the question changes from whether the stack works to how each failure is detected, who responds and how quickly service returns. Start by listing which apps and knowledge bases carry that commitment, because that list determines how many components need redundancy and which ones can wait for a restore.

Which Dify components hold state and which can be replicated

Dify's Docker Compose stack runs its api, worker, web, plugin daemon, sandbox, SSRF proxy, Nginx and data services together, which makes a single host the default failure domain. For high availability, the question for each component is whether it keeps state that must survive a node loss, and if so, where that state lives. The cards separate stateful data stores and keys from the application services that can usually run as multiple instances.

PostgreSQL metadata database

PostgreSQL holds the metadata Dify depends on, including accounts, workspaces, apps, workflow definitions and settings. The Compose stack runs it as a single container, so high availability requires an external database service that every api and worker instance can reach. The Enterprise resources checklist requires PostgreSQL 14 or later. Confirm which metadata database engines your version supports (PostgreSQL, MySQL or OceanBase), how failover is handled, and how point-in-time backups are taken.

Redis for queues and cache

Redis supports background task coordination and caching across Dify services. The Compose stack runs one Redis container, and the Enterprise resources checklist requires Redis 6 or later. If Redis is lost, queued background work can be interrupted, so the failure mode depends on which tasks use it in your version. Ask which Redis topology your version supports, whether it can be clustered or replicated, and what happens to in-flight jobs during a failover.

Vector store for knowledge bases

The vector store holds the embeddings behind knowledge base retrieval. Weaviate is the default in the Compose stack, while the Enterprise resources checklist names Qdrant and shows a three-node Qdrant cluster in its production example. If this store is lost, retrieval fails or returns incomplete results until data is restored or re-indexed. Confirm the backup, snapshot and re-indexing procedure for the store you choose, and how long a rebuild would take on your document volume.

Object storage for uploaded files

File storage holds uploaded documents and other files that Dify keeps outside the database. Dify can use OpenDAL, S3-compatible storage, Azure Blob, Google Cloud Storage and other providers, and the Enterprise resources checklist calls for S3-compatible or cloud object storage. Node-local storage is not shared across api and worker replicas, so replicas need shared object storage. Confirm bucket redundancy, versioning, lifecycle rules and how the bucket is included in backups.

SECRET_KEY and encryption keys

SECRET_KEY signs session cookies and JWTs and encrypts OAuth credentials, and changing it after deployment logs out all users. Workspace encryption keys can be stored locally or in Azure Key Vault. A restore that brings back the database without the matching key material can leave stored credentials unreadable. Keep these values in a secrets manager, include them in your recovery runbook, and confirm the key handling that your version uses before you plan failover.

Stateless application services

The api, worker, web, plugin daemon, code sandbox, SSRF proxy and Nginx are largely stateless, so they are the components usually replicated behind a load balancer or Kubernetes service. Adding instances does not remove the dependence on the data stores above, and a failed instance should be replaceable without data loss. Nginx is the entry point, so its redundancy must be designed in front of it. Confirm each component's replica behavior, and any local state or sticky-session needs, against the version you deploy.

Decisions that set the availability target for Dify

This table compares the platform, database, cache, vector store, file storage and key placement choices that determine how well a Dify deployment survives a failure. Read each row by its option, the situation it fits and the operating work it adds for your team. The main takeaway is that availability depends on every dependency, and adding more Dify pods alone does not address that.

Decision	Option	When it fits	Operational cost
Deployment platform	Community edition on Docker Compose, one host	A single workspace where a host outage and manual recovery are acceptable	The host is a single point of failure. Your team owns restarts, host patching and restore steps.
Deployment platform	Enterprise on Kubernetes with Helm	Multiple workspaces, SSO and high availability across nodes	Requires Kubernetes 1.24 or later and Helm 3.14 or later, plus cluster staff to operate them.
Relational database	Self-run PostgreSQL 14 or later	Teams with mature database operations and tested backup tooling	Your team owns failover, patching, backups and restore testing.
Relational database	Managed PostgreSQL in your cloud account	Teams that want provider-managed failover and backups inside their own account	Recurring provider fees. Confirm failover behavior, version support and data residency with the provider.
Cache	Replicated Redis 6 or later with failover	Deployments where a cache loss must not interrupt users	Needs a failover design and connection settings checked against your Dify version. Confirm what state Dify keeps in Redis.
Vector store	Clustered Qdrant, three nodes as in the Enterprise checklist example	Knowledge bases that must stay queryable through a node loss	Three nodes to run, patch and monitor, with storage and memory scaling by node. Store selection trade-offs are covered in the vector database topic.
Vector store	Weaviate, the Dify default	Lower-footprint deployments that accept its recovery model	Confirm the replication and recovery options for your version before treating it as highly available.
File storage	S3-compatible or cloud object storage	Multi-node deployments where every API and worker pod reads the same files. Local storage fits only a single host.	Recurring storage and request charges. Your team sets versioning, retention and cross-zone replication.
Key placement	SECRET_KEY and workspace encryption keys held in a managed secret store such as Azure Key Vault	Multi-replica deployments that need one consistent key set and separate key custody	Changing SECRET_KEY logs out all users, so plan rotation as a maintenance event. Back up keys separately from the database.

How to build Dify high availability step by step

This sequence takes a team from an agreed Enterprise target to a Dify deployment on Kubernetes where the api, worker, database, cache, vector store and file storage each run without a single point of failure. Each step ends with a check you can record, so the result is verified rather than assumed.

Confirm the target and edition
The platform owner and DeployOpen agree on the Dify version, the Enterprise edition, the cloud account or data center that will host the cluster, and the chart version that matches that release. The Community edition is limited to a single workspace, and the Kubernetes high availability deployment is described for Enterprise, so Enterprise is the starting point for this build. Ask the vendor to confirm the chart version and its upgrade path before any infrastructure is ordered. The step closes when the target, edition and chart version are written into the scope document and signed off by the client owner.
Provision Kubernetes and Helm
Stand up a Kubernetes cluster at version 1.24 or later and install Helm 3.14 or later on the administrator workstation and the deployment runner. Review node pools, storage classes, network policies and admission controls before the chart is applied, because the chart cannot correct a cluster that blocks its own pods. The Enterprise resources checklist uses six worker nodes with 8 CPUs and 32 GB of RAM each in its production example, which is a useful reference for sizing discussions. The step closes when the version commands report compatible versions and a test pod can reach the cluster DNS and the outbound network paths that the external services will need.
Provision PostgreSQL and Redis externally
Provision PostgreSQL 14 or later and Redis 6 or later as managed or self-run services outside the cluster, so that database and cache state do not depend on a single pod. Enable automated backups for PostgreSQL, confirm whether your platform offers point-in-time recovery, and apply TLS, connection limits and separate database users for Dify according to your own standards. Restore a PostgreSQL backup into a scratch instance before go-live. The step closes when the restore test succeeds and both services accept connections from a test pod inside the cluster.
Provision Qdrant and object storage
The Enterprise resources checklist names Qdrant as the vector database and uses a three-node Qdrant cluster in its production example, so deploy Qdrant as a clustered service with replication configured according to its own documentation. Place its storage where a node loss does not destroy the index. Provision S3-compatible or cloud object storage for uploaded files, and limit access to the Dify service identity. Confirm encryption and versioning options with your storage provider. The step closes when test writes and reads succeed against each service and a restart of one Qdrant member does not break retrieval in a test knowledge base.
Generate and distribute SECRET_KEY
Generate SECRET_KEY with a cryptographically secure random generator and store it in your secrets manager. The variable signs session cookies and JWTs and encrypts OAuth credentials, and changing it after deployment logs out all users, so treat it as permanent for the life of the environment. Expose it to every api and worker pod through a Kubernetes secret, then compare a hash of the mounted value across all pods without printing the value. The step closes when every api and worker pod reports the same hash and a session issued by one replica is accepted by another.
Deploy the Enterprise chart with external endpoints
Install the Enterprise chart with values that point to the external PostgreSQL, Redis, Qdrant and object storage endpoints. Confirm whether the chart bundles any in-cluster database or cache, and disable any bundled component that would run as a single instance. Review the rendered manifests before applying them, and check the metadata database, file storage and vector store settings against the environment variable reference for your version. The step closes when all pods reach the ready state, the console loads, and the api logs show successful connections to each external endpoint.
Scale api and worker, then test indexing
Increase api and worker replicas based on the results of your load test, and use pod anti-affinity or topology spread constraints so that workers are distributed across nodes. Upload a test document to a knowledge base and watch its indexing status. While indexing is in progress, delete one worker pod and confirm that another worker picks up the job after rescheduling, with no document left in a failed or stuck state. The step closes when the test document is fully indexed and the indexing status reports completion after the pod deletion.
Configure ingress, TLS and run failover checks
Configure ingress with a TLS certificate issued by your certificate authority, enforce HTTPS, and confirm that the external hostname matches the console and API addresses in the chart. Then run the failover checks from the verification section: drain one worker node, restart one api pod and restart one Qdrant member, testing sign-in, a chat run and knowledge base retrieval after each event. The step closes when each failure causes no user-visible outage beyond an expected reconnect, and the results are recorded in the operations runbook.

How the Dify HA design changes by deployment model

The Compose stack is the Community edition option and runs on one host. It bundles PostgreSQL, Redis, Weaviate, Nginx, a code sandbox and an SSRF proxy alongside the api, worker, web and plugin daemon services. Because every component shares one machine, that host is a single point of failure. A failed disk, a host outage or a damaged volume affects the application and its data together, so recovery depends on backups taken before changes. The Community edition is limited to one workspace, which suits pilots and non-critical use.

Recovers from: container restarts and service-level faults that Docker can resolve on the same host. Host-level failures require rebuilding the machine and restoring from backup.
Client responsibility: host operating system patching, Docker and Compose upgrades, volume backups, TLS setup, and hardware that meets the documented minimum of 2 CPU cores and 4 GB of RAM.
Cannot recover from: loss of the host, its storage or its network path without a restore to new hardware.
Confirm with vendor: whether backup and restore procedures for the bundled PostgreSQL and Weaviate volumes are documented for your target version, and whether your Docker Compose version meets the 2.24.0 minimum.

Before committing, confirm the restore procedure for the bundled database and vector store, and time a rebuild on new hardware in your own environment.

What drives the effort of a Dify high availability project

This table lists the factors that change how much work a highly available Dify build takes and how each one can be kept in check. Read it before asking for a quote, because most rows set the size of the environment, the integration work and the evidence that must be produced. Each driver is a question to answer in the scope document, not a fixed sizing rule.

Driver	Why it moves effort	How to keep it down
Number of environments	Development, test and production each need the full stack, including database, Redis, vector store, object storage and worker tier, so every extra environment repeats most of the build and configuration.	Keep non-production environments smaller but structurally identical, and generate them from the same Helm values with environment-specific overrides.
Data volume in knowledge bases and vector store size	Larger document sets increase ingestion time, index size, backup duration and the capacity planning needed for the clustered vector database.	Agree the document corpus and growth assumptions in writing, and load a representative sample during testing before sizing the production store.
Number of workspaces and SSO scopes	Enterprise multi-workspace management and separate SSO scopes for workspace access and web app access each add identity mapping, role decisions and test cases.	Define the workspace model and which users reach which scope before build starts, and limit the number of identity provider groups mapped to Dify.
Number of model providers and credentials to rotate	Each provider adds a credential, network egress rule and rotation procedure, and credential changes must be coordinated across high availability replicas.	Standardize on a short list of providers, store keys in the secret manager and document one rotation runbook that the client's team can execute.
External integrations that need network paths	Tools, APIs, internal databases and self-hosted models require routes through the SSRF proxy, firewall rules and, for agents, sandbox network isolation.	List every integration endpoint early, classify it as internal or external, and confirm each path with the network team before the build starts.
Compliance evidence requirements	Assessors may ask for configuration baselines, access reviews, backup restore records, change logs and upgrade records, which must be produced from the running system.	Agree the control evidence list in the scope and set up logging, backup reports and change records as part of the build rather than after go-live.
Worker scaling and queue behavior under load	Background tasks such as document processing add load that interactive testing may not show, so queues can grow after launch. The production reference of six worker nodes with 8 CPUs and 32 GB of RAM each is a reference point, not a sizing rule.	Test ingestion of large document batches alongside interactive use, watch queue depth and worker memory, and size workers from those measurements.
Existing Kubernetes, PostgreSQL and Redis	Enterprise on Kubernetes requires Kubernetes 1.24 or later, Helm 3.14 or later, PostgreSQL 14 or later and Redis 6 or later. Missing platforms add cluster, database and cache build work to the project.	Confirm the versions and operating model of each platform in the client environment before scoping, and reuse existing managed services where they meet the requirements.

Securing Dify HA secrets, sessions and service traffic

In a multi-replica Dify deployment, the same secrets, service credentials and network controls must hold across every api, worker and web pod. The cards below cover the values that must match, the outbound and sandbox paths that need controls, and the TLS and credential boundaries around them. The full hardening treatment is in the sibling security hardening topic.

SECRET_KEY across replicas

SECRET_KEY signs session cookies and JWTs and encrypts stored OAuth credentials. Store it in the cluster secret store, make every api and worker replica read the same value, and back it up through an encrypted, access-controlled channel. Changing it after deployment logs out all users, so confirm the rotation plan before go-live.

Workspace encryption key storage

Workspace encryption keys can be held in local storage or in Azure Key Vault. In a high availability setup, local storage must be shared or reproduced identically on every replica, or sessions and stored credentials will fail intermittently. Confirm which option fits your platform and who controls key access and backup.

Token-based service authentication

Dify 1.16.1 introduced token-based API authentication between its services. Confirm that your deployed version includes this change, that the internal tokens are generated per environment and stored as secrets, and that network policies keep internal service endpoints off public routes.

SSRF proxy on every outbound path

The SSRF proxy routes outbound requests and blocks internal and private IP ranges. Every outbound path, including model provider calls, tool requests, plugin traffic and HTTP nodes, must be configured to use it. Test the path from a worker pod, since a single unproxied route bypasses the control.

Agent sandbox network isolation

Dify 1.16.1 added agent sandbox network isolation through a Squid proxy. Confirm that sandboxed code execution can reach only the destinations you approve, and verify the isolation from inside a sandbox run rather than assuming it from the configuration file. Record the proxy allowlist as part of the deployment baseline.

Database and storage least privilege

Give the Dify database user and the S3-compatible storage credentials only the permissions each service needs, and keep them separate from administrative accounts. Store them as cluster secrets, rotate them on a defined schedule, and review which replicas and namespaces can read them. Redis and vector store credentials should follow the same rule.

TLS termination at ingress

Terminate TLS at the Kubernetes ingress with certificates managed in your own PKI or certificate tooling, then check that internal traffic between services and to the database is protected as your policy requires. Confirm HSTS and certificate renewal are handled, and test that plain HTTP redirects correctly. See the sibling security hardening topic for the full treatment.

How to test that Dify fails over without losing work

The test plan is the only evidence that a Dify high availability design holds up, so write it as a runbook the team can repeat after every upgrade. Each test names the component, the action, the expected result and the failure that should trigger escalation. Record the Dify version, the Helm chart version and the relevant .env values for every run, because a minor release can change how components recover. Run the plan in a non-production environment that matches production topology, including separate worker nodes and the three-node Qdrant cluster used in the Enterprise production example, since a single-node setup cannot show what happens when one member is lost. Before you accept any result, confirm the expected behavior of each component against the Enterprise documentation for your version.

Start with the application tier. During an active chat session, stop one api pod and confirm the response either completes or fails in a way the client can retry, with conversation history intact afterward. Then stop one worker pod while a document indexing job is running. The expected result is that another worker retries or resumes the job and the document reaches an indexed state without duplicate segments in the knowledge base. Escalate if an indexing job makes no progress, if segments are duplicated, or if messages from the interrupted chat are missing after recovery. Confirm the retry and resume behavior of the worker in your version's documentation rather than assuming it from the Docker Compose stack, which is not an HA design.

Next, test the data services one at a time. Restart the PostgreSQL primary and confirm that the api and worker pods reconnect without a manual restart, and that writes made after recovery persist. Restart one Redis node and confirm that queued tasks and cached state recover as documented for your Redis topology. Lose one Qdrant cluster node, then run retrieval against a knowledge base that has known content. The expected result is that answers still cite the expected chunks. Escalate if retrieval returns empty results or errors, because replication and shard settings in your Qdrant cluster determine whether data remains served. Confirm those settings with Qdrant's documentation and with the vector store configuration you chose for Dify.

Finish with object storage, secrets and outbound controls. Upload and download files during a replica or provider failover, then read each file back and confirm its contents match. Choose a non-critical secret in the test environment, rotate it and confirm session behavior matches the documentation. Be careful with SECRET_KEY: the environment reference says changing it logs out all users, so rotate it only as a deliberate test with that outcome expected. Last, restart the SSRF proxy and send a request to a private address through a Dify workflow or tool. The expected result is that the request is blocked. Any request that reaches a private range is a failure requiring immediate escalation. Keep the signed results with the upgrade record.

What to monitor, back up and upgrade after go-live

After go-live, high availability depends on routine checks more than on the initial build. The four areas below cover what to watch, what to back up, how to upgrade without losing the failover design, and where the operating knowledge lives. Each one supports the others: an alert means little without an owner, and a backup means little until a restore has been tested.

Monitor the full request path

Track pod health for the api, worker and web deployments, and alert on worker queue depth, because a growing backlog shows up in workflow runs before users report errors. On the data tier, watch PostgreSQL connection counts and replication lag, Redis memory use and failover events, and Qdrant cluster health, including whether every node in the cluster is serving. Also alert on object storage errors, since uploaded documents and file-based workflow steps depend on them. Confirm which metrics your chosen platform exposes before writing alert rules.

Back up data, files and keys

Take PostgreSQL and vector store snapshots on a schedule that matches how often knowledge bases change, and enable object storage versioning or cross-region replication for uploaded files. Keep SECRET_KEY and workspace encryption keys in a separate secure store, apart from the database backups, because a restored database may hold credentials that can no longer be decrypted. Restore the full set into a test environment on a fixed schedule, and record how long the restore takes and what needs manual repair.

Plan each upgrade from its guide

Dify minor releases arrive roughly monthly: 1.16.0 on July 17, 2026, 1.17.0 on August 25, 2026 and 1.17.1 on September 10, 2026. Each release has its own upgrade guide on the GitHub releases page, and you should read it before changing a running cluster. Take a backup before every upgrade, then check .env.example for new variables your deployment needs. Re-run the failover tests after each upgrade. The sibling topic on Dify upgrades and support covers the upgrade process itself.

Maintain a failover runbook

Keep a runbook that lists every endpoint in the deployment, the team that owns each component, the date and result of the last failover test, and the escalation path from on-call engineers to database, cloud and vendor contacts. Record where the backup sets and key store are located and who may access them. Review the runbook after each upgrade and each change to the cluster. Without it, a failover at night depends on whoever remembers the original setup.

Questions teams ask before building Dify high availability

Can the Dify Community edition be made highly available?

Not on a documented path. The Community edition is documented for Docker and is limited to one workspace, while the vendor describes high availability on Kubernetes as part of Dify Enterprise. You may be able to run several Compose stacks behind a load balancer, but the vendor documentation does not describe that design as high availability, and your team would then own the shared state, including sessions, file storage and vector data. Confirm the supported scope of Community deployments with the vendor before you rely on them. For Enterprise on Kubernetes, the vendor's resources checklist names 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. Ask for a component-by-component mapping from the Compose stack to the Enterprise design.

What does a Dify high availability build need from our internal team?

Your team needs operators for Kubernetes, PostgreSQL, Redis and object storage, plus approvals from identity and network owners. The cluster operator manages namespaces, ingress, persistent volumes and Helm releases. A database owner handles PostgreSQL backups, failover, connection limits and upgrades. Someone must run Redis 6 or later, operate the Qdrant cluster and administer the S3-compatible buckets. If you enable SSO, the identity team approves app registrations and redirect URIs for OpenID Connect, SAML or OAuth2 with providers such as Microsoft Entra ID or Okta. The network team approves ingress certificates, egress paths for model providers and the proxy path for outbound requests. Name an on-call owner for each layer before the build starts, because every layer has a failure mode that affects the others.

How long does a Dify high availability project take?

The duration depends on the drivers in your environment, and no fixed figure applies to every organization. The biggest drivers are how mature your Kubernetes platform already is, whether SSO and multiple workspaces are in scope, how many model providers and knowledge bases must be migrated, how much data and configuration moves from an existing install, and how long your change approvals take. Load testing and failover testing add time when the target availability design is strict. The vendor's production example uses six worker nodes with 8 CPUs and 32 GB of RAM each plus a three-node Qdrant cluster, which is a sizing reference rather than a schedule. Ask for a fixed-scope timeline in writing, with milestones, the client actions each milestone depends on and the acceptance tests that close each phase.

What does a highly available Dify deployment cost?

The cost has three separate components, and each is paid to a different party. The Dify Enterprise license is custom priced by the vendor, and the public pricing page does not list it. Infrastructure is owned and paid for by your organization: Kubernetes nodes, managed or self-run PostgreSQL and Redis, the Qdrant cluster, object storage, load balancers, backups and model provider usage. Implementation is quoted by DeployOpen from a written scope, and most engagements are fixed-scope. Infrastructure and license costs recur, while implementation is largely one-time unless you add a support or upgrade retainer. The pricing page lists Dify Cloud plans at 590 US dollars per year for Professional and 1,590 US dollars per year for Team, but those are cloud plans and do not price a self-hosted high availability design. Ask each quote to separate license, infrastructure assumptions, implementation, testing and recurring support.

Can our team build Dify high availability without an implementation partner?

A team can build it alone if it already runs Kubernetes, PostgreSQL, Redis and object storage in production and can obtain Enterprise access from the vendor. The difficult parts are rarely the Helm install itself. They are carrying application state from an existing environment without breaking sessions or credentials, sizing the worker and vector tiers under real query load, proving failover works for each dependency, and writing runbooks that someone outside the build team can follow during an incident. A partner adds a written scope, a fixed delivery plan, test evidence and documentation handover. Decide by comparing your team's available hours against those four areas. Ask your internal owners to estimate the work per area before you compare the outcome with a partner's quote.

What happens to SECRET_KEY during a Dify migration?

Keep the existing value and carry it into the new environment before the first start. The environment reference says SECRET_KEY signs session cookies and JWTs and encrypts OAuth credentials, and changing it after deployment logs out all users. A new key therefore disrupts every active session and may affect stored credentials that were encrypted with the old value. Store the key in a managed secrets store, record who holds custody and restrict access to it. Do not generate a new value during cutover unless the vendor has documented a rotation procedure. Confirm with the vendor whether a rotation changes how stored model provider keys and OAuth settings are decrypted, and how workspace encryption keys, which can be kept locally or in Azure Key Vault, relate to SECRET_KEY. After cutover, test sign-in, SSO if enabled, and a model call that uses a stored credential.

How DeployOpen scopes, builds and hands over Dify high availability

DeployOpen approaches Dify high availability as a fixed-scope engagement inside your own infrastructure, starting from the written scope and the platform components that must survive a failure. We plan, build, test, document and hand over the cluster, then offer ongoing support as a retainer if you want it.

How we scope

Confirm which Dify edition and deployment target apply, including whether Kubernetes and Helm are available in your environment.
Map every stateful dependency (metadata database, Redis, vector store, object storage) and record how each one will be made redundant.
Agree in writing the deliverables, assumptions, environment prerequisites and acceptance tests before any build work starts.

How we build

Deploy the Dify components on Kubernetes with Helm, with external PostgreSQL, Redis and a clustered vector database configured for failover.
Configure S3-compatible object storage and set worker scaling rules sized to the load profile agreed during scoping.
Test failover of nodes, database and vector store, and record the results against the agreed acceptance criteria.

How we hand over

Document the architecture, secret handling for SECRET_KEY, backup and restore steps, and the upgrade procedure for your team.
Run a supervised walkthrough of failover and recovery so your operators have practised each scenario before go-live.
Deliver configuration, runbooks and acceptance evidence in your repositories and systems, so your team owns the running cluster.

How we support

Ongoing support, upgrades and periodic testing are available as a retainer, scoped separately from the build.
Plan each upgrade against the target version's guide, with a backup taken before every change and new environment variables reviewed.
Ask any provider for the support hours, response commitments and exclusions in writing before you sign, since none are published here.