Deploy and Host Qdrant on Railway

Qdrant is an open-source vector database written in Rust: store embeddings alongside their payloads, filter on that payload while you search, and get nearest neighbours back in milliseconds. It is the storage layer behind semantic search, RAG pipelines and recommendation systems.

About Hosting Qdrant

This template runs the official qdrant/qdrant image on a pinned stable tag, with collections, the write-ahead log and snapshots on a persistent Railway volume. Nothing is rebuilt or forked, so upstream releases and upstream security fixes are what you get.

Both transports are live from the first deploy. The REST API and the built-in dashboard are served on your public Railway domain, and the gRPC API — the faster one, and the one the official Python, JavaScript, Rust and Go clients prefer — is published through a Railway TCP proxy. The same process also answers on the private network, so other services in your project can reach http://qdrant.railway.internal:6333 without leaving Railway or paying for egress.

An API key is generated at deploy time and required on every request, REST and gRPC alike. This is worth checking before you trust any Qdrant template: a vector database on a public domain with no key set is a database anyone can read, write and drop, and several of the templates in this marketplace ship exactly that.

Common Use Cases

RAG over your own documents: Store embeddings with their source metadata, filter by tenant, document or date at query time, and feed the results to a model.
Semantic and hybrid search: Replace or complement keyword search in your product, with payload filters doing the structured half of the query.
Recommendations and deduplication: Nearest-neighbour lookups over user, item or content embeddings, including recommendation by positive and negative examples.

Dependencies for Qdrant Hosting

Deployment Dependencies

Qdrant 1.19 — the database itself
A Railway volume mounted at /qdrant/storage — collections, WAL and snapshots
An embedding model, wherever you like: an API, or something running elsewhere in your Railway project

Implementation Details

QDRANT__SERVICE__HOST is set to ::, and the exact spelling matters. Railway's private network is IPv6-only while healthchecks and the edge proxy arrive over IPv4; neither actix (REST) nor tonic (gRPC) sets IPV6_V6ONLY, so the wildcard socket stays dual-stack and one bind covers both. Do not write it as [::] — the gRPC listener parses this value as a bare IP address and the bracketed form is not one. The image's own default of 0.0.0.0 would leave qdrant.railway.internal unreachable.

PORT is set to 6333 even though Qdrant never reads it. Railway uses that variable to decide where to send traffic, and the image exposes both 6333 and 6334, so leaving the choice to the platform is a coin flip between the REST API and the binary gRPC port.

The double underscores in variable names are not typos: they are how Qdrant maps environment variables onto its nested configuration, so QDRANT__SERVICE__HTTP_PORT is service.http_port in config.yaml. Any setting in the upstream config file can be overridden the same way.

Snapshots are redirected to /qdrant/storage/snapshots. Qdrant's default is /qdrant/snapshots, which is outside the volume and therefore in the container's ephemeral layer — a snapshot taken as a backup would disappear on the next redeploy, which is the opposite of what a backup is for.

The service carries no healthcheck, deliberately. Railway keeps the previous container serving until a new one reports healthy, while Qdrant holds an exclusive lock on its storage directory — with both on the same volume that is a deadlock, and every redeploy after the first would fail with the stale container still answering. Without a healthcheck Railway stops the old container first, which is also how Railway's own database templates are configured.

QDRANT__TELEMETRY_DISABLED is on. Set it to false if you would rather report anonymous usage upstream.

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 are one step closer to supporting a complete full-stack application with minimal burden. Host your servers, databases, AI agents, and more on Railway.

Resources: 1 GB RAM and the 1 GB volume are a comfortable start and cover a few hundred thousand vectors of typical dimensionality. Qdrant keeps the HNSW index in memory by default, so RAM is what you scale first — plan roughly on vector count times dimensions times four bytes, plus the index, and grow the volume (no downtime) before you run out of disk.