Selbst gehostete BI: die ganze Engine im eigenen Netz

Manche Daten dürfen ein Netz nicht verlassen. Manchmal ist es Regulierung, manchmal ein Vertrag mit einem Kunden, der selbst reguliert ist, und manchmal ein Sicherheitsteam, das es einfach entschieden hat und Ihnen keine Begründung schuldet. In allen drei Fällen ist ein gehostetes Analyseprodukt keine günstigere Option — es ist keine Option.

vibedasher läuft genau für diesen Fall auf Ihrer eigenen Infrastruktur.

Was Sie deployen

Die ganze Engine, keinen dünnen Client: ETL und Ingestion, die Datensatzschicht, die Abfrage-API, das Dashboard-Hosting, den Planer, das Alerting. Zwei unterstützte Formen:

• docker compose — ein einzelner Host. Die Form für eine Evaluierung oder ein kleines internes Deployment. Der Installer holt Basis-Images aus öffentlichen Registries und braucht daher Netzzugang; eine vom Netz getrennte Distribution gibt es heute nicht.
• Ein Helm-Chart — Kubernetes. Die Form für alles, was den Ausfall eines Knotens überleben muss.

Es ist dieselbe Engine wie in der Managed Cloud. Keine funktionsreduzierte Community-Edition und kein Fork, der auseinanderläuft: der selbst gehostete und der gehostete Build sind derselbe Code, und das ist die einzige Anordnung, unter der „selbst gehostet" auch ein Jahr später noch etwas bedeutet.

Was drinnen bleibt

Abfragen gehen nicht hinaus. Die Engine verbindet sich aus Ihrem Netz mit Ihren Datenquellen und liefert das Dashboard von dort; nichts macht einen Umweg über uns, um eine Zahl zu erzeugen.

Das Einzige, was hinausgehen kann, ist die Modell-Inferenz, und auf diesem Weg entscheiden Sie. Zeigen Sie den Agenten auf einen eigenen LLM-Endpunkt, und es geht nichts hinaus — keine Daten, keine Prompts, kein Schema. Deshalb ist „eigenes Modell" ein Self-Hosting-Merkmal und kein Managed-Merkmal: in Ihrem Netz ist es der Unterschied zwischen einem geschlossenen und einem fast geschlossenen System.

Der ehrliche Stand

Auf dem Self-Hosting-Weg gibt es noch keinen Produktionskunden. Er ist dokumentiert, er ist in beiden Formen getestet, und niemand betreibt damit sein Geschäft.

Das steht hier, im gleichen Textkörper wie alles andere, weil es das Nützlichste ist, was jemand, der selbst gehostete BI bewertet, über uns wissen kann — und weil es die am leichtesten zu fälschende Behauptung dieser Seite ist und die am schnellsten widerlegte. Wenn Sie es deployen, sind Sie der Erste, und die richtige Lesart ist: in Ihrer Umgebung wird es Kanten geben, auf die noch niemand gestoßen ist, und Sie sollten eine direkte Leitung zu der Person wollen, die es geschrieben hat, bevor Sie sich binden. Diese Leitung existiert — Kontakt — und es ist ein Mensch, keine Warteschlange.

Die Managed-Alternative, wenn der Grund die Jurisdiktion ist

Viele kommen auf der Suche nach Self-Hosting, während sie eigentlich „nicht in den USA" brauchen. Wenn das die Einschränkung ist, lesen Sie die ganze Antwort, bevor Sie entscheiden. Dashboards, Datensätze und Abfrageergebnisse werden in der Europäischen Union, in Frankfurt, verarbeitet und gespeichert, und wir betreiben das — Sie übernehmen also nicht Upgrades, Backups und Kapazitätsplanung. Die Anmelde-Identität aber — E-Mail-Adresse und Kontozugehörigkeit — liegt in den Vereinigten Staaten, für jedes Konto, wo auch immer Sie sind. Diese Teilung können Sie nicht wählen, und es gibt keinen Regionsschalter. Wenn die Anforderung also lautet, dass nichts von Ihnen die Vereinigten Staaten berührt, erfüllt die Managed Cloud sie nicht, und der selbst gehostete Build ist der, der beides in Ihrem Netz hält.

Es lohnt sich, die zwei Fragen vor der Wahl zu trennen, denn sie haben unterschiedliche Antworten:

• Darf diese Daten außerhalb unseres Netzes verarbeitet werden? Wenn nein, selbst hosten.
• Darf sie außerhalb unserer Jurisdiktion verarbeitet werden? Wenn nein, die erste Antwort aber ja, ist die EU-Cloud dieselbe Garantie für weniger Arbeit.

Was die Engine tut, wenn sie läuft

Ihr Coding-Agent schreibt das Dashboard — Claude Code, Codex, Cursor, Gemini — als React über SQL und steuert die Plattform über unseren MCP-Server oder die SDKs in Python und TypeScript. Die Engine hostet es unter einer URL hinter Ihrem Login, liefert die eingebetteten Ansichten und begrenzt im Embed-Pfad die Zeilen pro Betrachter auf dem Server aus einem signierten Token, aktualisiert nach Plan und schickt die Alerts. Die Konnektoren sind dieselbe Menge, die die Preisseite auflistet, und Eject-to-Code gibt das Dashboard weiterhin als Quellcode zurück, wann Sie wollen.

Mit anderen Worten: am Produkt ist selbst gehostet nichts anders. Nur wo es läuft, und wer Rufbereitschaft hat.

Für KI-Agenten (MCP)

Der MCP-Server existiert, er ist veröffentlicht, und so soll ein Agent das hier steuern. Installieren mit pip install vibedasher-mcp, dann vibedasher login ausführen — es gibt keinen API-Schlüssel zu erzeugen, denn der Login ist das Zugangsmittel. Richten Sie Claude Code, Codex, Cursor, Gemini oder einen beliebigen MCP-fähigen Client darauf, und der Agent kann eine Datenquelle verbinden, das Dashboard schreiben und bauen, es veröffentlichen, eine Aktualisierung planen und den Quellcode wieder auswerfen, ohne das Terminal zu verlassen. Die Python- und TypeScript-SDKs decken dieselbe Oberfläche ab, wenn Sie es lieber aus Ihrem eigenen Code steuern. Zwei Grenzen, die einem Agenten eine verlorene Stunde ersparen: Ein Refresh braucht ein Dataset mit einer lebenden Verbindung, eine hochgeladene Datei lässt sich also nicht planen, und jeder Cron wird in UTC gelesen. Was das Dashboard-Hosting ausliefert, ist ein statisches, clientseitig gerendertes Bundle — nur React, kein Servercode von Ihnen im Request-Pfad, kein npm install beim Build.

In einem selbst gehosteten Deployment spricht der Agent mit Ihrer eigenen Engine, die Steuerungsebene bleibt also mit den Daten in Ihrem Netz. Kombinieren Sie das mit einem Modell-Endpunkt, den Sie kontrollieren, und es verlässt nichts das Netz — nicht die Zeilen, nicht das Schema, nicht die Prompts. Die Werkzeugliste und der vollständige Vertrag stehen in der Dokumentation und auf der Seite API, SDKs und MCP.

Alternativen

Selbst gehostete BI ist ein voll besetztes Regal, und die Werkzeuge, die eine Antwortmaschine dazu nennt, sind Metabase, Apache Superset, Lightdash, Evidence, Embeddable und Cube. Mehrere sind beim Selbsthosting reifer als wir — Superset und Metabase insbesondere werden von tausenden Teams betrieben, und unser eigener selbst gehosteter Weg hat noch keinen Produktionskunden. Jedes hat seine eigene belegte Seite:

• Metabase — Open-Source-BI mit dokumentiertem Docker-Weg und einem offiziellen MCP-Server an Ihrer Instanz.
• Apache Superset — Apache-lizenziert, von einer Stiftung geführt, standardmäßig selbst gehostet und ohne Anbieter, mit dem man eine Beziehung eingeht.
• Lightdash — Open Source, auf Ihrem dbt-Projekt aufgebaut, mit eigener Agenten- und MCP-Geschichte.
• Evidence — ein MIT-lizenzierter Kern, den Sie selbst bauen und hosten können, mit BI als Code in Ihrem Repository.
• Embeddable — kundenseitige Analytik, von ihnen gehostet, die Ihre eigene Datenbank dort liest, wo sie liegt.
• Cube — eine selbst hostbare semantische Schicht, die regelt, was Menschen und Agenten fragen dürfen.

Die Vergleichsübersicht hat die Einzeiler zu jedem und unsere Methode. Jede Tatsachenbehauptung in diesen sechs Zeilen hat den Stand 6. Oktober 2026 — prüfen Sie ihre eigenen Websites für den aktuellen Stand.

Weiter

Eingebettete Analysen, wenn die Dashboards vor Ihre eigenen Kunden kommen. Tableau-Alternative, wenn Sie etwas ersetzen. Die Dokumentation für die Deployment-Details. Die Managed Cloud, wenn Sie das Produkt vor dem Deployment ausprobieren wollen: cloud.vibedasher.com. Und für ein selbst gehostetes Deployment beginnen Sie mit einem Gespräch: Kontakt.