Why self-host Qdrant on a VPS
Qdrant stores and queries embedding vectors to find the most semantically similar items: it is the search building block at the heart of RAG chatbots, recommendation engines and natural-language search. Written in Rust, it is fast and resource-efficient, which makes it ideal to host on a VPS rather than paying for a managed vector service billed per stored vector. Self-hosting is crucial for AI applications handling sensitive data: your embeddings, often derived from confidential internal documents, never leave your infrastructure. You also control latency, which is decisive when every user request triggers a vector search, and you avoid the rate limits of third-party APIs during load spikes.
The concrete benefits of self-hosting Qdrant
- Fast approximate nearest-neighbour (ANN) search thanks to the HNSW index, even across millions of vectors.
- Payload filtering combined with vector search for precise hybrid queries.
- Scalar and binary quantization to sharply reduce the memory occupied by vectors.
- REST and gRPC APIs, plus official Python, JavaScript and Rust SDKs ready to use.
- Privacy: your embeddings derived from internal documents stay on your VPS.
- No billing per vector or per query volume, unlike managed services.
Hardware and software prerequisites
Sizing Qdrant depends on the number of vectors and their dimension. To start with a few hundred thousand vectors, 2 GB of RAM is enough; beyond a million high-dimensional vectors, aim for 4 to 8 GB, because the HNSW index lives in memory to stay fast. Quantization helps reduce this footprint. One to two vCPUs are fine for moderate traffic. Plan for 20 to 50 GB of SSD to persist collections and snapshots. You will need Docker, a domain if you expose the API publicly, and an API key without fail: Qdrant enables no authentication by default, and exposing an open instance would be a major vulnerability.
Deploy Qdrant step by step
Provision the VPS and Docker
Install Docker and configure the firewall to allow only 80 and 443 through. Create a DNS A record for vectors.mydomain.com pointing to the VPS IP if you plan to expose the API over HTTPS.
Launch Qdrant with persistence
Use the qdrant/qdrant image. Mount a volume on /qdrant/storage to persist your collections: volumes: - ./qdrant_storage:/qdrant/storage. Qdrant exposes REST on 6333 and gRPC on 6334.
Enable API key authentication
Set the environment variable QDRANT__SERVICE__API_KEY with a long, random key (openssl rand -hex 32). Without this key, anyone reaching the port could read and delete your collections.
Set up the reverse proxy and TLS
Place Caddy in front of port 6333: vectors.mydomain.com { reverse_proxy localhost:6333 }. Caddy manages the Let's Encrypt certificate. If you use gRPC from your clients, also configure routing for port 6334 with the correct protocol.
Create a collection and insert vectors
Via the API or the Python SDK, create a collection specifying the dimension of your embeddings and the distance (Cosine, Dot or Euclid). Enable scalar quantization at creation time if RAM is limited, then upsert your points with their payload.
Configure snapshots and backup
Trigger regular snapshots via the API (POST /collections/{name}/snapshots) and copy them to external storage. Combined with volume persistence, this guarantees recovery in the event of an incident.
When memory becomes the limiting factor, enable scalar (int8) or binary quantization: it can divide the RAM footprint of vectors by 4 to 32, with slight oversampling (oversampling) at query time to preserve accuracy. Combine it with the on_disk parameter for the original vectors so you keep only the quantized index in memory. This is what makes it possible to serve millions of vectors on a VPS with a few gigabytes of RAM.
