Qdrant Vector Database AI Platform & Data · Qdrant v1.19.2 Launch on AWS

Configuration¶

This page shows where Qdrant's configuration lives, what the first-boot check enforces, and how to make the common changes: server settings, the API key and access from other machines. Make every change as root, then restart Qdrant.

Where things live¶

Path	What it is
`/etc/qdrant/config.yaml`	Main configuration. Created on first boot and not overwritten afterwards.
`/etc/qdrant/credentials/api.key`	The API key. Root only.
`/etc/qdrant/credentials/qdrant.env`	The key as `QDRANT__SERVICE__API_KEY`, read by systemd when it starts Qdrant.
`/var/lib/qdrant/storage`	Collections and points.
`/var/lib/qdrant/snapshots`	Snapshots.
`/opt/sushi/etc/qdrant/config.yaml.tmpl`	The default configuration, used when `config.yaml` is missing.
`/opt/sushi/bin/qdrant-api`	Helper client that adds the API key for you.

Do not put the API key in config.yaml. Qdrant reads it from the environment file.

The default configuration¶

log_level: INFO

storage:
  storage_path: /var/lib/qdrant/storage
  snapshots_path: /var/lib/qdrant/snapshots
  on_disk_payload: true

service:
  max_request_size_mb: 32
  host: 127.0.0.1
  http_port: 6333
  grpc_port: 6334
  enable_cors: false
  enable_tls: false
  enable_static_content: false
  enable_snapshot_url_recovery: false

cluster:
  enabled: false

telemetry_disabled: true

The file on the instance also holds write-ahead log settings. Telemetry is also turned off on the service command line.

What the first-boot check enforces¶

The first-boot service, sushi-qdrant-firstboot, runs before Qdrant on every boot. It reads config.yaml and stops, so Qdrant does not start, if the file does not contain all of these settings:

host: 127.0.0.1
http_port: 6333 and grpc_port: 6334
enable_tls: false
enable_static_content: false
enable_cors: false
cluster enabled: false

It also stops if the file binds all interfaces (0.0.0.0 or ::). Keep these lines as they are. You can change other settings, such as log_level, max_request_size_mb or the storage options.

Change a setting¶

Edit the file, then restart Qdrant:

sudo nano /etc/qdrant/config.yaml
sudo systemctl restart sushi-qdrant-firstboot qdrant

Restarting the first-boot service runs its check on your edited file. If it reports failed, read the reason with sudo journalctl -u sushi-qdrant-firstboot --no-pager. Collections written to disk survive the restart.

Rotate the API key¶

First boot does not replace an existing key. To rotate, stop Qdrant, remove the key and let the first-boot service create a new one. It also rewrites the environment file from the new key:

sudo systemctl stop qdrant
sudo rm /etc/qdrant/credentials/api.key
sudo systemctl restart sushi-qdrant-firstboot
sudo systemctl start qdrant

Then update the key in your application's secret store. Clients that still use the old key are refused.

Reach Qdrant from other machines¶

By default Qdrant listens on 127.0.0.1 only, with plain HTTP, and the first-boot check keeps it that way. Choose one of these:

Session Manager port forwarding for your workstation, see Connect your application.
Run your application on the same instance.
A TLS reverse proxy on the instance that you install and manage, which forwards to 127.0.0.1:6333. Bind it to the instance's private address, terminate TLS with your own certificate, and in the security group allow its port only from your application's security group.

Keep it private

Do not bind Qdrant to 0.0.0.0, and do not open port 6333 or 6334 to the internet. Keep the API key on.

Things to leave alone¶

Do not remove the API key or the environment file.
Do not turn on the web UI, CORS or cluster mode.
Do not run Qdrant as root or move storage outside /var/lib/qdrant. The service may write only there.

Last updated October 13, 2026 · Suggest an improvement