Dify Enterprise Qdrant cluster deployment

Why Dify Enterprise production needs a planned Qdrant cluster

A platform team moving Dify Enterprise from proof of concept to production needs a vector store that keeps serving retrieval when a node fails. The Dify Enterprise resources checklist lists 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. Its production example uses six worker nodes with 8 CPUs and 32 GB of RAM each, plus a three-node Qdrant cluster. Qdrant is therefore not an optional add-on in that reference design; it is one of the stateful services the platform team must size, protect and recover alongside PostgreSQL and object storage.

The checklist's three-node Qdrant example is the reference point to plan from, not a sizing answer for your organization. Your node count, memory, storage and replication settings depend on how many knowledge bases you index, their vector dimensions and how many queries run at peak. Confirm with Dify and your Qdrant support path which Qdrant deployment model fits your environment before go-live, because the choice affects who operates upgrades and recovery. Qdrant's own distributed deployment guidance recommends at least three nodes for production so that quorum survives a node failure, which is the reason the three-node example matters for retrieval availability.

Plan this work before the first production knowledge base is loaded, not after launch. Moving vectors between clusters later means re-indexing or migrating collections while applications depend on them, and changing the replication factor or shard layout after data exists is disruptive. Start the design when you fix the Kubernetes target, the storage class and the backup location, and hand the Qdrant decisions to the same review as PostgreSQL and object storage so that one restore test covers all the stores Dify depends on.

Choosing between managed, Helm chart and enterprise operator paths

Qdrant Cloud is Qdrant's managed service, so Qdrant operates the clusters and you consume them through an account. It is the path with the least infrastructure for your team to own, but it places your vector data in a service you do not run inside your own network. The pricing page lists a free single-node tier with 0.5 vCPU, 1 GB RAM and 4 GB disk, a usage-priced Standard tier with a 99.5% uptime SLA, and a Premium tier with a minimum spend that adds SSO, private VPC links and a 99.9% uptime SLA.

Residency: Your embeddings and payloads sit in the provider's regions, which may conflict with data-residency rules for regulated workloads.
Cost model: Standard pricing is usage-based, so spend grows with data volume and query traffic. Ask for a quote that shows how each factor is metered.
Support boundary: The SLA terms and the support you receive depend on the tier. Confirm the exact uptime commitment in the written contract.
Access controls: Confirm which identity features, such as SSO and private networking, are included in the tier you buy.
Dify fit: Dify connects to Qdrant as a vector store, so confirm the endpoint, TLS and API key handling for a cloud-hosted instance.

Before choosing this path, confirm with your data protection and legal teams whether managed hosting of vector embeddings derived from your documents is permitted.

Cluster options and when each fits

This table compares the main Qdrant cluster decisions for a Dify Enterprise deployment: node count, shard count, replication factor, storage and deployment path. Read each row as a choice that changes storage cost or operating effort, and use the last column to match the option to your constraints.

Decision	Option	Trade-off	When it fits
Node count	Three nodes	Quorum survives one node failure; the minimum the Qdrant docs recommend for production	Default for production Dify Enterprise with a recovery target that tolerates one node loss
Node count	Fewer than three nodes	No node failure can be tolerated without losing quorum; cheaper to run	Non-production or test environments only; confirm the risk with your team
Shard count	Multiple of node count	Shards spread evenly; uneven counts leave some nodes carrying more load	Use three, six or nine shards on a three-node cluster; plan for growth before creating collections
Replication factor	1 (no extra copies)	Lowest storage use; a lost node can take its shard data with it	Only where Dify knowledge data can be rebuilt from source documents within your recovery plan
Replication factor	2 or more	Storage doubles at factor 2; more writes and more disk to monitor	Production data that must survive a node loss without re-indexing
Storage class	Local SSD or NVMe block storage	Higher unit cost; required for acceptable indexing and search speed	Recommended choice; confirm POSIX file system support with your storage vendor
Storage class	NFS or object storage such as S3	Not supported by Qdrant; will not run as a supported configuration	Do not use; the Qdrant installation docs rule it out
Deployment path	Qdrant Cloud	Managed operations; data leaves your infrastructure, and the Premium tier needs a minimum spend	When managed hosting outside your network is acceptable to your data policy
Deployment path	Community Helm chart	No cost for software; lacks zero-downtime upgrades and automatic shard rebalancing	Teams with Kubernetes skills who accept manual upgrades and rebalancing
Deployment path	Enterprise operator via Qdrant Private Cloud or Hybrid Cloud	Adds upgrade and rebalancing features; priced through Qdrant sales, with recurring licensing to confirm	Regulated teams that need vendor-supported operations on infrastructure they control

Sizing the VMs and storage for each Qdrant node

Memory and disk per Qdrant node are driven by four inputs: vector count, vector dimension, payload indexing and replication factor. Each vector you store consumes space in proportion to its dimension, so a collection of many high-dimension embeddings from a Dify knowledge base can require far more memory and disk than a small collection with low-dimension vectors. Payload indexes add structures on top of the vectors, and filtered retrieval in Dify often depends on them. Replication multiplies the footprint: the Qdrant distributed deployment docs state that a replication factor of 2 doubles storage, so each additional copy of a shard adds another full share of data to every node that holds it.

Qdrant also has a hard storage requirement that shapes the VM choice before any sizing math begins. Qdrant needs block-level storage with a POSIX-compatible file system, and it cannot run on network file systems such as NFS or on object storage such as S3. The installation docs recommend SSD or NVMe drives. Confirm with your hypervisor or cloud team that each VM gets local or block-attached SSD or NVMe volumes that meet this rule, and avoid designs where the Qdrant data directory sits on a shared network mount.

No sizing figures are given here, and you should not fix VM specifications from general rules of thumb. Run a load test with your own embeddings, your real dimension, your expected vector count, your payload index plan and your replication factor, then measure memory and disk on a single node before multiplying by the cluster layout. The Dify Enterprise resources checklist sets the Dify worker baseline separately, including its production example of six worker nodes, so it does not size Qdrant and should not be used as a substitute for this test. Ask Qdrant or your implementation partner to review the test plan before you commit to hardware.

Deploying the three-node cluster step by step

This sequence takes a team from version checks to a three-node Qdrant cluster that Dify Enterprise can use. Each step ends with a check, and the final failover test shows whether the cluster keeps serving requests when one node is lost.

Confirm platform versions and prerequisites
Confirm that the target Kubernetes cluster runs version 1.24 or later and that Helm is version 3.14 or later, the minimums in the Dify Enterprise resources checklist. Confirm the PostgreSQL 14 or later, Redis 6 or later and S3-compatible object storage the same checklist requires, and check the Dify Enterprise release you plan to deploy against the Qdrant version you select. Run kubectl version and helm version and record the output in the change record. The step is complete when the platform owner signs off on the versions in writing.
Provision three nodes with block storage
Provision three nodes and place each on a separate failure domain, such as a different host, rack or availability zone, so one hardware or zone failure removes only one node. Attach block storage with a POSIX-compatible file system to each node. Qdrant does not run on NFS or object storage such as S3, and SSD or NVMe drives are recommended. Confirm the storage class and disk type with your infrastructure team before scheduling. The step is complete when each node reports its own volume and the storage is writable from a test pod.
Install Qdrant in distributed mode
Install Qdrant with distributed mode enabled so the nodes form one cluster using the Raft consensus protocol for cluster topology and collection structure. Choose your production path first: Qdrant Cloud, the community Helm chart, or the enterprise Kubernetes operator offered with Qdrant Private Cloud. The community Helm chart lacks features such as zero-downtime upgrades and automatic shard rebalancing, so weigh that before choosing it. Keep the cluster on an isolated network segment until security is configured in a later step, because self-deployed instances listen on all interfaces with no authentication by default. The step is complete when the cluster reports three peers and a single leader.
Create collections with shard and replication settings
Create the collections Dify will use, setting the shard count to a multiple of the node count so that data spreads evenly across the three nodes. Set the replication factor deliberately, because a factor of 2 doubles the storage each collection consumes. Size storage from the replicated figure, not the raw data size. The Qdrant distributed deployment documentation explains these settings in more detail. The step is complete when each collection shows its shards placed across all three nodes and its replica count matches the plan.
Enable TLS and API keys
Turn on TLS for both the REST and gRPC interfaces, then configure an admin API key and a read-only API key. Use the read-only key for retrieval traffic and keep the admin key out of application configuration. Where your policy requires per-collection permissions, confirm that the JWT-based access control in your Qdrant version fits the design. Confirm the audit logging setting for authenticated API operations if your version supports it, and send those logs to your central log store. The step is complete when an unauthenticated request is rejected, a read-only key cannot write, and a TLS connection verifies against your certificate authority.
Connect Dify Enterprise to the cluster
Select Qdrant as the vector store in the Dify Enterprise configuration and point it at the cluster endpoint with the read-write credentials for the Dify service. Confirm the exact setting names in the Dify environment variable reference for your release, because the default vector store is Weaviate. Store the keys in your secrets manager and do not place them in plain values files. Create a test knowledge base, upload a small sample document and run a retrieval query. The step is complete when the knowledge base indexes the document and the query returns the expected chunk.
Run the failover test
Stop one Qdrant node in a planned window and confirm that the cluster still has quorum, which the distributed deployment guidance expects with three nodes. Run a Dify retrieval query and an indexing job while the node is down, and record any errors or latency changes. Then restart the node and confirm that it rejoins the cluster and that replicas resynchronize. Repeat with a different node if your test plan requires it. The step is complete when retrieval succeeds during the outage, the restored node reports healthy, and the results are recorded for the operations runbook.

Securing the Qdrant API before Dify connects

Qdrant ships without authentication and listens on every network interface, so the cluster must be locked down before Dify Enterprise writes its first vector. The cards below cover the access controls Qdrant provides, the network boundary around the cluster, and the logging you need to show who touched the data.

Assume the default is open

Qdrant's security documentation states that self-deployed instances, by default, listen on all network interfaces and have no authentication configured. Treat a freshly installed node as reachable by anything on its network until you have changed both settings. Check the bind address and confirm that a request without a key is rejected before you give the Dify namespace any connection details. Record this check as part of the acceptance test for the cluster.

Admin and read-only API keys

Qdrant supports an admin key and a read-only key, which gives you two credential levels from the start. Dify needs write access to build and update collections for knowledge bases, so the admin key belongs in the Dify secret store, while operators and reporting tools should receive the read-only key. Store both keys outside the Helm values file in plain text, and plan a rotation procedure that updates Dify and every client in one change window.

TLS for REST and gRPC

Qdrant can serve both its REST and gRPC interfaces over TLS, so API keys and vector payloads are not sent in clear text between Dify and the cluster. Decide whether certificates come from your internal certificate authority and how they are renewed, because an expired certificate will stop Dify retrieval at the worst time. Confirm that every client Dify uses to reach the cluster trusts the internal CA and that the inter-node traffic plan is documented alongside it.

JWT permissions per collection

JWT-based access control lets you grant read or write permission on individual collections rather than on the whole cluster. Map each Dify knowledge base collection to a token scope that only the services that own it can use, and keep administrative operations such as collection deletion in a separate, tightly held token. Test the token scopes with a deliberately wrong collection name so you can see the denial in the logs before production traffic arrives.

Segment the network to Dify namespaces

Authentication limits what a caller can do, but network segmentation limits who can reach the port at all. Allow inbound traffic to the Qdrant nodes only from the Dify Enterprise namespace and the administration hosts that need them, and deny everything else at the network policy or firewall layer. Confirm this with a connection test from an unapproved namespace, since a permissive default network policy in Kubernetes will not block traffic on its own.

Audit logging and key separation

Qdrant can write JSON audit logs of authenticated API operations, which gives you a record of which key performed which change. Ship these logs to the same store your organization uses for security events, and set a retention period that matches your policy. Keep this separate from the Dify Enterprise SECRET_KEY, which signs sessions and encrypts OAuth credentials and is changed on a different schedule, since rotating one should never be confused with rotating the other.

Backing up Qdrant collections and proving you can restore them

Replication is not a backup. A three-node Qdrant cluster with a replication factor of 2 keeps extra copies of each shard so the cluster survives a node loss, but a bad delete, a faulty upgrade or a corrupted collection is copied to every replica. The documented backup mechanism is Qdrant snapshots, so the plan for this cluster starts there. Schedule snapshots for every collection that holds Dify knowledge base vectors, keep a retention count you can defend, and store the snapshot files outside the Qdrant cluster, on object storage or a backup target in a separate failure domain. Confirm the snapshot procedure for your Qdrant version in the Qdrant snapshots documentation before you write any automation around it.

Restore testing is what turns snapshots into evidence. On a schedule you set, restore a recent snapshot into a separate test cluster, not the production one, and check the results against known queries: collection point counts, payload fields used for filtering, and a sample of retrieval results from a knowledge base. Record how long the restore took and who ran it. Treat a restore that has never been run as an untested assumption, and budget time for it in your operating plan. Vector collections must stay consistent with the Dify metadata database. Knowledge base documents, segment records and dataset references live in PostgreSQL, while the embeddings live in Qdrant. Back up both at the same point in time, or as close to it as your tooling allows, and record which snapshot pairs with which database dump. If the two drift apart, Dify can hold references to vectors that no longer exist, or vectors that no longer map to any document. Confirm the exact tables and dataset identifiers with your Dify version before relying on this pairing.

Questions teams ask before deploying Qdrant for Dify Enterprise

Is Qdrant free to run for a Dify Enterprise deployment?

The open-source Qdrant engine is free to self-host under the Apache-2.0 license, so the software itself carries no license fee. Your costs come from the infrastructure: virtual machines for three nodes, block storage on SSD or NVMe, backup storage, network capacity, and the people who build and operate the cluster. If you want a managed service or vendor support, Qdrant offers commercial options, including Hybrid Cloud and Private Cloud, which are priced through Qdrant sales. Ask your team which of these you need before comparing quotes, because the commercial tier changes what you pay for and who carries the operational load.

What drives the cost of a self-hosted Qdrant cluster?

The main drivers are the size of your vector collections, the replication factor, and the storage performance you need. A replication factor of 2 doubles stored data, so storage cost rises with every extra copy you keep. Node sizing depends on how much data each node holds in memory and on disk, how many queries run at peak, and how heavy your filtering is. Backup frequency and retention add recurring storage cost. Ask your engineers to size the cluster from your embedding dimensions, expected vector count and query volume, and ask the implementer to show that sizing in the written scope.

How long does a Qdrant cluster deployment take?

Duration depends on scope: whether the work covers only the cluster, or also TLS, access control, backup automation, monitoring and the connection to Dify Enterprise. It also depends on how fast your cloud, network and storage approvals arrive, and on whether a storage class with suitable block performance already exists. No fixed duration applies to every environment, so ask the implementer for a timeline tied to a written scope with named milestones. Treat any schedule that does not list the approvals and environment readiness it assumes as incomplete.

What must our organization provide before the work starts?

The client side usually supplies four things. Cloud accounts or data center access, with permission to create virtual machines, load balancers and backup targets. Network approvals for the connections between Dify Enterprise and the Qdrant nodes, and for any operator access. Storage classes that meet Qdrant's requirements: block-level storage with a POSIX-compatible file system, SSD or NVMe, and no network file systems or object storage for the data path. Named data owners who decide retention, access groups and who may read each collection. Missing any of these is the most common reason a schedule slips.

Can our internal platform team deploy Qdrant alone?

A capable platform team can deploy Qdrant alone if it already runs Kubernetes or virtual machine clusters, understands block storage, and can manage TLS certificates and secrets. The harder parts are usually the security configuration and the operating runbooks. Qdrant does not configure authentication by default, so the team must set API keys, TLS and per-collection access before any data is loaded. Enterprise features such as zero-downtime upgrades and automatic shard rebalancing are not in the community Helm chart, so the team should decide early whether it needs them. An external partner can cover the gaps, but internal ownership of the runbooks should remain.

Which Qdrant security settings should be configured before loading data?

Start by changing the defaults, because self-deployed Qdrant listens on all network interfaces and has no authentication configured. Enable TLS for REST and gRPC, create an admin API key and a read-only API key, and restrict network access to the Dify Enterprise namespace and approved operator hosts. Where you need granular control, Qdrant supports JWT-based access with per-collection read or write permissions. Enable JSON audit logging of authenticated API operations and forward those logs to your central store. Confirm each setting against the security documentation for the Qdrant version you deploy.

What should we ask for in a written quote for this work?

Ask for a quote that lists the scope by component: cluster sizing and the reasoning behind it, storage class requirements, TLS and access configuration, backup design and restore testing, monitoring hooks, and the connection to Dify Enterprise. Each item should name the deliverable, the environment it runs in, and who performs each step. Ask which items are one-time work and which recur, such as upgrades, backup checks and support. Request the assumptions list, the client responsibilities list and the acceptance criteria. DeployOpen's engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.

How do we keep the Qdrant version current with Dify releases?

Dify minor releases arrive roughly monthly, so the Qdrant side needs its own upgrade plan rather than a reaction to each Dify release. Check the Dify upgrade guide for the target version to see whether it expects a particular vector store behavior, and test the combination in a staging environment first. Qdrant publishes its own releases on GitHub, and the community Helm chart does not provide zero-downtime upgrades, so plan a maintenance window or confirm that your chosen path supports rolling upgrades. Take a snapshot or backup before every upgrade and record the versions you tested together.

Limits to confirm in your environment

The Qdrant cluster sits between Dify Enterprise and your storage, so its version, its Kubernetes path and its disks all limit what you can run. Confirm each item below with the vendor and your own infrastructure before sizing or signing a scope.

Qdrant release in use

The latest release cited in our research is v1.19.2, published October 5, 2026, following v1.19.0 on August 5, 2026. Treat that as a starting reference, not a target. Ask Qdrant and Dify which release each side has tested together, and pin the version in your plan. Confirm also whether the security features you need, such as JWT per-collection permissions and JSON audit logging, exist in that release.

Dify Enterprise client compatibility

Dify can point its vector store at Qdrant, but the supported client version and connection settings for your Dify Enterprise release are the part to confirm. Ask your Dify Enterprise contact which Qdrant versions the release is validated against, and whether any configuration keys differ from the Community edition. Do not assume a Community setting carries over unchanged.

Kubernetes and Helm minimums

The Dify Enterprise resources checklist requires Kubernetes 1.24 or later and Helm 3.14 or later, and it names PostgreSQL 14 or later and Redis 6 or later alongside Qdrant. Check these minimums against your cluster distribution, including any managed-service version windows. Confirm that your storage class and node pools can host three Qdrant pods with separate persistent volumes.

Storage performance on your infrastructure

Qdrant needs block-level storage with a POSIX-compatible file system and does not run on NFS or S3-style object storage. Recommended media are SSD or NVMe. Measure random read and write latency and sustained throughput on the disks your platform team will provide, because virtualized or shared storage can differ from the drive class on paper. Ask the storage team who owns replication and snapshot policy for those volumes.

Upgrade and rebalancing support by path

The Qdrant Helm chart is community-supported and lacks enterprise features such as zero-downtime upgrades and automatic shard rebalancing. If your upgrade plan or node-replacement plan depends on either behavior, the enterprise operator under Qdrant Private Cloud or a managed option may be the only fit. Get written confirmation of what each path supports before choosing one.

Security configuration defaults

Self-deployed Qdrant listens on all interfaces with no authentication by default. Confirm that your build sets API keys, TLS for REST and gRPC, and network policies that limit access to the Dify namespace before any data is loaded. Verify these settings in your environment after deployment, since a default cluster is not secure.

How DeployOpen scopes and delivers this cluster

DeployOpen plans and deploys the three-node Qdrant cluster that sits behind Dify Enterprise, inside the cloud accounts, data centers or air-gapped networks you control. Each step starts from a written scope that covers sizing, storage, replication, access control and backup, so your team knows what is built, tested and handed over before work begins.

How we scope

Confirm the Dify Enterprise version, Kubernetes target and the namespace that will host the Qdrant nodes
Agree on the node layout, VM or Kubernetes sizing, and block storage class for each Qdrant node
Define the collection plan, shard count, replication factor and expected storage growth for your knowledge bases
Document which Qdrant deployment path applies, such as the community Helm chart or an enterprise option, and why
Record the written scope, deliverables and timelines in a fixed-scope agreement before any build starts

How we build

Provision three nodes with block storage on a POSIX-compatible file system, avoiding NFS and object storage for data paths
Enable API key authentication, TLS for REST and gRPC, and restrict network listeners so the cluster is not exposed by default
Configure distributed mode with Raft consensus, the agreed shard count and replication factor, and tested node failure behavior
Set up snapshot schedules and an off-cluster copy location, then run a restore test into a separate environment
Connect Dify's vector store settings to the cluster and verify retrieval against a representative knowledge base

How we hand over

Deliver the architecture record, sizing rationale, configuration files and network and access diagrams
Provide a runbook covering node replacement, snapshot restore, key rotation and version upgrade checks
Document the tested recovery steps and the evidence collected, including restore results and access logs
Walk your platform and security teams through alerting, monitoring hooks and the open items left for your owners
Confirm acceptance against the written scope before the engagement closes

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after handover, scoped separately from the build
Plan Qdrant version reviews against the official release notes before any upgrade is scheduled in your environment
Repeat restore tests on a schedule you approve and record the results for your operations and audit files
Review access controls and API keys when Dify, Qdrant or your identity provider changes
Ask us to confirm scope, quote and support terms in writing before committing budget or changing production data