Deploy Qdrant — High-Performance Vector Database

Deploy and Host Qdrant on Railway

Qdrant is the high-performance, open-source vector database — a Rust-built Pinecone and Milvus alternative engineered for speed and scale, handling billions of vectors with advanced payload filtering, quantization, and hybrid search. It's the vector store teams reach for when they need production-grade throughput for RAG, semantic search, recommendations, and agent memory. This template deploys the official Qdrant image with a persistent volume, both API ports exposed, and API-key auth configured — so vectors survive redeploys, your client connects, and the instance isn't left open.

What This Template Deploys

A single Rust binary — no external database, no cluster orchestration — so it runs efficiently and starts fast. A persistent volume at /qdrant/storage holds your collections and vectors, and API-key authentication secures the instance.

About Hosting

Qdrant is a single fast binary, but three specifics decide whether it works in production — all handled here.

Persist the volume, or you lose everything on redeploy. Qdrant writes vector indexes and payload data to /qdrant/storage. By default that lives in the container filesystem and disappears on restart — a disaster in production. This template mounts a persistent volume there, so collections and vectors survive redeploys.

Both ports must be exposed — gRPC is the most common gotcha. Qdrant serves its REST API and dashboard on 6333 and gRPC on 6334. The Python and other SDK clients default to gRPC, so if 6334 isn't exposed you get "connection refused" — the single most common Qdrant setup bug. This template exposes both, so the SDKs connect without the usual debugging.

Set the API key — Qdrant is open by default. Without QDRANT__SERVICE__API_KEY, any process that can reach the instance has full read/write access to your vectors. This template generates a strong key; pass it in the api-key header from your clients and keep it secret.

Built for scale — with the knobs to prove it. Qdrant's edge over simpler vector stores is production performance: payload filtering runs inside the vector query (no separate metadata store), scalar or product quantization cuts memory 4–8× with minimal recall loss, and HNSW parameters tune the speed/accuracy trade-off per collection. It handles billions of vectors on modest hardware.

Drops into LangChain, LlamaIndex, and n8n. Qdrant integrates natively with the major AI frameworks and has an n8n node for automation. Point the host at your Railway domain, pass the API key, and it's your production vector store. Connect other Railway services over the private network on 6333 to keep traffic internal.

Typical cost: ~$5–10/month on Railway for the service plus storage, scaling with your vector volume. Qdrant is Apache-2.0 licensed and free — versus Pinecone's per-read/query billing that compounds as traffic grows.

How It Compares

Pinecone is managed but bills per query and holds your data. Chroma is excellent for quick prototyping and is the framework default, but Qdrant is built for performance at scale. Milvus is powerful but heavy, aimed at large distributed clusters. Qdrant's edge is production-grade speed in a single lightweight binary — billions of vectors, in-query filtering, and quantization — self-hosted at flat cost.

Deploy in Under 5 Minutes

1. Click Deploy on Railway — Qdrant builds with the volume and both ports configured (~2 minutes)
2. Confirm the volume is mounted at /qdrant/storage
3. Copy your key from QDRANT__SERVICE__API_KEY
4. Open [your-domain]/dashboard to browse collections, or hit the REST API on 6333
5. Connect from LangChain, LlamaIndex, or an SDK, passing the API key, and create a collection

Use the private network hostname on 6333 for service-to-service connections from other Railway apps.

Common Use Cases

• Production RAG pipelines — store document embeddings and retrieve relevant chunks with in-query metadata filters
• Vector search at scale — fast similarity search across millions or billions of vectors
• Semantic search — search by meaning across docs, products, or tickets, combined with payload filtering
• AI agent memory — give agents fast, filterable long-term memory backed by a vector store
• Hybrid search — combine keyword filters with vector similarity in one query

Configuration

Persist the volume and expose both ports. Data lives at /qdrant/storage — without the volume, a redeploy wipes it. And 6334 (gRPC) must be exposed or SDK clients get "connection refused," the top Qdrant bug. Both are handled here.

Set the API key — Qdrant is open by default. This template generates QDRANT__SERVICE__API_KEY. Pass it in the api-key header from your clients and keep it secret, since without it the database is fully read/write to anyone who can reach it.

Dependencies for Qdrant Hosting

• Railway account — ~$5–10/month plus storage, scaling with vector volume
• A persistent Railway volume at /qdrant/storage (included)
• An embedding model (OpenAI, a local model, etc.) to generate vectors
• A Qdrant client, LangChain, LlamaIndex, or the n8n node in your application

Deployment Dependencies

• Qdrant GitHub Repository
• Qdrant Documentation
• Qdrant Client SDKs
• Railway Volumes Documentation

Implementation Details

The template runs the official qdrant/qdrant image, a single Rust binary exposing the REST API and dashboard on 6333 and gRPC on 6334, with a persistent volume at /qdrant/storage so collections, indexes, and payload data survive redeploys. Because the SDK clients default to gRPC, exposing 6334 alongside 6333 prevents the "connection refused" error that is the most common Qdrant setup issue.

QDRANT__SERVICE__API_KEY is generated to secure the instance, since Qdrant accepts unauthenticated requests by default and an open endpoint grants full read/write access; clients pass the key in the api-key header. The instance is reachable over automatic HTTPS on the public domain and over the private network on 6333 for service-to-service connections. Qdrant runs payload filtering within the vector query, supports quantization to reduce memory 4–8×, and exposes HNSW tuning per collection, so it scales to billions of vectors on modest hardware. It integrates natively with LangChain, LlamaIndex, Haystack, and n8n. All data persists on the volume, which is the component to back up.

Frequently Asked Questions

Why do I get "connection refused" from the Python client? Because the SDK defaults to gRPC on port 6334, and if only 6333 is exposed the client can't connect — the most common Qdrant setup bug. This template exposes both ports, so the SDKs work out of the box.

Why does Qdrant need a volume? It writes vector indexes and payload data to /qdrant/storage, which is wiped on redeploy without a mounted volume. This template mounts one so your collections persist — losing and re-indexing vectors is expensive.

Is the instance secured? Yes. This template generates QDRANT__SERVICE__API_KEY; pass it in the api-key header from clients. Qdrant is unauthenticated by default, so this matters on any public endpoint.

How is it different from Chroma? Both are self-hosted vector databases. Chroma is the easy, framework-default choice ideal for prototyping; Qdrant is Rust-built for production performance — billions of vectors, in-query filtering, and quantization. Choose Qdrant when you need speed and scale.

Does my data persist? Yes, on the mounted volume — collections, vectors, and payloads survive redeploys. Back it up, since re-indexing large datasets is slow and costly.

How does it save money versus Pinecone? Pinecone bills per read unit and query, which compounds with traffic. Qdrant self-hosted is flat Railway compute regardless of query volume.

Why Deploy Qdrant on Railway?

Railway is a singular platform to deploy your infrastructure stack. Railway will host your infrastructure so you don't have to deal with configuration, while allowing you to vertically and horizontally scale it.

By deploying Qdrant on Railway you get a high-performance vector database with the hard parts solved — the volume persisted so vectors survive redeploys, both REST and gRPC ports exposed so SDKs connect, API-key auth enabled, and automatic HTTPS. Production-grade vector search for RAG and AI, self-hosted on infrastructure you own.