Network isolation & data residency¶

Datahub runs entirely inside your own cloud subscription — your data, secrets, and files never move to a shared or multi-tenant environment.

This page is written for security and compliance reviewers: what the deployment boundary is, where your data lives, and exactly what you can rely on.

Deployment modelSingle-tenant · your subscription

Data residencyYour chosen Azure region

Egress1 static IP / environment

EncryptionTLS in transit · at rest

What you can rely on¶

Dedicated isolation

Each deployment runs in its own Azure Virtual Network with no peering to other customers. Datahub's own systems have zero standing access to your data.
Data residency

Database, secrets, files, and search index all live in your subscription and your chosen Azure region. Nothing leaves it except through an integration you configure.
One static egress IP

Every outbound call leaves through a single fixed public IP per environment — one address to allowlist in your firewall or Databricks policy.
Private connectivity

Datahub reaches your Azure Data Lake storage over Azure Private Link, not the public internet, and you approve every connection on your side.

How the boundary works¶

Users reach Datahub only through Cloudflare; every internal hop between the app, its database, and its secret store stays inside a private Azure Virtual Network; and every outbound call leaves through one static IP. Nothing crosses into a shared Datahub tenant.

flowchart LR
    U["Your users"] --> CF["Cloudflare<br/>WAF · DDoS · Access"]
    CF --> WEB
    CF --> API
    subgraph SUB["Your Azure subscription · dedicated VNet"]
        WEB["Web app<br/>your-subdomain.datahub.nl"] --> API["Backend API<br/>no public Azure endpoint"]
        API --> DB[("PostgreSQL<br/>public access disabled")]
        API --> KV[["Key Vault<br/>deny by default"]]
        API --> EG(["Static egress IP<br/>one per environment"])
    end
    EG --> EXT["External services you configure<br/>Databricks · Microsoft 365 · dbt Cloud · webhooks"]
    classDef accent fill:#ff8400,stroke:#e67700,color:#ffffff,font-weight:600;
    class EG accent

Figure 1 — Inbound traffic is funnelled through Cloudflare; app, database, and Key Vault communicate only inside a private VNet; all outbound calls exit through a single static egress IP. Nothing crosses into a shared tenant.

Nothing shared, nothing implicit

The application services connect to your database from within the private network using application credentials stored in your Key Vault. Datahub's own systems have zero access to your database, your secrets, or your files. Support access requires you to explicitly grant it via Azure RBAC.

Where your data lives¶

Component	Location
Application database	Azure PostgreSQL Flexible Server, in your subscription and chosen region
Secrets & credentials	Azure Key Vault, in your subscription
Frontend & backend services	Azure Container Apps, in your subscription
AI/search index	Azure Blob Storage, in your subscription

Network access paths¶

Who can reach the application¶

Access to Datahub is controlled exclusively through Cloudflare. There are two protected entry points per deployment:

Entry point	What it serves	Who can reach it
`{your-subdomain}.datahub.nl`	Datahub web app	Anyone with valid credentials; protected by Cloudflare WAF and DDoS mitigation
`api-{your-subdomain}.datahub.nl`	Backend API	Browser sessions only (authenticated); no other inbound path exists

The backend API has no public Azure endpoint — it is only reachable via the Cloudflare-protected API route. Direct connections to the underlying cloud service are not possible.

Internal service communication¶

All communication between application components (frontend ↔ backend, backend ↔ database, backend ↔ secret store) runs entirely within a private Azure Virtual Network. No inter-service traffic crosses the public internet.

The database has public network access disabled. It is only reachable from within the private network.
The secret store (Key Vault) denies all connections by default. Only the application services inside the private network can retrieve secrets.

Outbound connections¶

Some features require Datahub to make outbound calls to external services you configure (e.g. Databricks, Microsoft 365, dbt Cloud, webhooks). All outbound traffic from Datahub exits through a single static IP address per environment.

Static egress IP¶

Every environment has a fixed public IP address for all outbound connections. You can use this address to allowlist Datahub in your corporate firewall, Databricks workspace policy, or any other system that requires IP-based access control.

Your static egress IP is provided in your onboarding documentation. Contact support if you need it.

What this means for integrations

When you configure a Databricks workspace connection, a Microsoft 365 integration, or a webhook endpoint, you only need to add one IP address to your allowlist. That address never changes unless you explicitly request an environment migration.

Private-network hosts¶

Datahub will not connect to a data source on a private network unless you say so, per integration.

By default a connection is refused when its address resolves to a private, loopback or link-local network. This holds for Databricks, Microsoft Fabric, PostgreSQL and Azure SQL alike, and on every path, not just the connection test. For a Databricks workspace that means queries, catalog browsing, metrics, alerts, dashboards and Genie. Nothing is contacted, and the refusal says so explicitly rather than reporting an unreachable host.

To allow it, open the integration under Admin → Integrations (for Databricks, its Credentials tab) and turn on Network access → Allow private-network hosts. It saves as soon as you switch it. Grant it only for a host you intend Datahub to reach there, and keep the address under your own control.

This switch only lifts Datahub's own refusal. Datahub still needs a network route to the host; see the troubleshooting row on internal data sources below.

Private connectivity to your storage¶

When you connect an Azure Data Lake Storage (ADLS Gen2) account as a data source, Datahub reaches it over Azure Private Link rather than the public internet. You stay in control of the connection: it is created in a Pending state and only goes live once you approve it on your storage account.

flowchart LR
    subgraph DHV["Datahub VNet · your subscription"]
        API["Backend"] --> PE["Private Endpoint pair<br/>blob + dfs · dedicated subnet"]
    end
    PE --> PL(["Azure Private Link<br/>never the public internet"])
    PL --> ST[("Your ADLS Gen2<br/>storage account")]
    ST -. you approve .-> PE
    classDef accent fill:#ff8400,stroke:#e67700,color:#ffffff,font-weight:600;
    class PL accent

Figure 2 — Datahub connects to your data lake over Azure Private Link. The endpoint pair lands in "Pending" until you approve it on your storage account, and Datahub's managed identity holds no storage permissions.

Property	How it works
Transport	Azure Private Link. Traffic between Datahub and your storage never traverses the public internet.
Endpoints	A blob + dfs Private Endpoint pair is provisioned per storage connection, in a dedicated subnet, with private DNS records so the storage hostname resolves inside the network.
You approve	Each connection is created in a Pending state and only becomes active once you approve it on your storage account.
Least privilege	Datahub's managed identity holds network and private-DNS rights only — zero storage permissions.

What we guarantee¶

Guarantee	What it means	How it's enforced
No standing access to your data	Datahub does not read your database, secrets, or files.	Application services connect from within your private network using application credentials stored in your Key Vault; any support access requires an Azure RBAC role assignment you control.
Encrypted at rest	Your data is encrypted on disk.	Azure PostgreSQL and Azure Blob Storage use platform-managed encryption by default; you can bring your own key (BYOK) via Azure Key Vault.
Encrypted in transit	Every connection uses TLS.	TLS everywhere, including internal service-to-service traffic within the private network.
Tenant boundary	Your deployment is isolated from other customers.	Each deployment runs in a dedicated virtual network with no peering to other customers.
Access control by IP / location	You can restrict who reaches Datahub.	Cloudflare Access policies, configurable per deployment. Contact support to enable this.

Troubleshooting¶

Symptom	Likely cause	Action
An integration says our IP address is blocked	Your firewall is not yet allowlisting the Datahub egress IP	Add the static egress IP to your allowlist; the IP is in your onboarding docs or available from support
This connection points at a host on a private network, and this integration is not allowed to reach one. Nothing was contacted.	The workspace or server address resolves to a private network, and the integration's network access does not allow one. Datahub declined on purpose; your firewall is not the issue	If the address is intended, turn on Network access → Allow private-network hosts on the integration (for Databricks, its Credentials tab); if it is not, correct the address. See Private-network hosts
Datahub cannot reach an internal data source	Datahub cannot connect to private networks in your organisation by default	Contact support to discuss private peering or a VPN tunnel option
Cloudflare shows an access error before the login page	Cloudflare Access policy is blocking the connection	Check the Cloudflare Access policy configured for your deployment