What do I actually deploy?

The engine, which is what does the work: ETL and ingestion, the dataset layer, the query API, the dashboard host, the scheduler and the alerting. Two shapes are supported — docker compose for a single host, and a Helm chart for Kubernetes. It is the same engine as the managed cloud, not a reduced edition.

Does any data leave my network?

Not to run a query. The engine talks to your data sources and serves the dashboard from inside your network; a query never leaves it. What you choose to route outside is the model inference, and that is a decision you make: point it at your own LLM endpoint and nothing goes out at all.

Has anyone run this in production?

No. The self-hosted path is documented and tested, and it has no production customer yet. Saying otherwise would be the easiest lie on this site to tell and the fastest one to be caught in, so: you would be the first, and you should price that in.

Can I bring my own LLM?

Yes, and on the self-hosted path it is the point. The agent writing your dashboards can run against a model endpoint you control, so neither your data nor your prompts reach a third party.

Per deployment, and it is not metered. There are no query or ETL meters to watch and no per-seat count, because it is your hardware and your capacity. The figure depends on the deployment, which is why it is a conversation rather than a number on this page.

Self-hosted BI: run the whole engine inside your own network

Some data cannot leave a network. Sometimes that is regulation, sometimes it is a contract with a customer who is themselves regulated, and sometimes it is a security team who has simply decided and does not owe you a reason. In all three cases a hosted analytics product is not a cheaper option — it is not an option.

vibedasher runs on your own infrastructure for exactly that case.

What you deploy

The whole engine, not a thin client: ETL and ingestion, the dataset layer, the query API, the dashboard host, the scheduler, the alerting. Two supported shapes:

docker compose — a single host. The shape for an evaluation or a small internal deployment. The installer pulls base images from public registries, so it needs network access; there is no air-gapped distribution today.
A Helm chart — Kubernetes. The shape for anything that needs to survive a node going away.

It is the same engine as the managed cloud. Not a feature-reduced community edition, and not a fork that drifts: the self-hosted build and the hosted build are the same code, which is the only arrangement under which "self-hosted" means something a year later.

What stays inside

Queries do not leave. The engine connects to your data sources from inside your network and serves the dashboard from there; nothing round-trips through us to produce a number.

The one thing that can leave is model inference, and on this path you decide. Point the agent at your own LLM endpoint and nothing goes out at all — no data, no prompts, no schema. That is why bring-your-own-model is a self-hosted feature rather than a managed one: in your network it is the difference between a closed system and a nearly-closed one.

The honest status

There is no production customer on the self-hosted path yet. It is documented, it is tested on both shapes, and nobody is running their business on it.

This is written here, in the same size type as everything else, because it is the single most useful thing a reader evaluating self-hosted BI can know about us, and because it is the easiest claim on this site to fake and the fastest to be caught in. If you deploy it you are the first, and the right way to read that is: there will be rough edges in your environment that nobody has hit, and you should want a direct line to the person who wrote it before you commit. That line exists — contact — and it is a person, not a queue.

The managed alternative, if the reason is jurisdiction

A lot of people arrive looking for self-hosted when what they actually need is "not in the United States". If that is the constraint, read the whole answer before you decide. Dashboards, datasets and query results are processed and stored in the European Union, in Frankfurt, and we operate that — so you are not taking on the upgrades, the backups or the capacity planning. But sign-in identity — your email address and account membership — is held in the United States, for every account, wherever you are. The split is not something you choose and there is no region selector. So if the requirement is that nothing of yours touches the United States, the managed cloud does not meet it and the self-hosted build is the one that keeps both inside your network.

Worth separating the two questions before you choose, because they have different answers:

May this data be processed outside our network? If no, self-host.
May this data be processed outside our jurisdiction? If no but the first answer is yes, the EU cloud is less work for the same guarantee.

What the engine does once it is running

Your coding agent writes the dashboard — Claude Code, Codex, Cursor, Gemini — as React over SQL, and drives the platform over our MCP server or the Python and TypeScript SDKs. The engine hosts it at a URL behind your login, gives you embeds and, in the embed lane, scopes rows per viewer on the server from a signed token, refreshes on a schedule and sends alerts. The connectors are the same set the pricing page lists, and eject-to-code still hands the dashboard back as source whenever you want it.

In other words: nothing about the product is different self-hosted. Only where it runs, and who is on call.

For AI agents (MCP)

The MCP server exists, it is published, and it is how an agent is meant to drive this. Install it with pip install vibedasher-mcp, then run vibedasher login — there is no API key to mint, because the login is the credential. Point Claude Code, Codex, Cursor, Gemini or any MCP-capable client at it and the agent can connect a data source, write and build the dashboard, publish it, schedule a refresh and eject the source back out, all without leaving the terminal. Python and TypeScript SDKs cover the same surface when you would rather drive it from your own code. Two limits that save an agent a wasted hour: a refresh needs a dataset backed by a live connection, so an uploaded file cannot be scheduled, and every cron is read in UTC. What the dashboard host serves is a static, client-rendered bundle — React only, none of your server code in the request path, no npm install at build time.

On a self-hosted deployment the agent talks to your own engine, so the control plane stays inside your network along with the data. Pair it with a model endpoint you control and nothing — not the rows, not the schema, not the prompts — leaves. The tool list and the full contract are in the documentation and on the API, SDK and MCP page.

Alternatives

Self-hosted BI is a crowded shelf, and the tools an answer engine names when asked about it are Metabase, Apache Superset, Lightdash, Evidence, Embeddable and Cube. Several are more mature at being self-hosted than we are — Superset and Metabase in particular have been operated by thousands of teams, and our own self-hosted path still has no production customer. Each gets its own sourced page:

Metabase — open-source BI with a documented Docker path and an official MCP server at your instance endpoint.
Apache Superset — Apache-licensed, foundation-governed, self-hosted by default and with no vendor to have a relationship with.
Lightdash — open source, built on your dbt project, with its own agents and MCP story.
Evidence — an MIT-licensed core you can build and host yourself, with BI defined as code in your repository.
Embeddable — customer-facing analytics, cloud-hosted, reading your own database in place.
Cube — a self-hostable semantic layer that governs what humans and agents are allowed to ask.

The comparison hub has the one-line version of each and the method we used. Every factual claim in those six lines is as of 2026-10-06 — check their own sites for the current state.

Embedded analytics if the dashboards are going in front of your own customers. Tableau alternative if you are replacing something. The documentation for the deployment detail. The managed cloud, if you would rather try the product before the deployment: cloud.vibedasher.com. And for a self-hosted deployment, start with a conversation: contact.

Perguntas frequentes

What do I actually deploy?: The engine, which is what does the work: ETL and ingestion, the dataset layer, the query API, the dashboard host, the scheduler and the alerting. Two shapes are supported — docker compose for a single host, and a Helm chart for Kubernetes. It is the same engine as the managed cloud, not a reduced edition.
Does any data leave my network?: Not to run a query. The engine talks to your data sources and serves the dashboard from inside your network; a query never leaves it. What you choose to route outside is the model inference, and that is a decision you make: point it at your own LLM endpoint and nothing goes out at all.
Has anyone run this in production?: No. The self-hosted path is documented and tested, and it has no production customer yet. Saying otherwise would be the easiest lie on this site to tell and the fastest one to be caught in, so: you would be the first, and you should price that in.
Can I bring my own LLM?: Yes, and on the self-hosted path it is the point. The agent writing your dashboards can run against a model endpoint you control, so neither your data nor your prompts reach a third party.
How is it priced?: Per deployment, and it is not metered. There are no query or ETL meters to watch and no per-seat count, because it is your hardware and your capacity. The figure depends on the deployment, which is why it is a conversation rather than a number on this page.
What is the difference from the EU cloud?: Where it runs, and who operates it. Dashboards, datasets and query results are processed and stored in the European Union, in Frankfurt, and we run it — but sign-in identity, your email address and account membership, is held in the United States for every account, wherever you are. Self-hosted is in your network and you run it — which also means you own the upgrades, the backups and the capacity planning.