Bring Your Own Storage (BYOS)
BYOS is an Enterprise plan capability that keeps your engagement telemetry entirely in storage you own. Your events land directly in your own Azure Data Lake Storage Gen2 account (BI Pixie never stores them) while you keep the full BI Pixie experience to manage your reports, add Pixies, and install the BI Pixie Dashboard.
When to use BYOS
- You have data-residency or data-sovereignty requirements that mandate telemetry stay in your own tenant and region.
- You want BI Pixie to never hold your telemetry at rest, and to read it only when you allow.
- You already run, or are willing to run, BI Pixie on Azure (BI Pixie's self-hosted edition).
This page covers BYOS in the BI Pixie Cloud portal. If you run BI Pixie inside Microsoft Fabric, BYOS is available there too (see BYOS in the Fabric Workload), alongside OneLake delivery, which routes events to your own OneLake lakehouse. For a side-by-side of every option, see the Data Residency overview.
How it works
- You run BI Pixie on Azure. You deploy BI Pixie on Azure (BI Pixie's self-hosted edition) in your own Azure subscription. It runs the BI Pixie telemetry web trigger and writes events directly to your own Azure Data Lake Storage Gen2 account.
- You point the Pixies at your telemetry web trigger. In the BI Pixie portal you enter the address of your self-hosted telemetry web trigger, and BI Pixie points the Pixies in your reports at it instead of at BI Pixie's own. Your telemetry never enters BI Pixie infrastructure.
- You can grant scoped read access (optional). To use Event Viewer and Data Management over your own store, you grant BI Pixie least-privilege, revocable access: a container-scoped Azure role assignment (recommended; secret-free) or a container-scoped SAS. Without a grant, BI Pixie never reads your data; you keep adding Pixies to your reports and managing your account.
Granting read access with an Azure role (recommended)
An Azure role assignment is the recommended grant: nothing is stored as a secret, and you can revoke it at any time. Setting up the role assignment takes three one-time steps in your own tenant:
- Consent to the BI Pixie app so its service principal, BI Pixie Delivery, exists in your tenant.
- Hold User Access Administrator (or Owner) on the storage scope so you can assign a role.
- Assign Storage Blob Data Reader to BI Pixie Delivery on your events container. For the optional read + delete tier, assign Storage Blob Data Contributor instead.
We recommend scoping the role to the events container rather than the whole storage account. A container-scoped grant is least-privilege, and keeps the assignment from interfering with import-mode (Power Query / M) refreshes that read the same account. BI Pixie only ever needs your events container.
Your data stays yours
- BI Pixie never stores your telemetry. Your telemetry lives only in your Azure account, and BI Pixie holds no copy.
- BI Pixie never deletes your telemetry on its own. BI Pixie performs no destructive operations against your store unless you explicitly opt in. In the BI Pixie Cloud portal you may grant an optional read + delete tier so you can erase data yourself (for example, GDPR requests); in the Fabric Workload, deletion and retention run as customer notebooks on your own Fabric capacity, so BI Pixie is never the one deleting.
- You can revoke BI Pixie's access at any time. To revoke it, remove the role, let the SAS expire, or switch back to BI Pixie storage in the portal. Switching back also ends BI Pixie's access to your store.
AI Readiness assessments with BYOS
You can assess your semantic models for AI Readiness while BYOS is on, and BI Pixie keeps none of the results. When an assessment finishes, the portal shows you the full result, and the result stays available until you refresh or close the browser tab where the assessment ran. BI Pixie does not write the result to its own storage or to your Azure Data Lake Storage Gen2 account, so BI Pixie cannot show you that result again later. BI Pixie also keeps no history of your assessment scores while BYOS is on.
To assess a semantic model, BI Pixie reads the semantic model's definition from your Power BI tenant under your own permissions, and processes it in BI Pixie's service in the Azure region assigned to your BI Pixie account. BI Pixie does not keep the definition afterward. BI Pixie sends nothing from your semantic models to an AI service unless an administrator on your BI Pixie account has connected your AI. The Trust Center lists each AI service you can connect and exactly what it receives, under Sub-Processors.
If you need your AI Readiness assessments kept in your own tenant, OneLake delivery, available when you run BI Pixie in the Fabric Workload, keeps them in your own lakehouse, where you can reopen them. An account uses either OneLake delivery or BYOS, and both keep your telemetry in your own tenant: OneLake delivery in your Fabric lakehouse, and BYOS in your Azure storage. The Trust Center sets out where an AI Readiness result goes for each storage option.
BYOS vs. the default
| BI Pixie storage (default) | BYOS (Enterprise plan) | |
|---|---|---|
| Where telemetry rests | Your dedicated, isolated container in BI Pixie's Azure | Your own Azure Data Lake account |
| Telemetry web trigger | Hosted by BI Pixie | Hosted by you |
| BI Pixie's access to the data | Full (it's our storage) | None, unless you grant scoped read access |
| Setup | Zero (automatic) | You run BI Pixie on Azure; configured with our team |
Full processing terms for BYOS, OneLake delivery, and BI Pixie storage are set out in our Data Processing Agreement.