Qdrant zelf hosten in 2026: opslag, API-sleutels en back-ups

Qdrant zelf hosten wordt interessant bij de eerste redeploy, niet bij de eerste docker run. Als opslagrechten mislukken of de client 6334 gebruikt terwijl alleen 6333 wordt gerouteerd, kan Docker nog steeds een volledig gezond proces rapporteren. De onderstaande deployment is ingericht rond observeerbaar gedrag: maak een collection aan met de beoogde vectorgrootte, voeg points met payload toe, voer een gefilterde nearest-neighbor-query uit en herstel een collection-snapshot.

Het doel van Qdrant is duidelijk: een vector database voor embeddings en retrievalsystemen. Die omschrijving maakt duidelijk wat publiek moet blijven, wat privé hoort te blijven en wat een back-up moet kunnen reconstrueren.

Breng Qdrant in kaart voordat je Docker aanraakt

Laat de Qdrant-image niet per ongeluk de productiearchitectuur bepalen. De image levert een proces op 6333; opslag, routing en externe vereisten hebben nog steeds bewust gekozen lifecycles nodig. De vereiste voor de lokale runtime is voldoende RAM en schijfruimte voor vectordimensies, payloads en indexen. Documenteer de verwachte capaciteit, eigenaar en failure mode in plaats van dit als image-default te laten staan.

De deployment is klaar voor diepgaandere tests wanneer deze een collection kan aanmaken met de beoogde vectorgrootte, points met payload kan invoegen, een gefilterde nearest-neighbor-query kan uitvoeren en een collection-snapshot kan herstellen. Volg de transactie in de logs en let op vectordimensies, HNSW-opbouw, payload-indexen, collection-replica's en het verschil tussen memory-mapped data en beschikbare RAM. Deze observaties laten zien of de huidige topologie het juiste component isoleert.

Routeer Qdrant zonder te doen alsof het HTTPS is

Kies de uiteindelijke Qdrant-hostname voordat gebruikers callbacks of clientinstellingen opslaan. Houd REST alleen publiek wanneer clients dit echt nodig hebben en houd gRPC privé. De platformroute moet TLS één keer termineren en doorsturen naar private poort 6333.

Voer de acceptatietransactie extern uit. Als de client Qdrant nooit bereikt, gebruik dan de SSL-validatiechecklist voor DNS- en certificaatcontroles. Als het verzoek Qdrant wel bereikt maar opslagrechten mislukken of de client 6334 gebruikt terwijl alleen 6333 wordt gerouteerd, stop dan met het aanpassen van proxy-redirects en inspecteer de toepassingsspecifieke grens.

Maak van het lokale commando een inspecteerbare service

Gebruik een commando dat elke belangrijke keuze zichtbaar maakt. Deze basisconfiguratie bindt Qdrant aan de loopback van de host, voegt de bekende datamounts toe en levert de eerste vereiste instelling. Controleer de lokale vereiste voordat je de service blootstelt: voldoende RAM en schijfruimte voor vectordimensies, payloads en indexen.

docker run -d \
  --name qdrant \
  --restart unless-stopped \
  -p 127.0.0.1:6333:6333 \
  -v qdrant-data:/qdrant/storage \
  -e QDRANT__SERVICE__API_KEY=replace-with-a-long-random-value \
  qdrant/qdrant:latest

Vervang zwevende tags door een geteste versie of digest. Inspecteer na het opstarten docker logs --tail 200 qdrant en controleer of het proces op 6333 luistert. Voer daarna de Qdrant-acceptatieactie uit; een antwoord van de rootpagina bewijst niet dat het volledige scenario slaagt: maak een collection aan met de beoogde vectorgrootte, voeg points met payload toe, voer een gefilterde nearest-neighbor-query uit en herstel een collection-snapshot.

Upgrade Qdrant zonder te gokken

Capaciteitstests moeten vectordimensies, HNSW-opbouw, payload-indexen, collection-replica's en het verschil tussen memory-mapped data en beschikbare RAM testen, niet een herhaald verzoek naar /. Voer het scenario “maak een collection aan met de beoogde vectorgrootte, voeg points met payload toe, voer een gefilterde nearest-neighbor-query uit en herstel een collection-snapshot” uit met een realistische concurrency en registreer latency, error rate en opslaggroei.

Bij het plannen van upgrades moet je rekening houden met dit risico: collection-snapshots, compatibiliteit van het opslagformaat en gedrag van de client-library moeten worden getest voordat je naar een nieuwe serverversie springt. Test de nieuwe release met representatieve invoer, voer daarna de acceptatietransactie opnieuw uit en vergelijk het resultaat. Als opslagrechten mislukken of de client 6334 gebruikt terwijl alleen 6333 wordt gerouteerd, leg dan de mislukte transactie vast en inspecteer de eerste betrokken grens in plaats van aan te nemen dat ingress verantwoordelijk is.

Maak van de Qdrant-smoketest een releasecheck

Een release candidate voor Qdrant verdient verkeer door een vast scenario succesvol af te ronden: maak een collection aan met de beoogde vectorgrootte, voeg points met payload toe, voer een gefilterde nearest-neighbor-query uit en herstel een collection-snapshot. Leg de image-digest, effectieve niet-geheime configuratie, publieke origin en tijdstippen voor dat scenario vast. De testdata moet wegwerpbaar zijn, maar realistisch genoeg om hetzelfde pad te testen als gebruikers.

Voer de test uit nadat je de runtime hebt vervangen en bouw de service vervolgens opnieuw op vanuit Qdrant-snapshots en de persistente opslagdirectory. Recovery is geslaagd wanneer een snapshot de collection opnieuw aanmaakt met hetzelfde aantal points, dezelfde vectorconfiguratie en representatieve queryresultaten. Vergelijk resource-metingen voor vectordimensies, HNSW-opbouw, payload-indexen, collection-replica's en het verschil tussen memory-mapped data en beschikbare RAM met de vorige release en onderzoek betekenisvolle afwijkingen voordat je promoveert.

Test ten slotte deze gecontroleerde failure: stuur onschadelijke invoer in de buurt van de resource- of formaatl imiet die bij deze grens hoort: opslagrechten mislukken of de client gebruikt 6334 terwijl alleen 6333 wordt gerouteerd. Controleer of Qdrant de failure uitlegt, bestaande state niet beschadigt en hervat zodra de geldige toestand terugkeert. Bewaar een geredigeerd logfragment en de hersteltijd. Samen dekken deze controles gedrag, duurzaamheid en beheerbaarheid af, in plaats van alleen de uptime van het proces.

Bewijs dat Qdrant een vervanging overleeft

Voor Qdrant begint redeploy-veiligheid met Qdrant-snapshots en de persistente opslagdirectory. Mount /qdrant/storage vóór de bootstrap, schrijf onschadelijke voorbeelddata en vervang de container om te bewijzen dat dat pad daadwerkelijk persistent is. Test het pad door de container te vervangen terwijl er onschadelijke voorbeelddata aanwezig is; zo ontdek je mounts die één directory te hoog of te laag zijn gericht.

Test vervolgens disaster recovery op een lege host. Gebruik waar nodig een applicatieconsistente database-export en controleer of een snapshot de collection opnieuw aanmaakt met hetzelfde aantal points, dezelfde vectorconfiguratie en representatieve queryresultaten. De handleiding voor een geteste databaseback-up biedt een sterker doel dan alleen controleren of er een archiefbestand is aangemaakt.

Inloggegevens, rollen en blootgestelde oppervlakken

Voor Qdrant is het waardevolle oppervlak niet per se de landingspagina. De grootste fout is een API zonder authenticatie op internet publiceren. Ga dit bewust tegen: geef ingestion-services beperkte API-toegang en houd de volledige administratieve API op een private route.

Behandel QDRANT__SERVICE__API_KEY volgens de Qdrant-rol ervan: houd gevoelige waarden uit Git, documenteer de gevolgen van rotatie en gebruik in productie nooit een publiek voorbeeld. Gebruik een container-user zonder privileges wanneer de image dit ondersteunt en mount geen niet-gerelateerde inloggegevens. Pas rate- of sizelimieten toe bij ingress wanneer niet-vertrouwd werk vectordimensies, HNSW-opbouw, payload-indexen, collection-replica's en het verschil tussen memory-mapped data en beschikbare RAM kan verbruiken.

Verplaats herhaalbaar infrastructuurwerk naar Dockup

Dockup kan de vervangbare platformonderdelen beheren: verkeer routeren naar poort 6333, het domein en certificaat uitgeven, secrets injecteren, persistente opslag koppelen en Qdrant verbinden met beheerde of privaat gekoppelde services. Dit kan op de infrastructuur van Dockup of op een server die je koppelt.

Het acceptatiewerk voor Qdrant blijft expliciet. Houd REST na de one-click deployment alleen publiek wanneer clients dit echt nodig hebben en houd gRPC privé. Controleer de lokale vereiste — voldoende RAM en schijfruimte voor vectordimensies, payloads en indexen — en voer dit scenario uit: maak een collection aan met de beoogde vectorgrootte, voeg points met payload toe, voer een gefilterde nearest-neighbor-query uit en herstel een collection-snapshot. Die verdeling is bewust: Dockup neemt repetitieve infrastructuurconfiguratie weg zonder te doen alsof toepassingsrollen, providerreferenties of restorebeleid vanzelf worden gekozen.

Veelgestelde vragen

Wat heeft Qdrant nodig voor een productie-deployment?

Routeer de Qdrant-container via één HTTPS-origin op poort 6333. De vereiste voor de lokale runtime is voldoende RAM en schijfruimte voor vectordimensies, payloads en indexen. Verklaar Qdrant pas gereed wanneer je een collection kunt aanmaken met de beoogde vectorgrootte, points met payload kunt invoegen, een gefilterde nearest-neighbor-query kunt uitvoeren en een collection-snapshot kunt herstellen.

Welke Qdrant-data hoort in een back-up?

Maak /qdrant/storage persistent en neem Qdrant-snapshots en de persistente opslagdirectory op in hetzelfde recovery-manifest. Een schone Qdrant-restore is pas geslaagd wanneer een snapshot de collection opnieuw aanmaakt met hetzelfde aantal points, dezelfde vectorconfiguratie en representatieve queryresultaten.

Heeft Qdrant HTTPS nodig achter een reverse proxy?

Gebruik HTTPS voor de publieke Qdrant-origin en houd poort 6333 op de interne route. Pas de Qdrant-instelling correct toe: houd REST alleen publiek wanneer clients dit echt nodig hebben en houd gRPC privé. Voor Qdrant beschermt HTTPS inloggegevens of gebruikerscontent tijdens transport en zorgt het voor consistent gedrag van clients die afhankelijk zijn van de origin.

Hoe test je een Qdrant-upgrade?

Herstel de huidige Qdrant-state in een geïsoleerde deployment, pas de kandidaatversie toe en voer de acceptatietransactie opnieuw uit. Let hier vooral op, omdat collection-snapshots, compatibiliteit van het opslagformaat en gedrag van de client-library moeten worden getest voordat je naar een nieuwe serverversie springt. Houd de vorige Qdrant-image beschikbaar totdat de grenzen voor datamigratie en rollback duidelijk zijn.