Self-host Qdrant with Levelrail

​

Deploy it

levelrail-cli templates deploy qdrant --name my-qdrant

​

Security and requirements

• Publishes ports directly on the host (qdrant): 6333:6333.
• Passwords and keys are generated at deploy time (qdrant): QDRANT__SERVICE__API_KEY.
• Stores data in named volumes (qdrant): qdrant_data.

​

What Levelrail adds

• HTTPS and an ingress filter in front of any domain you attach. See domains and ingress and the firewall.
• Secrets stored encrypted and masked in logs and the UI, including the API key. See environment variables and secrets.
• Volume backups for qdrant_data, the vector storage. See backups and storage.
• Health-gated deploys. The template’s health check must pass before traffic moves. See deploy safety.
• Rollback to the previous image. See deploying apps.

​

What a raw docker compose misses

• The template uses qdrant/qdrant:v1.12.4. Its source notes that this tag could not be checked against a live registry when it was added, so confirm it works before you rely on it.
• 6333:6333 is published on the host, so the REST API is reachable without a domain or filter unless you add one.
• The API key is a $SERVICE_HEX_64_APIKEY placeholder. Plain Docker Compose cannot resolve it, so you would generate and store the key yourself.
• Compose does not back up qdrant_data, so the stored vectors exist on one disk.
• Compose has no rollback to an earlier revision.

​

Next steps

• Backups and storage to schedule qdrant_data backups, then prove your backups work.
• Exposure audit to confirm which ports are reachable from outside.
• Template reference for Qdrant for the full service table.
• All guides.