Where your data lives
Hosting location, storage, and where AI requests go.
This page lists where Beetl stores each kind of data, which data stays in your own systems, and what leaves Beetl, including the requests the assistant sends to a model.
Hosting location
Beetl hosts customer data in Germany by default. Other locations are available on request; contact Beetl to arrange one.
What Beetl stores
| Data | Where it is stored |
|---|---|
| Datasets Beetl writes, from webhooks, syncs, file processors and pipelines | The tenant's default object store: Beetl's hosted store, or your own bucket in the region you chose |
| Files uploaded to a File Set | The store that was the default when the File Set was created |
| Query results, including pipeline previews and automation evidence | Beetl's storage in the hosting location, whichever store your datasets use |
| Application data: pipeline and automation definitions, connection settings and credentials, run history and logs, chat conversations, users, API keys and assistant instructions | Beetl's database in the hosting location |
A new tenant writes to Beetl's hosted store. To keep your datasets in a bucket you control, a TenantAdmin adds it and chooses Use as Beetl storage; see Use your own bucket. Datasets that already exist stay in the store they were first written to, so make the switch before you load data.
Data that stays in your systems
Two kinds of dataset are never copied into Beetl:
- A registered dataset is a set of files in one of your object stores. Beetl reads them in place each time they are queried and never writes to, moves or deletes them.
- An external dataset is a table in your PostgreSQL database. Beetl queries it on demand and never writes to it.
A query over either kind reads the rows it needs at that moment. Like every query, it saves its result in Beetl's storage, where you can open it for 7 days.
What leaves Beetl
Data leaves Beetl in these cases:
- AI requests, described in the next section.
- MCP clients. Whatever an MCP client reads with your API key goes to that client and to the model it uses.
- Downloads. A CSV you download from a query result goes to your device.
- Your own systems. A sync's integration code calls the system it connects to, and registered and external datasets are read from your store or database.
Beetl does not send email, Slack or webhook notifications about runs.
AI requests
The assistant in chat and automations run on a model. For each turn or run, the model receives:
- your messages and the conversation so far, or an automation's instructions
- the assistant instructions a TenantAdmin wrote
- what the assistant reads through its tools: query rows, dataset names and schemas, pipeline definitions, run details and Beetl's platform reference
- in the sidebar, the page you have open
Beetl also uses the tenant's AI source to title conversations and to write a document for each deployed pipeline, so pipeline definitions reach the model even when nobody is chatting.
Where the requests go depends on the tenant's AI source:
| AI source | Where requests go |
|---|---|
| Managed AI | OpenRouter, a sub-processor, through its EU endpoint. OpenRouter passes each request to a provider of the model you selected. |
| Bring your own key | The provider you registered: Gemini, OpenRouter, or the base URL you entered for an OpenAI-compatible provider. Titles and pipeline documents use your key too. |
With your own key, your agreement with that provider governs how it handles the requests. MCP clients never use the tenant's AI source, because they bring their own model.
Dashboards
Dashboards run on an Apache Superset instance that Beetl prepares for your tenant and runs alongside the platform. Superset reads your tenant's datasets read-only, so a dashboard query cannot insert, update or delete data. Dashboard and chart definitions are stored in that Superset instance.
Related
Last updated on