메뉴
There are multiple ways to deploy Qdrant, this document navigates through different deployment options and provides guidance on how to choose the right one for your use case.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Search and store knowledge locally using Qdrant Edge. No server needed.
Guides developers through building community Qdrant skills that embed domain knowledge into Claude. Use when someone wants to "create a community qdrant skill", "build an external skill for qdrant", "make a qdrant skill for the community", "build a public qdrant skill", or asks how to "create a skill for qdrant memory issues for developers". Also trigger when someone says "I want to build an open source qdrant skill" or "help me create a qdrant skill for public use". Do NOT use for internal SA skills, general non-Qdrant skill creation, or Python project skills unrelated to Qdrant.
Diagnoses when and why to recommend specific cost optimization techniques for Qdrant customers. Use when a customer or SA says "too expensive", "need to reduce cost", "pricing too high", "how to lower price", "sticker shock", or asks about scaling costs. Also trigger when a deal is blocked by pricing, a customer compares competitor pricing, a startup says the quote is too high, or someone needs a formula to predict costs at scale. This skill answers "when should I recommend scalar vs binary quantization?" not "how to configure quantization." Do NOT use for general Qdrant setup, feature requests, or implementation how-tos.
Handles technical objections that block Qdrant deals and provides proven response playbooks. Use when a deal is stalled due to pricing concerns, missing features, performance issues, or competitive pressure. Triggers on "deal blocked", "customer concerned about cost", "proposal too expensive", "missing feature blocking production", "latency issues on call", "why not use pinecone", "customer built workaround", or "champion lost budget battle". Do NOT use for general product questions, documentation lookups, or technical implementation.
Guides Qdrant SAs through building internal skills that embed domain knowledge into Claude. Use when someone wants to "create a qdrant skill", "build a skill for qdrant diagnostics", "make an internal skill for qdrant customers", "create a qdrant troubleshooting skill", or asks how to "turn SA knowledge into a skill". Also trigger when someone says "help me build a skill for qdrant deal objections" or "I want to create a skill for qdrant cluster sizing". Do NOT use for general skill creation unrelated to Qdrant, external community skills, or Python/JS project skills.
Diagnoses and fixes Qdrant memory problems. Use when a developer reports OOM crashes, high RAM usage, HNSW consuming too much memory, latency spiking after switching storage, or needing to fit more vectors on existing hardware. Also trigger when someone asks which quantization to use, how to choose between mmap and RAM, how to estimate memory for scaling, or why their Qdrant node keeps dying. Do NOT use for initial Qdrant setup, API scripting, embedding model selection, search accuracy tuning, backups, or vector DB comparisons.
| name | qdrant-deployment-options |
| description | There are multiple ways to deploy Qdrant, this document navigates through different deployment options and provides guidance on how to choose the right one for your use case. |
| allowed-tools | ["Read","Grep","Glob"] |
Qdrant deployment types can be categorized into two broad categories: client-server deployments and embedded deployments. Server deployments are suitable for production environments, where accessibility, scalability, and reliability are important. This document focuses on several deployment options for Qdrant, including self-hosted, cloud-based, and embedded deployments, and provides guidance on how to choose the right one for your use case.
Docker-based deployment is the default and most common way to deploy Qdrant. It provides full features of Qdrant Open Source and requires minimal setup.
Minimal command to run Qdrant in Docker is:
docker run -p 6333:6333 qdrant/qdrant
For more details on Docker deployment, see Quick Start -Download and Run
Cloud-based deployment is another version of the client-server deployment, where Qdrant is hosted on a Qdrant Cloud platform. On top of the features of the self-hosted deployment, Qdrant Cloud also provides additional features such as zero-downtime updates, resharding, automatic backups, and more.
For more details on Qdrant Cloud, see Qdrant Cloud
One of the features of Qdrant Python Client is the ability to run Qdrant in local mode. Local mode is a zero-dependency pure Python implementation of Qdrant API, which is tested for congruence with the server version of Qdrant.
Local mode can either be completely in-memory, or can be configured to use disk storage.
from qdrant_client import QdrantClient
client = QdrantClient(":memory:")
# or
client = QdrantClient(path="path/to/db") # Persists changes to disk
Qdrant local mode is suitable for development, testing, CI/CD pipelines. Qdrant local mode is not optimized for performance, and is not recommended for production use cases or benchmarking. Qdrant local mode data format is not compatible with the server version of Qdrant.
Qdrant EDGE is in-process version of Qdrant. It used direct bindings to Qdrant Shard-level function, and can perform same operations as single-node Qdrant deployment, but without the overhead of network communication. Qdrant EDGE uses the same data format as the server version of Qdrant, and can be synchronized with the server by using shard snapshots. This allows you to use Qdrant EDGE for latency-sensitive applications, while still benefiting from the scalability and reliability of a server deployment.
More details on Qdrant EDGE can be found in the Qdrant EDGE docs.