Files
Abdon Pijpelink 45f19f30ee Break up "Distributed Deployment" page into new "Scaling & Resilience" section (#2491)
* Add new Scaling landing page under Operations

Introduces a Scaling section with vertical vs. horizontal scaling
guidance and failover best practices, linking out to detail pages.

* Add new Vertical Scaling page

Dedicated how-to guidance for resizing existing nodes: when to scale
vertically, RAM sizing formulas, and Cloud/self-hosted resize steps.

* Add new Horizontal Scaling and Resilience page

Covers Raft consensus, the replication model, consistency guarantees,
Multi-AZ, and the resilience terminology used elsewhere in the docs.

* Move Distributed Deployment under Scaling and update all incoming links

Moves distributed_deployment.md into the new scaling/ section, trims
its Raft/Replication/Consistency intros into cross-links to the new
Horizontal Scaling and Resilience page, adds Multi-AZ and single-replica
cross-link callouts in the Cloud docs, rewrites all internal references
across ~30 files to the new canonical path instead of relying on
aliases, and applies Title Case to Distributed Deployment's headers.

* Split Resilience out of Horizontal Scaling and Resilience

Adds a dedicated Resilience page covering fault tolerance, Multi-AZ,
resilience terminology, and failover best practices (moved from the
Scaling landing page). Horizontal Scaling is retitled and scoped to
the underlying mechanics: Raft consensus, replication, and consistency.

* Reorganize Horizontal Scaling's structure

Moves "How Many Qdrant Nodes Should I Run?" from Distributed Deployment
into Horizontal Scaling, adds a conceptual Sharding section, and
reorders Sharding/Replication/Raft Consensus/Consistency. Moves the
remaining conceptual content out of Distributed Deployment: Temporary
Node Failure to Resilience, Error Handling folded into Replication,
sharding heuristics folded into Sharding, and the Consensus
Checkpointing explanation folded into Raft Consensus.

* Rename Scaling section to Scaling & Resilience

Renames the section and restructures the landing page: the vertical-
vs-horizontal decision is now purely about scaling, with a dedicated
Resilience section covering fault tolerance through sharding and
multi-node deployments.

* Polish Vertical Scaling and Resilience page content

Reframes Vertical Scaling's "What Not to Do" as positive "Best
Practices". Reworks Resilience's structure: moves the uptime/data-
integrity terminology into the intro as three distinct aspects of
resilience, and renames "How Resilience Works" to "Setting Up a
Resilient Qdrant Cluster".

* Add diagrams illustrating sharding and replication

Adds cluster diagrams to the Sharding and Replication sections on
Horizontal Scaling to make the shard/replica layout easier to follow.

* Add new Node Failure Recovery page

Extracts the node failure recovery scenarios out of Distributed
Deployment into their own page, with each bolded sub-header converted
to a proper heading, and links updated across Resilience and the
Scaling landing page.

* Add new Consistency Guarantees page

Extracts write consistency factor, read consistency, and write
ordering out of Distributed Deployment into their own page, positioned
after Distributed Deployment.

* Add new "Deploy Behind a Load Balancer" section

Explains why a load balancer is needed in front of a multi-node
Qdrant cluster: avoiding a single point of failure at the entry point
and making sure replicas on every node actually serve reads.

* Add new "Rebalancing" section

Documents how Qdrant Cloud automatically rebalances shards across
nodes, as its own subsection under Sharding.

* Rewrite Multi-AZ vs. Replication Factor as Multi-AZ Deployments

Defines an availability zone on first use, explains why multi-AZ
deployments guard against a zone going down, clarifies that Qdrant
Cloud is zone-aware once enabled, and that self-hosted deployments
need to place and move replicas across zones manually.

* Restructure node-count guidance into One/Two/Three-or-more Node subsections

Splits "How Many Qdrant Nodes Should I Run?" into three subsections
and drops the "balanced" framing for two nodes: it states plainly
that two nodes give more capacity without true high availability.

* Add new "Which Configuration Is Right for You?" section

Summarizes the one/two/three-or-more node tradeoffs in one place
right after the detailed breakdown.

* Add explicit _redirects entry for legacy distributed_deployment URL

Closes the redirect chain: the existing /guides/ and /operations/
legacy rules both terminate at /documentation/distributed_deployment/,
which previously had no explicit _redirects entry and only resolved
via the Hugo alias meta-refresh page.

* Fix all incoming links to Distributed Deployment and pages under Scaling

Repoints two same-page anchors in distributed_deployment.md that broke
when Write Ordering moved to Consistency Guarantees, and one link in
cloud/create-cluster.md that broke when a Resilience heading was
reworded.

* Update time-based sharding diagram and restructure section

* Fix a couple of broken links

* Move 'Consensus Checkpointing' to 'Node Failure Recovery' page
2026-07-16 09:11:58 +02:00

11 KiB

title, short_description, description, partition, weight, aliases
title short_description description partition weight aliases
Installation Install Qdrant on Linux, macOS, or Windows using Docker, Kubernetes, or a binary, with hardware and storage guidance. Install Qdrant via Docker, Kubernetes, or binary releases — review CPU, memory, storage, and networking requirements for self-hosted deployments. deploy 110
/documentation/install
/documentation/installation
/documentation/operations/installation

Installation requirements

The following sections describe the requirements for deploying Qdrant.

CPU and memory

The preferred size of your CPU and RAM depends on:

  • Number of vectors
  • Vector dimensions
  • Payloads and their indexes
  • Storage
  • Replication
  • How you configure quantization

Our Cloud Pricing Calculator can help you estimate required resources without payload or index data.

Supported CPU architectures:

64-bit system:

  • x86_64/amd64
  • AArch64/arm64

32-bit system:

  • Not supported

Storage

For persistent storage, Qdrant requires block-level access to storage devices with a POSIX-compatible file system. Network systems such as iSCSI that provide block-level access are also acceptable. Qdrant won't work with Network file systems such as NFS, or Object storage systems such as S3.

If you offload vectors to a local disk, we recommend you use a solid-state (SSD or NVMe) drive.

Networking

Each Qdrant instance requires three open ports:

All Qdrant instances in a cluster must be able to:

  • Communicate with each other over these ports
  • Allow incoming connections to ports 6333 and 6334 from clients that use Qdrant.

Security

The default configuration of Qdrant might not be secure enough for every situation. Please see our security documentation for more information.

Installation options

Qdrant can be installed in different ways depending on your needs:

For production, you can use our Qdrant Cloud to run Qdrant either fully managed in our infrastructure or with Hybrid Cloud in yours.

If you want to run Qdrant in your own infrastructure, without any cloud connection, we recommend to install Qdrant in a Kubernetes cluster with our Qdrant Private Cloud Enterprise Operator.

For testing or development setups, you can run the Qdrant container or as a binary executable. We also provide a Helm chart for an easy installation in Kubernetes.

Production

Qdrant Cloud

You can set up production with the Qdrant Cloud, which provides fully managed Qdrant databases. It provides horizontal and vertical scaling, one click installation and upgrades, monitoring, logging, as well as backup and disaster recovery. For more information, see the Qdrant Cloud documentation.

Qdrant Kubernetes Operator

We provide a Qdrant Enterprise Operator for Kubernetes installations as part of our Qdrant Private Cloud offering. For more information, use this form to contact us.

Kubernetes

You can use a ready-made Helm Chart to run Qdrant in your Kubernetes cluster. While it is possible to deploy Qdrant in a distributed setup with the Helm chart, it does not come with the same level of features for zero-downtime upgrades, up and down-scaling, monitoring, logging, and backup and disaster recovery as the Qdrant Cloud offering or the Qdrant Private Cloud Enterprise Operator. Instead you must manage and set this up yourself. Support for the Helm chart is limited to community support.

The following table gives you an overview about the feature differences between the Qdrant Cloud and the Helm chart:

Feature Qdrant Helm Chart Qdrant Cloud
Open-source ✅
Community support only ✅
Quick to get started ✅ ✅
Vertical and horizontal scaling ✅ ✅
API keys with granular access control ✅ ✅
Qdrant version upgrades ✅ ✅
Support for transit and storage encryption ✅ ✅
Zero-downtime upgrades with optimized restart strategy ✅
Production ready out-of the box ✅
Dataloss prevention on downscaling ✅
Full cluster backup and disaster recovery ✅
Automatic shard rebalancing ✅
Re-sharding support ✅
Automatic persistent volume scaling ✅
Advanced telemetry ✅
One-click API key revoking ✅
Recreating nodes with new volumes in existing cluster ✅
Enterprise support ✅

To install the helm chart:

helm repo add qdrant https://qdrant.to/helm
helm install qdrant qdrant/qdrant

For more information, see the qdrant-helm README.

Docker and Docker Compose

Usually, we recommend to run Qdrant in Kubernetes, or use the Qdrant Cloud for production setups. This makes setting up highly available and scalable Qdrant clusters with backups and disaster recovery a lot easier.

However, you can also use Docker and Docker Compose to run Qdrant in production, by following the setup instructions in the Docker and Docker Compose Development sections. In addition, you have to make sure:

Development

For development and testing, we recommend that you set up Qdrant in Docker. We also have different client libraries.

Docker

The easiest way to start using Qdrant for testing or development is to run the Qdrant container image. The latest versions are always available on DockerHub.

Make sure that Docker, Podman or the container runtime of your choice is installed and running. The following instructions use Docker.

Pull the image:

docker pull qdrant/qdrant

In the following command, revise $(pwd)/path/to/data for your Docker configuration. Then use the updated command to run the container:

docker run -p 6333:6333 \
    -v $(pwd)/path/to/data:/qdrant/storage \
    qdrant/qdrant

With this command, you start a Qdrant instance with the default configuration. It stores all data in the ./path/to/data directory.

By default, Qdrant uses port 6333, so at localhost:6333 you should see the welcome message.

To change the Qdrant configuration, you can overwrite the production configuration:

docker run -p 6333:6333 \
    -v $(pwd)/path/to/data:/qdrant/storage \
    -v $(pwd)/path/to/custom_config.yaml:/qdrant/config/production.yaml \
    qdrant/qdrant

Alternatively, you can use your own custom_config.yaml configuration file:

docker run -p 6333:6333 \
    -v $(pwd)/path/to/data:/qdrant/storage \
    -v $(pwd)/path/to/custom_config.yaml:/qdrant/config/custom_config.yaml \
    qdrant/qdrant \
    ./qdrant --config-path config/custom_config.yaml

For more information, see the Configuration documentation.

Docker Compose

You can also use Docker Compose to run Qdrant.

Here is an example customized compose file for a single node Qdrant cluster:

services:
  qdrant:
    image: qdrant/qdrant:latest
    restart: always
    container_name: qdrant
    ports:
      - 6333:6333
      - 6334:6334
    expose:
      - 6333
      - 6334
      - 6335
    configs:
      - source: qdrant_config
        target: /qdrant/config/production.yaml
    volumes:
      - ./qdrant_data:/qdrant/storage

configs:
  qdrant_config:
    content: |
      log_level: INFO

From source

Qdrant is written in Rust and can be compiled into a binary executable. This installation method can be helpful if you want to compile Qdrant for a specific processor architecture or if you do not want to use Docker.

Before compiling, make sure that the necessary libraries and the rust toolchain are installed. The current list of required libraries can be found in the Dockerfile.

Build Qdrant with Cargo:

cargo build --release --bin qdrant

After a successful build, you can find the binary in the following subdirectory ./target/release/qdrant.

Client libraries

In addition to the service, Qdrant provides a variety of client libraries for different programming languages. For a full list, see our Client libraries documentation.