* 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
* Break Inference page into several pages
* Make all inference code snippets testable and clean up
* Make more snippets testable
* Edits
* Document automatic query and passage prefix injection in Cloud Inference
Qdrant Cloud Inference silently applies model-specific prefixes (e.g.
"query: "/"passage: " for E5, BGE-style instruction prefix for BGE/mxbai/
Snowflake arctic-embed) so users don't need to manage them manually.
Add a section explaining this behavior, the idempotency guarantee, and
the scope (Qdrant-hosted models only; external providers handle their own).
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
* Document short query optimization in Cloud Inference
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
* Update links
* Expand on external provider API key usage
* Add section about external provider API keys
* Default to header for external API keys
---------
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
* Rewrite security page intro to be feature-forward
Replaces the generic opening paragraph with one that names each security
feature (API key auth, read-only keys, JWT RBAC, network binding, TLS,
audit logging) and links directly to their sections, so scanning readers
see the full capability surface before hitting the warning block.
Also updates the checklist items to surface read-only keys and JWT RBAC
as explicit options under Authentication.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
* Add Security FAQ section to Qdrant Fundamentals
Adds three new Q&A entries covering default security posture, read-only
API keys, and JWT collection-scoped access control — the exact questions
users ask in Discord. Also adds Security to the page nav table and fixes
the heading depth on the collection-per-user entry (## → ###).
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
* Add Security section to production checklist
Inserts a new section 2 covering the five key security steps — API key
auth, read-only keys, JWT access control, TLS, and network binding —
with direct links to the Security page. Renumbers existing sections
2–4 to 3–5. Closes the gap where a user following the checklist
step-by-step could go to production with an open, unauthenticated instance.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
* Link production checklist from both quickstart pages
Adds a production checklist callout to the "Next Steps" section of the
local quickstart and a bullet to the "What's Next?" section of the cloud
quickstart, so users completing either tutorial have a clear path to
production readiness.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
* Make code snippets testable
* Lead Security page by listing all the features; Rename API keys->Admin API keys, and 'Granular Access Control with JWT' section into 'Granular Access API Keys'
* Update links
* Update meta description
* Fix C# snippet
---------
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
Dylan Couzon