Neu veröffentlicht: E-Commerce mit Power Pages, Stripe & Analytics

· David Göschel · DevOps  · 5 minuten Lesezeit

Qdrant Dashboard sicher öffnen mit lokalem Traefik und SSH Tunnel

Ich wollte die Qdrant Daten im Browser sehen, ohne die Datenbank öffentlich zu machen. Lokal nutze ich Traefik, in Produktion öffne ich nur einen SSH Tunnel und lasse Qdrant intern.

Ich wollte die Qdrant Daten im Browser sehen, ohne die Datenbank öffentlich zu machen. Lokal nutze ich Traefik, in Produktion öffne ich nur einen SSH Tunnel und lasse Qdrant intern.

Inhalt

Qdrant Dashboard per Traefik und SSH Tunnel sicher öffnen

Ich wollte die Daten in Qdrant im Browser sehen, lokal und später auch auf Hetzner. Mir ging es nicht um Komfort um jeden Preis, sondern um eine sichere und trotzdem einfache Möglichkeit, die Collections zu prüfen.

Die zentrale Frage war klar. Wie komme ich an das Qdrant Dashboard, ohne die Datenbank in Produktion zu einer öffentlich erreichbaren Oberfläche zu machen?

Warum ich Qdrant nicht öffentlich mache

Qdrant OSS bringt keine eigene Authentifizierung mit. Genau das ist der Punkt, an dem ich bei einer normalen Web App anders denken muss als bei einer Datenbank mit Login.

Wenn ich Qdrant direkt über Traefik veröffentliche, bleibt die Oberfläche auch dann erreichbar, wenn eine Middleware falsch konfiguriert ist, eine IP Liste sich ändert oder später jemand eine neue Route ergänzt. Für Bull Board und Dozzle ist das noch vertretbar. Für Qdrant ist es mir zu riskant, weil dort die Vektordaten aller Nutzer liegen.

Ich will hier nicht auf eine zusätzliche Schicht vertrauen, wenn ich die Daten auch ganz ohne öffentliche Freigabe prüfen kann.

Der gewählte Weg

Ich nutze zwei unterschiedliche Wege, die aber denselben Zweck erfüllen.

UmgebungZugriffBewertung
Lokalhttp://qdrant.localhost/dashboardSchnell, bequem, ausreichend sicher im eigenen Docker Stack
ProduktionSSH Tunnel auf den internen Qdrant PortAm sichersten, weil Qdrant intern bleibt

Lokal ist Traefik praktisch. Ich habe eine klare URL im Browser und bleibe im gleichen Zugriffsmuster wie bei den anderen Services.

In Produktion öffne ich Qdrant nicht über Traefik. Ich lasse den Dienst auf internal_net und greife nur über einen SSH Tunnel zu. Damit bleibt die Datenbank intern, und die Browser Session ist nur so lange gültig, wie der Tunnel offen ist.

Warum das besser ist

Der Vorteil ist nicht nur Sicherheit. Der Vorteil ist auch Klarheit.

  1. Ich reduziere die Angriffsfläche auf Produktion auf null.
  2. Ich brauche keine zusätzliche Traefik Route, keine IP Allowlist und kein weiteres Passwort.
  3. Ich habe lokal und in Produktion denselben mentalen Ablauf, nur mit einem anderen Transportweg.
  4. Ich kann das Dashboard jederzeit öffnen, ohne Qdrant selbst zu verändern.

Das ist für mich die sauberste Trennung. Lokal darf es bequem sein. Produktion darf nur das Minimum offenlegen.

So nutze ich es praktisch

Lokal öffne ich direkt die Dashboard URL:

http://qdrant.localhost/dashboard

In Produktion starte ich den Tunnel:

ssh -L 6333:qdrant:6333 user@<hetzner-ip>

Danach öffne ich im Browser:

http://localhost:6333/dashboard

Der entscheidende Punkt ist, dass Qdrant dabei weiter intern bleibt. Ich öffne keinen zusätzlichen Port im Internet und ich ändere nichts an der Produktionsarchitektur.

Was ich aus Traefik und SSH Tunnel für Qdrant mitnehme

Ich habe hier bewusst den sichersten Weg gewählt und nicht den bequemsten mit der höchsten Außenwirkung. Für ein Tool wie Qdrant ist das die richtige Entscheidung.

Der Nutzen ist für mich doppelt. Ich kann Daten im Browser prüfen, und ich behalte die Architektur streng genug, dass ich später nicht gegen eine unnötige öffentlich sichtbare Oberfläche ankämpfen muss.

Qdrant Dashboard Zugriff mit lokalem Traefik und SSH Tunnel in Produktion

Das Bild steht für die Entscheidung hinter dem Setup. Lokal darf ich bequem im Browser prüfen, was in Qdrant liegt. In Produktion bleibt die Oberfläche geschlossen und ich öffne sie nur kurz über einen SSH Tunnel.


Alle Artikel der Serie

  1. Vision und Systemübersicht: Chrome Extension, RAG-Architektur, Projekthintergrund: Artikel lesen
  2. RAG-System Aufbau: Qdrant, Embeddings, Cosine-Ähnlichkeit in TypeScript: Artikel lesen
  3. AI Provider Abstraktion: Ollama vs. OpenAI, Interface-Design, kein Vendor-Lock-in: Artikel lesen
  4. Chrome Extension MV3: Drei isolierte Laufzeitkontexte, Message Passing, Strategy Pattern: Artikel lesen
  5. Docker Compose Strategie: Override-Pattern, von lokal zu Azure: Artikel lesen
  6. Ollama lokal vs. Docker: Die Entscheidung und ihre Konsequenzen: Artikel lesen
  7. Ollama Auto-Pull Entrypoint: Automatisiertes Modell-Setup beim Container-Start: Artikel lesen
  8. tsconfig und Vite: Node16 vs. bundler, warum Vite eigene Regeln hat: Artikel lesen
  9. Instagram Caption mit MutationObserver vollständig laden: Artikel lesen
  10. Chrome Extension Foundation mit Health-Dot und Retry-Queue: Artikel lesen
  11. Phase 2 Features: Shadow DOM Overlay, Tailwind v4, Duplicate Detection: Artikel lesen
  12. Race Condition bei der Plattformerkennung: Wie ein UI-Event die Instagram-Erkennung bricht: Artikel lesen
  13. PostId-Extraktion in zwei Instagram-Layouts: querySelector vs. Ancestor-Traversal: Artikel lesen
  14. Instagram Karussell vollständig erfassen mit MutationObserver: Lazy-Loading, Observer-before-click, Timeout-Fallback: Artikel lesen
  15. Notiz und Tags beim Screenshot-Speichern: Artikel lesen
  16. Instagram Tastatur-Shortcuts blockieren Chrome Extension Eingaben: Artikel lesen
  17. Lowercase-Normalisierung und Duplikat-Erkennung im Tag-Input: Artikel lesen
  18. Zitadel Login V2 in Docker Compose: drei versteckte Fehler: Artikel lesen
  19. PKCE OAuth in einer Chrome MV3 Extension: Artikel lesen
  20. React Frontend mit react-oidc-context und Zitadel: Artikel lesen
  21. Vite Build-Time-Umgebungsvariablen in Docker: Artikel lesen
  22. Event-Driven Ingestion mit BullMQ und Redis: Artikel lesen
  23. MinIO statt Azurite: S3-kompatible Objektspeicherung lokal und auf Hetzner: Artikel lesen
  24. access_token, id_token und der Userinfo-Endpoint: was wohin gehört: Artikel lesen
  25. Qdrant Multi-Tenancy: Pro Nutzer eine eigene Collection: Artikel lesen
  26. Wenn Backend und Frontend unterschiedliche Typen kennen: Artikel lesen
  27. Zitadel Bootstrap entfernt: Host-Header-Bug und manuelles Setup: Artikel lesen
  28. Backend Code Review: sechs Probleme vor dem Launch behoben: Artikel lesen
  29. Traefik statt NGINX: Reverse Proxy für einen wachsenden Docker-Compose-Stack: Artikel lesen
  30. Zweischichtiges Rate Limiting: Traefik und express-rate-limit mit Redis: Artikel lesen
  31. DSGVO Art. 17 korrekt implementieren: Promise.allSettled und Export-Batching: Artikel lesen
  32. Embedding-Modell-Lock-in: Warum mxbai-embed-large eine Produktionsentscheidung für immer ist: Artikel lesen
  33. Docker Volumes in Produktion: Named Volumes, Bind Mounts und der Hetzner-Volume-Trick: Artikel lesen
  34. Zwei Sicherheitslücken vor dem Launch: Redis ohne Auth und ein offener Qdrant-Admin-Port: Artikel lesen
  35. Traefik als einziger Einstiegspunkt im Docker Compose Stack: Artikel lesen
  36. Zitadel hinter Traefik richtig verdrahten mit Issuer, JWKS und Login V2: Artikel lesen
  37. Frontend reparieren wenn der nginx Healthcheck an localhost scheitert: Artikel lesen
  38. Observability für meinen Docker Compose Stack mit Bull Board und Dozzle: Artikel lesen
  39. Qdrant Dashboard sicher öffnen mit lokalem Traefik und SSH Tunnel: (dieser Artikel)
  40. Diagnose: Warum mein Chunking trotz Tokenisierung noch scheiterte: Artikel lesen
  41. Entscheidung: Warum ich den Chunk auf 1500 Tokens gesetzt habe: Artikel lesen
  42. Implementierung: Wie ich den Embedding Workflow in mehrere saubere Schritte zerlegt habe: Artikel lesen
  43. Validierung: Wie ich Chunking, Speicherung und Suche wieder zusammenbringe: Artikel lesen

Du willst eine ähnliche Trennung für deine eigene Infrastruktur? Lass uns das gemeinsam einschätzen.

Zurück zum Blog

Ähnliche Beiträge

Alle Beiträge ansehen
Traefik statt NGINX für einen wachsenden Docker-Compose-Stack

Traefik statt NGINX für einen wachsenden Docker-Compose-Stack

Ab acht Services im Docker-Compose-Stack wird nginx.conf zur Wartungslast. Traefik liest Service-Konfiguration direkt aus Docker-Labels, terminiert TLS automatisch über ACME und braucht keine separate Konfigurationsdatei. Warum ich gewechselt habe und wie die Konfiguration aussieht.