mirror of
https://github.com/qdrant/landing_page.git
synced 2026-09-26 14:38:30 +02:00
* 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
9.5 KiB
9.5 KiB
title, short_description, description, slug, breadcrumb, aliases, content, partition, hideInSidebar, build
| title | short_description | description | slug | breadcrumb | aliases | content | partition | hideInSidebar | build | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Deploy Qdrant | Deploy Qdrant your way — managed in Qdrant Cloud, Hybrid Cloud, Private Cloud, or self-hosted with Docker or Kubernetes. | Choose how to deploy Qdrant: Managed Cloud, Hybrid Cloud, Private Cloud, or self-hosted via Docker, Kubernetes, or bare-metal installation. | deploy-intro | false |
|
|
deploy | true |
|
Deploy Qdrant
Self-Hosted
- Installation — Install Qdrant via Docker, Kubernetes, or binary on Linux, macOS, or Windows.
- Distributed Deployment — Multi-node clusters with horizontal sharding and replication for scale and fault tolerance.
- Capacity Planning — Estimate RAM and disk requirements for vectors, payloads, indexes, and replication factors.
- Snapshots — Back up and restore collections for disaster recovery and cross-cluster replication.
- Production Checklist — Pre-launch review of sharding, replication, quantization, load balancing, and observability.
- Upgrades — Upgrade Qdrant clusters across Cloud, Kubernetes, and Docker with zero-downtime planning.
Managed Cloud
- Managed Cloud — Run Qdrant as a managed service on AWS, GCP, or Azure with automatic scaling, backups, and zero-downtime upgrades.
- Create a Cluster — Launch a free or standard cluster on your preferred cloud provider.
- Authentication — Create Database API keys with granular access control and expiration settings.
- Cluster Access — Connect via REST, gRPC, or the Cluster UI with load-balanced endpoints and IP allowlists.
- Configure Clusters — Tune collection defaults, strict mode, replication factor, and optimizer settings.
- Scale Clusters — Scale vertically or horizontally with automatic shard rebalancing.
- Monitor Clusters — Monitor cluster health with built-in metrics, logs, and email alerts.
- Backup Clusters — Schedule snapshots and restore clusters for disaster recovery.
- Update Clusters — Zero-downtime rolling upgrades on multi-node clusters.
- Cloud Inference — Generate embeddings inside Qdrant Cloud or proxy to OpenAI, Cohere, and Jina.
Hybrid Cloud
- Hybrid Cloud — Deploy Qdrant in your own Kubernetes cluster while managing it through Qdrant Cloud.
- Setup Hybrid Cloud — Install and connect the Qdrant Kubernetes Operator to Qdrant Cloud.
- Create a Cluster — Create a Qdrant cluster in your Hybrid Cloud environment.
- Configure, Scale & Upgrade — Tune, resize, and upgrade Hybrid Cloud clusters.
- Networking, Logging & Monitoring — Configure networking, ingress, and observability for Hybrid Cloud.
- Operator Configuration — Advanced configuration of the Qdrant Kubernetes Operator.
- Deployment Platforms — Platform-specific deployment guides for AWS, GCP, Azure, and on-prem Kubernetes.
Private Cloud
- Private Cloud — Fully air-gapped Qdrant deployment in your own Kubernetes cluster with no Qdrant Cloud connectivity.
- Setup Private Cloud — Install and configure Qdrant Private Cloud in a Kubernetes cluster.
- Cluster Management — Create, manage, and operate clusters in Private Cloud.
- Configuration — Advanced configuration options for Private Cloud deployments.
- Backups — Configure backup and restore for Private Cloud clusters.
- Logging & Monitoring — Set up observability for Private Cloud environments.
- API Reference — Private Cloud management API reference.
Operations
- Configuration — Customize Qdrant via config files and environment variables; runtime administration; GPU-accelerated indexing.
- Monitoring & Telemetry — Monitor Qdrant with Prometheus and Grafana via built-in OpenMetrics endpoints.
- Optimization — Tune for high-speed search, high precision, or low memory; understand the background optimizer.
Security & Troubleshooting
- Security — API keys, JWT-based collection-scoped access control, TLS encryption, and network binding.
- Troubleshooting — Diagnose common runtime errors: open-file limits, filesystem incompatibilities, corrupted collection metadata.