Qdrant Security Review

Qdrant’s own documentation states that self-hosted deployments are not secure by default: open to all network interfaces with no authentication configured, and reachable by everybody on the internet until you configure otherwise.

Why Qdrant security comes down to what is open before you configure it

Qdrant’s own documentation on security and access control is direct about what a self-deployed instance ships with: it is open to all network interfaces and has no authentication configured, and may be reachable by everybody on the internet until you set that up. Qdrant supports three API key types: an Admin API Key with full access to every operation and collection, a Read-Only API Key limited to read operations, and Granular Access API Keys, built on JSON Web Tokens, that scope read or write permission to individual collections. On Qdrant Cloud, granular access API key authentication is enabled by default; on a self-hosted instance it has to be switched on with the jwt_rbac configuration flag alongside an api_key, and a separate value_exists claim can tie a token’s validity to a point still existing in a chosen collection, letting an application revoke a token by changing that point rather than rotating the key.

Network exposure follows a similar pattern. Qdrant’s own guidance states that a custom deployment binds to all network interfaces by default, so an instance can be reachable by everybody on the internet unless it is bound to a specific address, such as 127.0.0.1 for local development or a private interface in production. Encryption in transit works the same way round: connections are unencrypted by default, which the documentation itself warns allows sniffing and man-in-the-middle attacks, so TLS has to be enabled explicitly with the enable_tls setting and a certificate before that risk closes. Where several tenants share one collection, Qdrant’s multitenancy guide recommends partitioning by a payload field such as group_id rather than creating a collection per tenant, with isolation enforced entirely by the filter your application adds to every query.

Qdrant Cloud moves some of these questions into the console instead. Its Cloud RBAC covers identity and access management, cluster and backup administration, Hybrid Cloud environments and billing, and Qdrant’s own documentation notes that current permissions apply across an entire account rather than to a single cluster; Premium customers can add single sign-on and connect a cluster to their own VPC over a private link. For the wider family of NoSQL, cache and streaming platforms this scope splits from, see our NoSQL, cache and streaming security review, and where Qdrant sits inside a retrieval pipeline for a language model, our AI and LLM penetration testing covers what the wider application does with what it retrieves.