# Embedded analytics for SaaS > Customer-facing dashboards written by your agent, hosted behind your login with per-customer row scoping — and how that differs from building in-house or embedding a visual-builder product. Source: https://vibedasher.com/embedded-analytics # Embedded analytics for SaaS Your customers want charts inside your product. You have a coding agent that can write those charts in an afternoon — Claude Code, Codex, Cursor and Gemini all produce decent React components over a SQL query, and they produce them faster than any ticket can describe them. What the agent cannot do is the part that comes after. It cannot keep the numbers correct next week, it cannot stop customer A from reading customer B's rows, and it cannot give you a URL you are willing to put in front of a paying account. That is the job vibedasher does. ## The division of labour **Your agent writes the dashboard.** React components, SQL queries, the layout, the chart choices. It writes the thing it is good at writing. **We host and govern it.** The dashboard gets a URL behind your login. Every query is scoped to the viewer on the server, so each customer sees only their own rows. You get an embed you can drop into your application, a refresh schedule, and alerts when a number crosses a line. You connect your warehouse once through one of our connectors, or upload a flat file. **Either side can leave.** Eject-to-code hands the dashboard back as source in your repo. Nothing we host is in a format only we can read, which is the whole point: the artifact your agent produced is the artifact we serve. [Start building](https://cloud.vibedasher.com) · [Talk to us](https://vibedasher.com/contact) ## Versus building it in-house Building embedded analytics yourself is a well-understood project, and that is exactly the problem: everybody underestimates the second half. The first dashboard is a week. The things that follow are per-tenant query scoping that holds up under an adversarial customer, a query layer that does not fall over when one account runs a year-long aggregation, caching with sensible invalidation, a refresh scheduler, and an on-call rotation for the hours when the numbers are wrong and a customer has noticed before you have. None of that is interesting work, and none of it differentiates your product. It is also the part your agent will confidently stub out and leave you to discover. ## Versus the embedded-analytics vendors Luzmo, Explo and Metabase all do embedded analytics, and they are real products — if a drag-and-drop builder is what your team wants, they are worth your time, and we are not going to pretend otherwise. The difference is what the dashboard **is**. In those products, a dashboard is an object authored in their builder and stored in their format; the embed serves that object. Your agent does not produce that object. It produces React and SQL, and there is no import path from "a component my agent wrote" into a visual builder's internal model — the translation loses the thing you wanted. vibedasher hosts the React and the SQL directly. That is the only real distinction, and it has one consequence worth stating plainly: because the artifact is code, taking it back is a copy, not a migration. ## Versus embedding Tableau or Power BI Same shape, older vintage. Tableau and Power BI host workbooks authored in their own builders and their embedding products serve those workbooks. If your organisation already runs on them, see [the Tableau alternative page](https://vibedasher.com/tableau-alternative) for what moving actually involves. ## Hosting On the managed cloud, dashboards, datasets and query results are processed and stored in the European Union, in Frankfurt — while 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. If your contracts or your customers' contracts will not allow that, the self-hosted build runs the same engine inside your own network — `docker compose` for a single host, a Helm chart for Kubernetes. Being straight about it: the self-hosted path is documented and tested, and it has no production customer yet. See [self-hosted BI](https://vibedasher.com/self-hosted-bi) for what that means in practice. ## Next Read the [API, SDK and MCP page](https://vibedasher.com/api-docs), or the [documentation](https://docs.vibedasher.com). When you want to try it: [cloud.vibedasher.com](https://cloud.vibedasher.com). When you would rather ask a person first: [contact](https://vibedasher.com/contact). ## Frequently asked questions Do my customers need a vibedasher account? No. The embed is authorised by your application, not by a separate login. You ask our API for a scoped token on behalf of the customer you have already authenticated, and the dashboard renders inside your product with that customer's rows and no others. How is row-level filtering enforced? On the server, when the query runs — not in the dashboard code. The scope travels with the token, so a viewer who edits the request, the URL or the client bundle still gets their own rows back. A filter applied in the frontend is a display choice, not a boundary, and we do not treat it as one. Can I keep the dashboard code? Yes. Eject-to-code hands you the dashboard as React source to host in your own application, and it keeps using our query API for data. There is a real ejected dashboard running on this site so you can look at the output rather than take our word for it. Where does the data live? On the managed cloud, dashboards, datasets and query results are processed and stored in the European Union, in Frankfurt. Sign-in identity — your email address and account membership — is held in the United States, for every account, wherever you are. If that is a blocker it should be, and the self-hosted build keeps both inside your network — same engine, same API. What does my agent need in order to build one? An MCP server. Point Claude Code, Codex, Cursor or any MCP-capable agent at ours and it can connect the data source, write the dashboard, publish it and configure refreshes without leaving the terminal. Python and TypeScript SDKs exist for driving it from your own code instead.