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

1. 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.
2. Pixels point at your telemetry web trigger. In the BI Pixie portal you set your self-hosted telemetry web trigger, and the Pixies in your reports send events to it instead of ours. Your telemetry never enters BI Pixie infrastructure.
3. (Optional) Grant scoped read access. To use Event Viewer and Data Management over your own store, you grant BI Pixie least-privilege, revocable access: a container-scoped RBAC 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 RBAC read access (recommended)

RBAC is the recommended grant: nothing is stored as a secret, and you can revoke it at any time. It is three one-time steps in your own tenant:

1. Consent to the BI Pixie app so its service principal — BI Pixie Delivery — exists in your tenant.
2. Hold User Access Administrator (or Owner) on the storage scope so you can assign a role.
3. 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.

Scope the role to the events container, not 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

• We never store it. Telemetry lives only in your Azure account; BI Pixie holds no copy.
• We never delete it on our 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.
• Revocable any time. Remove the role or let the SAS expire, or switch back to BI Pixie storage in-product, which also revokes our access.

BYOS vs. the default

Full processing terms for BYOS, OneLake delivery, and BI Pixie storage are set out in our Data Processing Agreement.