` with
your tenant ID:
`https://login.microsoftonline.com/
/oauth2/authorize?client_id=0c5d0d4b-6cee-402e-9a08-e5b79f199481&response_type=code&redirect_uri=https%3A%2F%2Fwww.microsoft.com%2F`
-3. The Cube Cloud service principal has specific credentials. Check that the
+3. The Cube service principal has specific credentials. Check that the
following details match exactly what you see on the dialog box that pops up:
- Client ID: `d1c59948-4d4a-43dc-8d04-c0df8795ae19`
@@ -87,7 +87,7 @@ On the [Azure Portal][azure-console], go to **Subscriptions**
## Deployment
-The actual deployment will be done by Cube Cloud automation. All that's left to
+The actual deployment will be done by Cube automation. All that's left to
do is notify your Cube contact point that access has been granted, and pass
along your Azure Tenant/Subscription/Region information.
diff --git a/docs-mintlify/admin/deployment/dedicated/azure/index.mdx b/docs-mintlify/admin/deployment/dedicated/azure/index.mdx
new file mode 100644
index 0000000000000..2c0f51d14ec49
--- /dev/null
+++ b/docs-mintlify/admin/deployment/dedicated/azure/index.mdx
@@ -0,0 +1,42 @@
+---
+title: Dedicated Infrastructure on Azure
+sidebarTitle: Azure
+description: Connect Cube's Dedicated Infrastructure on Azure to your VNets and corporate networks, or deploy the entire data plane inside your own Azure subscription via BYOC.
+---
+
+On Azure, Cube offers single-tenant Dedicated Infrastructure operated by Cube,
+and Bring Your Own Cloud (BYOC) operated inside your own Azure subscription.
+Both options support private network connectivity to your data sources.
+
+## Backend connectivity (Cube → your network)
+
+Use these options to give Cube private access to your data sources, auth
+providers, BI APIs targeted by Semantic Layer Sync, and anything else Cube
+needs to query. See [Backend and frontend connectivity][backend-frontend] for
+the full picture.
+
+- [**Azure Private Link**][azure-private-link] — connect to data sources
+ exposed through Azure Private Link Services without routing traffic over
+ the public internet.
+- [**VNet Peering**][azure-vnet-peering] — establish a VNet peering connection
+ between the Cube VNet and your own VNet.
+
+## Frontend connectivity (your clients → Cube)
+
+Expose Cube's APIs to your applications, browsers, BI tools, embedded
+analytics clients, and Semantic Layer Sync-generated configs over a private
+network. The pattern mirrors the AWS implementation documented in
+[Private API Connectivity on AWS][aws-private-api-connectivity];
+[contact us](https://cube.dev/contact) to enable the equivalent on Azure for
+your tenant.
+
+## Bring Your Own Cloud
+
+If you'd like the entire Cube data plane to live inside your own Azure
+subscription, see [Bring Your Own Cloud on Azure][azure-byoc].
+
+[azure-private-link]: /admin/deployment/dedicated/azure/private-link
+[azure-vnet-peering]: /admin/deployment/dedicated/azure/vpc-peering
+[azure-byoc]: /admin/deployment/dedicated/azure/byoc
+[aws-private-api-connectivity]: /admin/deployment/dedicated/aws/private-api-connectivity
+[backend-frontend]: /admin/deployment/dedicated#backend-and-frontend-connectivity
diff --git a/docs-mintlify/admin/deployment/dedicated/azure/private-link.mdx b/docs-mintlify/admin/deployment/dedicated/azure/private-link.mdx
new file mode 100644
index 0000000000000..dd2f6e16ae408
--- /dev/null
+++ b/docs-mintlify/admin/deployment/dedicated/azure/private-link.mdx
@@ -0,0 +1,136 @@
+---
+title: Setting up Azure Private Link
+sidebarTitle: Private Link
+description: How to publish an Azure Private Link Service and coordinate the connection so Cube's Dedicated Infrastructure reaches your VNet privately.
+---
+
+
+
+This page covers **backend connectivity** — Cube reaching into your network to
+query data sources, auth providers, BI APIs targeted by Semantic Layer Sync,
+and other upstream services. See
+[Backend and frontend connectivity][backend-frontend] for the full picture.
+For **frontend connectivity** (exposing Cube's APIs to your applications,
+browsers, BI tools, and embedded analytics clients), see
+[Private API Connectivity on AWS][aws-private-api-connectivity]; the
+equivalent pattern is available on Azure on request.
+
+
+
+[Azure Private Link][azure-docs-private-link] enables you to access Azure
+PaaS services and Azure-hosted customer-owned/partner services over a private
+endpoint in your virtual network. To set up a Private Link connection between
+Cube's Dedicated Infrastructure and your own VNet, you'll need to prepare a
+Private Link Service, share service details with the Cube team, and approve
+the incoming connection request.
+
+## Preparing the Private Link Service
+
+There are two common scenarios for preparing the Private Link Service:
+
+- Connecting to a service in your Azure infrastructure
+- Connecting to a service provided by a third party such as Snowflake,
+ Databricks, Confluent Cloud, etc.
+
+In the case of your own infrastructure, please follow the
+[official Azure documentation][azure-docs-private-link-service] to configure
+the Private Link Service behind a standard Azure Load Balancer.
+
+If your data source is hosted in a third-party infrastructure, please follow
+the vendor's documentation for creating and managing a Private Link Service.
+
+## Configuring service visibility
+
+Azure Private Link Service enables you to control the visibility of your
+private endpoint. You'll need to configure access permissions to allow Cube
+to connect to your service.
+
+To allow Cube access, please go to **Azure Portal** → **Private Link
+Services** → **Your service** → **Manage visibility** and add the following
+subscription ID to the allowed list: `cd69336e-c628-4a88-a56e-86900a0df732`.
+
+
+
+This is the Azure subscription ID of Cube's Private Link consumer
+subscription. Adding it authorizes Cube to discover your Private Link
+Service and create a private endpoint against it; nothing else in Cube's
+Azure estate gains access to your network.
+
+
+
+Alternatively, you can configure auto-approval for faster connection
+establishment by adding the same subscription ID to the auto-approval list
+under **Manage auto-approval**.
+
+## Gathering required information
+
+To request establishing a Private Link connection, please share the following
+information with the Cube team:
+
+- **Private Link Service Resource ID** (such as
+ `/subscriptions/abc123/resourceGroups/myResourceGroup/providers/Microsoft.Network/privateLinkServices/myservice`)
+- **Reference Name** for the record (such as "Snowflake-prod" or
+ "databricks-dev")
+- **Ports**: a list of ports that will be accessed through this connection
+- **DNS Name(s)**: see [DNS and TLS](#dns-and-tls) below
+- **Cube Region:** Private Link requires Cube to be hosted on
+ [Dedicated Infrastructure][cube-region]. Specify which Cube Region should
+ host your Dedicated Infrastructure.
+
+## DNS and TLS
+
+How your data source is addressed inside Cube depends on whether it speaks
+TLS:
+
+- **If the service uses TLS** (HTTPS, JDBC `Encrypt=true`, etc.), share the
+ **DNS name(s)** the certificate is issued for — typically the same
+ hostname your in-network clients already use to reach it. Cube creates
+ internal DNS overrides inside the Dedicated Infrastructure so that the
+ same hostname resolves to the Private Endpoint. Keeping the original
+ hostname is what preserves TLS validity: the certificate's CN/SAN keeps
+ matching what Cube dials.
+- **If the service does not use TLS** and you don't supply a DNS name, the
+ Cube team will share back an internal endpoint hostname (e.g. an
+ Azure-assigned private-endpoint DNS name) that you can configure as the
+ upstream when you wire the connection into Cube.
+
+## Approving the connection
+
+The connection approval process depends on your visibility configuration:
+
+### Manual approval
+
+If you haven't configured auto-approval, the Cube team will notify you once
+the Private Endpoint connection request is sent. You can approve it by:
+
+1. Going to **Azure Portal** → **Private Link Center** → **Private Link
+ Services** → **Your Service** → **Private endpoint connections**.
+2. Finding the pending connection from Cube.
+3. Clicking **Approve** and optionally providing an approval message.
+
+Alternatively, you can approve the connection from the resource itself if it
+supports Private Link natively (e.g., Storage Accounts, SQL Databases).
+
+### Auto-approval
+
+If you've added Cube's subscription ID to the auto-approval list, the
+connection will be automatically approved upon creation and no manual action
+is required.
+
+## Using the connection
+
+Once the connection is established, you can access your data source by
+addressing it via the DNS name(s) you supplied (TLS case) or the internal
+endpoint hostname returned to you by the Cube team (non-TLS case).
+
+## Supported Regions
+
+Azure Private Link is available in all Azure commercial regions where
+Dedicated Infrastructure can be provisioned. Azure operated by 21Vianet
+(China) and Azure Government regions are not supported.
+
+[azure-docs-private-link]: https://docs.microsoft.com/azure/private-link/
+[azure-docs-private-link-service]: https://docs.microsoft.com/azure/private-link/create-private-link-service-portal
+[cube-region]: /admin/deployment/infrastructure#understanding-cube-cloud-region
+[aws-private-api-connectivity]: /admin/deployment/dedicated/aws/private-api-connectivity
+[backend-frontend]: /admin/deployment/dedicated#backend-and-frontend-connectivity
diff --git a/docs-mintlify/admin/deployment/dedicated/azure/vpc-peering.mdx b/docs-mintlify/admin/deployment/dedicated/azure/vpc-peering.mdx
new file mode 100644
index 0000000000000..60aed39709591
--- /dev/null
+++ b/docs-mintlify/admin/deployment/dedicated/azure/vpc-peering.mdx
@@ -0,0 +1,137 @@
+---
+title: Setting up VNet Peering on Azure
+sidebarTitle: VNet Peering
+description: End-to-end checklist for VNet peering Cube's Dedicated Infrastructure with your Azure VNet for private data access.
+---
+
+
+
+This page covers **backend connectivity** — Cube reaching into your network to
+query data sources, auth providers, BI APIs targeted by Semantic Layer Sync,
+and other upstream services. See
+[Backend and frontend connectivity][backend-frontend] for the full picture.
+For **frontend connectivity** (exposing Cube's APIs to your applications,
+browsers, BI tools, and embedded analytics clients), see
+[Private API Connectivity on AWS][aws-private-api-connectivity]; the
+equivalent pattern is available on Azure on request.
+
+
+
+For cross-tenant peering in Azure, you assign the peering role to the service
+principal of the peering party. Using the steps outlined below, you would
+register the Cube tenant in your organization, grant peering access to the
+Cube service principal, and hand over the information Cube needs to initiate
+the peering.
+
+## Granting peering access to Cube
+
+### Add the Cube tenant to your organization
+
+First, add the Cube tenant to your organization. Open the
+[Azure Portal][azure-console] and go to **Azure Active Directory** →
+**External Identities** → **Cross-tenant access settings** →
+**Organizational Settings** → **Add Organization**.
+
+For Tenant ID, enter `197e5263-87f4-4ce1-96c4-351b0c0c714a`.
+
+Make sure that **B2B Collaboration** → **Inbound Access** →
+**Applications** is set to **Allows access**.
+
+### Register the Cube service principal at your organization
+
+To register the Cube service principal for your organization, follow these
+steps:
+
+1. Log in with an account that has permissions to register Enterprise
+ applications.
+2. Open a browser tab and go to the following URL, replacing ``
+ with your tenant ID:
+ `https://login.microsoftonline.com//oauth2/authorize?client_id=7f3afcf3-e061-4e1b-8261-f396646d7fc7&response_type=code&redirect_uri=https%3A%2F%2Fwww.microsoft.com%2F`
+3. The Cube service principal has specific credentials. Check that the
+ following details match exactly what you see on the dialog box that
+ pops up:
+
+ - Client ID: `7f3afcf3-e061-4e1b-8261-f396646d7fc7`
+ - Name: `cube-dedicated-infra-peering-sp`
+
+ Once you have confirmed that all the information is correct,
+ select **Consent on behalf of your organization** and
+ click **Accept**.
+
+### Grant peering permissions on your virtual network
+
+As the peering role you can use the built-in `Network Contributor` role or
+create a custom role (e.g. `cube-peering-role`) with the following
+permissions:
+
+- `Microsoft.Network/virtualNetworks/virtualNetworkPeerings/write`
+- `Microsoft.Network/virtualNetworks/peer/action`
+- `Microsoft.ClassicNetwork/virtualNetworks/peer/action`
+- `Microsoft.Network/virtualNetworks/virtualNetworkPeerings/read`
+- `Microsoft.Network/virtualNetworks/virtualNetworkPeerings/delete`
+
+On the [Azure Portal][azure-console], go to **Virtual networks** →
+_Virtual Network Name_ → **Access Control (IAM)** → **Add** →
+**Add role assignment** and fill in the following details:
+
+- Role: `Network Contributor` or `cube-peering-role`
+- Members: `cube-dedicated-infra-peering-sp`
+
+## Information required by Cube
+
+When reaching out to Cube support, please provide the following information:
+
+- **Virtual Network ID:** Find this at **Virtual Networks** →
+ _Virtual Network Name_ → **Overview** → **JSON view** →
+ **Resource ID** on the [Azure Portal][azure-console].
+- **Virtual Network Address Spaces:** Find this at **Virtual Networks**
+ → _Virtual Network Name_ → **Overview** → **JSON view** →
+ **properties** → **addressSpace** on the [Azure Portal][azure-console].
+- **Tenant ID:** Find this in **Azure Active Directory** →
+ **Properties** → **Tenant ID** section of the
+ [Azure Portal][azure-console].
+- **Cube Region:** VNet Peering requires Cube to be hosted on
+ [Dedicated Infrastructure][cube-region]. Specify which Cube Region should
+ host your Dedicated Infrastructure.
+
+## Firewall and routing
+
+Once the peering is established, allow traffic from Cube's VNet CIDR block to
+reach your data source:
+
+1. **Network Security Groups (NSGs)** attached to the data-source subnet (or
+ the resource itself) must include an inbound rule that permits TCP traffic
+ from Cube's VNet CIDR on the database port. For example, for PostgreSQL:
+
+ | Priority | Source | Source Port | Destination | Service / Port | Action |
+ | -------- | ---------------------------- | ----------- | ----------- | -------------- | ------ |
+ | 1000 | Cube VNet CIDR (e.g. 10.x/16)| `*` | `VirtualNetwork` | TCP / 5432 | Allow |
+
+ Cube's VNet CIDR is shared with you alongside the peering request and is
+ also visible in the Azure Portal on the **Virtual networks** →
+ **\** → **Peerings** → **\** → **Address
+ space** field.
+
+2. **Azure Firewall / third-party NVAs**: if traffic between your subnets
+ transits a firewall, add a rule permitting TCP from the Cube VNet CIDR to
+ the data source's IP and port.
+
+3. **User-defined routes (UDRs)**: confirm that the route tables on your
+ subnets do not blackhole Cube's CIDR via `0.0.0.0/0` next-hop appliances.
+ Ensure traffic destined for Cube's VNet CIDR is routed to the **Virtual
+ network peering** next-hop.
+
+4. **Data source firewall**: if the resource has its own firewall (e.g. an
+ Azure SQL Server firewall or a PaaS-level allow-list), add Cube's VNet
+ CIDR there as well.
+
+## Supported Regions
+
+VNet Peering is available in all Azure commercial regions where Dedicated
+Infrastructure can be provisioned. Azure operated by 21Vianet (China) and
+Azure Government regions are not supported.
+
+[azure-console]: https://portal.azure.com
+[cube-region]: /admin/deployment/infrastructure#understanding-cube-cloud-region
+[aws-private-api-connectivity]: /admin/deployment/dedicated/aws/private-api-connectivity
+[backend-frontend]: /admin/deployment/dedicated#backend-and-frontend-connectivity
diff --git a/docs-mintlify/admin/deployment/byoc/gcp/deployment.mdx b/docs-mintlify/admin/deployment/dedicated/gcp/byoc.mdx
similarity index 88%
rename from docs-mintlify/admin/deployment/byoc/gcp/deployment.mdx
rename to docs-mintlify/admin/deployment/dedicated/gcp/byoc.mdx
index 9e09347fb06ae..6f6b291687622 100644
--- a/docs-mintlify/admin/deployment/byoc/gcp/deployment.mdx
+++ b/docs-mintlify/admin/deployment/dedicated/gcp/byoc.mdx
@@ -1,23 +1,23 @@
---
-title: Deploying Cube Cloud BYOC on GCP
-sidebarTitle: GCP
-description: Project setup, permissions, and provisioning flow for Cube Cloud BYOC inside a dedicated GCP project.
+title: Bring Your Own Cloud on GCP
+sidebarTitle: BYOC
+description: Project setup, permissions, and provisioning flow for deploying Cube BYOC inside a dedicated GCP project.
---
With Bring Your Own Cloud (BYOC) on Google Cloud Platform (GCP), all the components interacting with private data are deployed on
-the customer infrastructure on GCP and managed by the Cube Cloud Control Plane via the Cube Cloud Operator.
-This document provides step-by-step instructions for deploying Cube Cloud BYOC on GCP.
+the customer infrastructure on GCP and managed by the Cube Control Plane via the Cube Operator.
+This document provides step-by-step instructions for deploying Cube BYOC on GCP.
## Prerequisites
-The bulk of provisioning work will be done remotely by Cube Cloud automation.
+The bulk of provisioning work will be done remotely by Cube automation.
However, to get started, you'll need:
### Required Information
- **GCP Project ID:** A dedicated GCP project ID that will exclusively host Cube-managed infrastructure.
- This should be a new, isolated project created specifically for Cube Cloud BYOC.
-- **GCP Region:** [The GCP region][gcp-docs-regions] where Cube Cloud resources
+ This should be a new, isolated project created specifically for Cube BYOC.
+- **GCP Region:** [The GCP region][gcp-docs-regions] where the BYOC resources
should be deployed.
### Required Permissions
@@ -91,11 +91,11 @@ gcloud services enable \
### Step 3: Grant IAM permissions
-In order to manage resources in the Cube-dedicated GCP project, Cube Cloud Service Principal
+In order to manage resources in the Cube-dedicated GCP project, the Cube service principal
needs to be granted administrative permissions to a set of services.
Navigate to **IAM & Admin > IAM** in your dedicated project and add the following IAM
-binding for the Cube Cloud service account:
+binding for the Cube service account:
**Principal:** `cube-cloud-byoc-installer@cube-cloud-byoc.iam.gserviceaccount.com`
@@ -115,7 +115,7 @@ You can grant these permissions through the Google Cloud Console UI or using the
# Set your project ID (replace with your actual project ID)
export PROJECT_ID="your-cube-byoc-project-id"
-# Set the Cube Cloud service account (use this exact value)
+# Set the Cube service account (use this exact value)
export CUBE_SA="cube-cloud-byoc-installer@cube-cloud-byoc.iam.gserviceaccount.com"
# Grant all required roles
@@ -146,7 +146,7 @@ gcloud projects add-iam-policy-binding $PROJECT_ID \
### Step 4: Grant Service Account User permissions
-Additionally, the Cube Cloud service account needs permission to use the default Compute Engine service account for GKE node pools.
+Additionally, the Cube service account needs permission to use the default Compute Engine service account for GKE node pools.
@@ -168,7 +168,7 @@ gcloud iam service-accounts add-iam-policy-binding \
--project=$PROJECT_ID
```
-This allows the Cube Cloud service account to create GKE clusters that use the project's default compute service account for worker nodes.
+This allows the Cube service account to create GKE clusters that use the project's default compute service account for worker nodes.
### Step 5: Verify setup
@@ -194,11 +194,11 @@ If all commands return the expected results, you're ready to proceed with deploy
## Deployment
-The actual deployment will be done by Cube Cloud automation. All that's left to
+The actual deployment will be done by Cube automation. All that's left to
do is notify your Cube contact point that access has been granted, and pass
along your GCP Project ID and Region information.
-After deployment, Cube Cloud will manage the following resources in your dedicated project:
+After deployment, Cube will manage the following resources in your dedicated project:
- A VPC network with subnets, Cloud Router, and Cloud NAT for outbound connectivity
- A GKE cluster with node pools for running Cube applications
diff --git a/docs-mintlify/admin/deployment/dedicated/gcp/index.mdx b/docs-mintlify/admin/deployment/dedicated/gcp/index.mdx
new file mode 100644
index 0000000000000..2c08f348337d3
--- /dev/null
+++ b/docs-mintlify/admin/deployment/dedicated/gcp/index.mdx
@@ -0,0 +1,42 @@
+---
+title: Dedicated Infrastructure on GCP
+sidebarTitle: GCP
+description: Connect Cube's Dedicated Infrastructure on GCP to your VPC networks via Private Service Connect or VPC Peering, or deploy the entire data plane inside your own GCP project via BYOC.
+---
+
+On GCP, Cube offers single-tenant Dedicated Infrastructure operated by Cube,
+and Bring Your Own Cloud (BYOC) operated inside your own GCP project. Both
+options support private network connectivity to your data sources.
+
+## Backend connectivity (Cube → your network)
+
+Use these options to give Cube private access to your data sources, auth
+providers, BI APIs targeted by Semantic Layer Sync, and anything else Cube
+needs to query. See [Backend and frontend connectivity][backend-frontend] for
+the full picture.
+
+- [**Private Service Connect**][gcp-private-service-connect] — connect to
+ data sources exposed through GCP Service Attachments without routing traffic
+ over the public internet.
+- [**VPC Peering**][gcp-vpc-peering] — establish a VPC peering connection
+ between the Cube VPC and your own VPC.
+
+## Frontend connectivity (your clients → Cube)
+
+Expose Cube's APIs to your applications, browsers, BI tools, embedded
+analytics clients, and Semantic Layer Sync-generated configs over a private
+network. The pattern mirrors the AWS implementation documented in
+[Private API Connectivity on AWS][aws-private-api-connectivity];
+[contact us](https://cube.dev/contact) to enable the equivalent on GCP for
+your tenant.
+
+## Bring Your Own Cloud
+
+If you'd like the entire Cube data plane to live inside your own GCP project,
+see [Bring Your Own Cloud on GCP][gcp-byoc].
+
+[gcp-private-service-connect]: /admin/deployment/dedicated/gcp/private-service-connect
+[gcp-vpc-peering]: /admin/deployment/dedicated/gcp/vpc-peering
+[gcp-byoc]: /admin/deployment/dedicated/gcp/byoc
+[aws-private-api-connectivity]: /admin/deployment/dedicated/aws/private-api-connectivity
+[backend-frontend]: /admin/deployment/dedicated#backend-and-frontend-connectivity
diff --git a/docs-mintlify/admin/deployment/dedicated/gcp/private-service-connect.mdx b/docs-mintlify/admin/deployment/dedicated/gcp/private-service-connect.mdx
new file mode 100644
index 0000000000000..d396fdbdbebb1
--- /dev/null
+++ b/docs-mintlify/admin/deployment/dedicated/gcp/private-service-connect.mdx
@@ -0,0 +1,126 @@
+---
+title: Setting up Google Private Service Connect
+sidebarTitle: Private Service Connect
+description: How to publish a Service Attachment and coordinate Private Service Connect so Cube's Dedicated Infrastructure reaches your VPC privately.
+---
+
+
+
+This page covers **backend connectivity** — Cube reaching into your network to
+query data sources, auth providers, BI APIs targeted by Semantic Layer Sync,
+and other upstream services. See
+[Backend and frontend connectivity][backend-frontend] for the full picture.
+For **frontend connectivity** (exposing Cube's APIs to your applications,
+browsers, BI tools, and embedded analytics clients), see
+[Private API Connectivity on AWS][aws-private-api-connectivity]; the
+equivalent pattern is available on GCP on request.
+
+
+
+[Private Service Connect][gcp-docs-psc] (PSC) provides private connectivity
+between VPC networks in different projects or organizations, without VPC
+peering or exposing your traffic to the public internet. To set up a PSC
+connection between Cube's Dedicated Infrastructure and your own VPC, you'll
+need to publish a Service Attachment, share its details with the Cube team,
+and approve the incoming connection request.
+
+## Preparing the Service Attachment
+
+There are two common scenarios for preparing the Service Attachment:
+
+- Connecting to a service in your GCP infrastructure
+- Connecting to a service provided by a third party such as Snowflake,
+ Databricks, Confluent Cloud, etc.
+
+In the case of your own infrastructure, follow the
+[official GCP documentation][gcp-docs-publish-service] to publish a Service
+Attachment that points at an
+[internal passthrough or proxy Network Load Balancer][gcp-docs-internal-lb]
+in front of your data source.
+
+If your data source is hosted in a third-party infrastructure, follow the
+vendor's documentation for creating and managing a Service Attachment.
+
+## Allowing the Cube consumer project
+
+PSC service attachments can restrict which consumer projects are allowed to
+create a PSC endpoint against them. Cube's PSC consumer project is
+`cube-cloud-dedicated`.
+
+In the GCP Console, go to **Network services → Private Service Connect →
+Published services → \** and add `cube-cloud-dedicated` to
+**Accepted projects**. For faster connection establishment, you can also
+add the same project to the **auto-accept** list so the connection is
+approved automatically when Cube initiates it.
+
+
+
+`cube-cloud-dedicated` is the GCP project Cube uses to host Dedicated
+Infrastructure PSC endpoints. Adding it to your accepted-projects list
+authorizes Cube to create a private endpoint against your Service
+Attachment; nothing else in Cube's GCP estate gains access to your network.
+
+
+
+## Gathering required information
+
+To request establishing a PSC connection, please share the following
+information with the Cube team:
+
+- **Service Attachment URI** (such as
+ `projects//regions//serviceAttachments/`)
+- **Reference Name** for the record (such as "Snowflake-prod" or
+ "clickhouse-dev")
+- **Ports**: a list of ports that will be accessed through this connection
+- **DNS Name(s)**: see [DNS and TLS](#dns-and-tls) below
+- **Cube Region:** PSC requires Cube to be hosted on
+ [Dedicated Infrastructure][cube-region]. Specify which Cube Region should
+ host your Dedicated Infrastructure.
+
+## DNS and TLS
+
+How your data source is addressed inside Cube depends on whether it speaks
+TLS:
+
+- **If the service uses TLS** (HTTPS, JDBC `sslmode=require`, etc.), share
+ the **DNS name(s)** the certificate is issued for — typically the same
+ hostname your in-network clients already use to reach it. Cube creates
+ internal DNS overrides inside the Dedicated Infrastructure so that the
+ same hostname resolves to the PSC endpoint. Keeping the original hostname
+ is what preserves TLS validity: the certificate's CN/SAN keeps matching
+ what Cube dials.
+- **If the service does not use TLS** and you don't supply a DNS name, the
+ Cube team will share back an internal endpoint hostname that you can
+ configure as the upstream when you wire the connection into Cube.
+
+## Accepting the connection
+
+The approval flow depends on how your Service Attachment is configured:
+
+- **Manual acceptance.** Cube will notify you once the connection request
+ has been sent. Approve it in the GCP Console under **Network services →
+ Private Service Connect → Published services → \ →
+ Connected endpoints**, then select the pending connection and click
+ **Accept**.
+- **Auto-accept.** If you added `cube-cloud-dedicated` to the auto-accept
+ list, the connection is approved automatically upon creation and no
+ further action is required.
+
+## Using the connection
+
+Once the connection is established, you can access your data source by
+addressing it via the DNS name(s) you supplied (TLS case) or the internal
+endpoint hostname returned to you by the Cube team (non-TLS case).
+
+## Supported Regions
+
+Private Service Connect is available in all GCP commercial regions where
+Dedicated Infrastructure can be provisioned. GCP regions in mainland China
+(serviced by partner providers) are not supported.
+
+[gcp-docs-psc]: https://cloud.google.com/vpc/docs/private-service-connect
+[gcp-docs-publish-service]: https://cloud.google.com/vpc/docs/configure-private-service-connect-producer
+[gcp-docs-internal-lb]: https://cloud.google.com/load-balancing/docs/internal
+[cube-region]: /admin/deployment/infrastructure#understanding-cube-cloud-region
+[aws-private-api-connectivity]: /admin/deployment/dedicated/aws/private-api-connectivity
+[backend-frontend]: /admin/deployment/dedicated#backend-and-frontend-connectivity
diff --git a/docs-mintlify/admin/deployment/dedicated/gcp/vpc-peering.mdx b/docs-mintlify/admin/deployment/dedicated/gcp/vpc-peering.mdx
new file mode 100644
index 0000000000000..2f890839d5c5b
--- /dev/null
+++ b/docs-mintlify/admin/deployment/dedicated/gcp/vpc-peering.mdx
@@ -0,0 +1,84 @@
+---
+title: Setting up VPC Peering on GCP
+sidebarTitle: VPC Peering
+description: End-to-end checklist for VPC peering Cube's Dedicated Infrastructure with your GCP VPC network for private data access.
+---
+
+
+
+This page covers **backend connectivity** — Cube reaching into your network to
+query data sources, auth providers, BI APIs targeted by Semantic Layer Sync,
+and other upstream services. See
+[Backend and frontend connectivity][backend-frontend] for the full picture.
+For **frontend connectivity** (exposing Cube's APIs to your applications,
+browsers, BI tools, and embedded analytics clients), see
+[Private API Connectivity on AWS][aws-private-api-connectivity]; the
+equivalent pattern is available on GCP on request.
+
+
+
+VPC Peering requires Cube to be hosted on
+[Dedicated Infrastructure][cube-region]. Let the Cube team know which Cube
+Region should host your Dedicated Infrastructure.
+
+Cube will provision the Dedicated VPC and provide the following information
+you can use to create the peering request:
+
+- **GCP Project ID:** `cube-cloud-dedicated` (the project Cube uses to host
+ Dedicated VPCs).
+- **VPC Network Name:** shared with you by the Cube team once the Dedicated
+ VPC is provisioned.
+
+## Setup
+
+### Creating the peering connection
+
+After receiving the information above, create a
+[VPC peering request][gcp-docs-vpc-peering], either through the
+[GCP Web Console][gcp-console] or an infrastructure-as-code tool. To send a
+VPC peering request through the Google Cloud Console, follow
+[the instructions here][gcp-docs-create-vpc-peering], with the following
+amendments:
+
+- In Step 6, use the project ID `cube-cloud-dedicated` and the network name
+ provided by Cube.
+- In Step 7, ensure **Import custom routes** and **Export custom routes** are
+ selected so that the necessary routes are created.
+
+### Firewall and routing
+
+Once the peering is established, configure your VPC firewall rules to allow
+inbound TCP traffic from Cube's VPC CIDR block to your data source on the
+database port. Cube's VPC CIDR is shared with you alongside the peering
+request and is also visible in the GCP Console on the **VPC network** →
+**\** → **VPC network peering** → **\** page as
+the **Peer VPC network** subnet ranges.
+
+If your data source is in a different project or subnet that transits a
+firewall or Cloud NAT, add a matching allow rule for Cube's CIDR there as
+well.
+
+## Cloud SQL
+
+Google Cloud SQL databases
+[can only be peered to a VPC within the same GCP project][gcp-docs-vpc-peering-restrictions].
+If you need Cube to reach a Cloud SQL instance, prefer
+[Private Service Connect][gcp-private-service-connect] (Cloud SQL supports
+PSC natively), or alternatively provision a small VM in your GCP project
+running the [Cloud SQL Auth Proxy][gcp-cloudsql-auth-proxy].
+
+## Supported Regions
+
+VPC Peering is available in all GCP commercial regions where Dedicated
+Infrastructure can be provisioned. GCP regions in mainland China (serviced
+by partner providers) are not supported.
+
+[gcp-cloudsql-auth-proxy]: https://cloud.google.com/sql/docs/mysql/connect-admin-proxy
+[gcp-console]: https://console.cloud.google.com/
+[gcp-docs-create-vpc-peering]: https://cloud.google.com/vpc/docs/using-vpc-peering#creating_a_peering_configuration
+[gcp-docs-vpc-peering]: https://cloud.google.com/vpc/docs/vpc-peering
+[gcp-docs-vpc-peering-restrictions]: https://cloud.google.com/vpc/docs/vpc-peering#restrictions
+[cube-region]: /admin/deployment/infrastructure#understanding-cube-cloud-region
+[gcp-private-service-connect]: /admin/deployment/dedicated/gcp/private-service-connect
+[aws-private-api-connectivity]: /admin/deployment/dedicated/aws/private-api-connectivity
+[backend-frontend]: /admin/deployment/dedicated#backend-and-frontend-connectivity
diff --git a/docs-mintlify/admin/deployment/dedicated/index.mdx b/docs-mintlify/admin/deployment/dedicated/index.mdx
new file mode 100644
index 0000000000000..c2855b5a1e4cb
--- /dev/null
+++ b/docs-mintlify/admin/deployment/dedicated/index.mdx
@@ -0,0 +1,80 @@
+---
+title: Dedicated Infrastructure
+description: Run Cube on dedicated single-tenant infrastructure (managed by Cube) or on your own AWS, Azure, or GCP account (BYOC), with private connectivity to your data sources and APIs.
+---
+
+Cube offers two flavors of single-tenant deployment: **Dedicated Infrastructure**
+managed by Cube in our cloud accounts, and **Bring Your Own Cloud (BYOC)** managed
+by Cube inside your own cloud account. Both options give you isolated compute,
+the ability to route traffic over private networks, and integrations with
+services in your VPC or VNet.
+
+
+
+Available on the [Enterprise plan](https://cube.dev/pricing) with the
+[Dedicated Infrastructure][ref-dedicated-infra] add-on.
+
+
+
+## Single-tenant Cube cluster
+
+With Dedicated Infrastructure, Cube provisions and operates a **single-tenant**
+cluster for you in a Cube-managed account on AWS, GCP, or Azure. *Single-tenant*
+means the cluster — VPC/VNet, compute, storage, and the Cube data plane that
+runs your deployments — is dedicated entirely to your organization and not
+shared with any other customer. The cluster lives in a Cube
+[Region][cube-region], can be peered or PrivateLink/PSC-connected to your own
+networks, and can optionally expose Cube's APIs to your network so that no Cube
+traffic ever crosses the public internet.
+
+## Bring Your Own Cloud (BYOC)
+
+On the Enterprise plan, Cube is also available as **Bring Your Own Cloud**: all
+components that interact with your private data are deployed inside your own
+AWS, Azure, or GCP account and managed remotely by the Cube Control Plane via
+the Cube Operator. This keeps all data plane resources within your boundary
+while preserving the managed-service experience.
+[Contact us](https://cube.dev/contact) for details.
+
+## Backend and frontend connectivity
+
+There are two distinct directions in which Cube exchanges traffic with your
+network, and each has its own connectivity story:
+
+- **Backend connectivity** — traffic that flows **from Cube into your network**.
+ Cube uses these connections to query the things it needs to function:
+ databases and warehouses, auth providers (e.g. an internal OIDC issuer),
+ upstream BI APIs that Semantic Layer Sync targets, and any other service the
+ Cube data plane has to reach. PrivateLink, Private Link, Private Service
+ Connect, and Peering on the provider pages below all configure backend
+ connectivity.
+- **Frontend connectivity** — traffic that flows **from your network into
+ Cube**. Anything that needs to query Cube falls in this bucket: the Cube UI
+ running in employee browsers, application servers, BI tools, embedded
+ analytics clients, and Semantic Layer Sync-generated configs. Frontend
+ connectivity is currently documented for AWS in
+ [Private API Connectivity on AWS][aws-private-api-connectivity], and
+ equivalent patterns are available on Azure and GCP on request.
+
+Most enterprise deployments end up using both: a backend
+PrivateLink/PSC/peering into the customer's data network, plus a frontend
+private API endpoint so the Cube UI and BI tools talk to Cube over the same
+private fabric.
+
+## Choose a provider
+
+
+
+ Dedicated Infrastructure, BYOC, and private connectivity on AWS.
+
+
+ Dedicated Infrastructure and BYOC on GCP.
+
+
+ Dedicated Infrastructure, BYOC, and private connectivity on Azure.
+
+
+
+[ref-dedicated-infra]: /admin/deployment/infrastructure#dedicated-infrastructure
+[aws-private-api-connectivity]: /admin/deployment/dedicated/aws/private-api-connectivity
+[cube-region]: /admin/deployment/infrastructure#understanding-cube-cloud-region
diff --git a/docs-mintlify/admin/deployment/dedicated/pre-aggregation-storage.mdx b/docs-mintlify/admin/deployment/dedicated/pre-aggregation-storage.mdx
new file mode 100644
index 0000000000000..171ffded78830
--- /dev/null
+++ b/docs-mintlify/admin/deployment/dedicated/pre-aggregation-storage.mdx
@@ -0,0 +1,64 @@
+---
+title: Bring-Your-Own Pre-aggregation Storage
+sidebarTitle: Pre-aggregation Storage
+description: Supply your own object storage bucket as the backend for Cube Store pre-aggregated data so that all data at rest stays within your infrastructure.
+---
+
+On the Enterprise plan, Dedicated Infrastructure customers can supply their
+own object storage bucket to be used as the underlying storage for Cube Store
+pre-aggregated data. This lets you keep all data at rest fully within your
+own infrastructure while still leveraging the managed compute and operations
+of Dedicated Infrastructure.
+
+
+
+Available on the [Enterprise plan](https://cube.dev/pricing) with Dedicated
+Infrastructure. [Contact us](https://cube.dev/contact) to enable this option
+for your tenant.
+
+
+
+## AWS — S3
+
+To activate this option on AWS:
+
+1. Create an S3 bucket in the same region as your Cube Region.
+2. Generate a new AWS Access Key with full access to that bucket.
+3. Request activation from your Customer Success Manager and share the
+ following:
+ - **AWS Access Key ID**
+ - **AWS Secret Access Key**
+ - **S3 Bucket ARN**
+
+## GCP — Cloud Storage
+
+To activate this option on GCP:
+
+1. Create a Cloud Storage bucket in the same region as your Cube Region.
+2. Create a service account with full access to that bucket and generate a
+ JSON service-account key.
+3. Request activation from your Customer Success Manager and share the
+ following:
+ - **GCS Bucket Name**
+ - **Service-account JSON key** (transferred securely)
+
+## Azure — Blob Storage
+
+To activate this option on Azure:
+
+1. Create a Storage Account and Blob container in the same region as your
+ Cube Region.
+2. Create a SAS token (or service principal) with full read/write/delete
+ access to the container.
+3. Request activation from your Customer Success Manager and share the
+ following:
+ - **Storage Account name**
+ - **Container name**
+ - **Access credentials** (SAS token or service-principal details)
+
+## Supported Regions
+
+Bring-Your-Own Pre-aggregation Storage is available wherever Dedicated
+Infrastructure is supported on the corresponding cloud — see the per-provider
+[Supported Regions](#supported-regions) sections in the connectivity docs for
+the exact list. Government and China regions are not supported.
diff --git a/docs-mintlify/admin/deployment/vpc/aws/index.mdx b/docs-mintlify/admin/deployment/vpc/aws/index.mdx
deleted file mode 100644
index 3759a5bebb00c..0000000000000
--- a/docs-mintlify/admin/deployment/vpc/aws/index.mdx
+++ /dev/null
@@ -1,20 +0,0 @@
----
-title: AWS VPC Connectivity
-description: Establish a private network connection between Cube Cloud and your AWS VPC using PrivateLink or VPC peering.
----
-
- Connecting with a VPC on AWS
-
-[Single-tenant infrastructure][dedicated-infrastructure] in Cube Cloud comes with
-an option of setting up a direct network connection between
-an AWS VPC on the Cube Cloud side and your own VPC(s). Such a connection allows you to
-access internal datasources without the need to expose any ports publicly.
-
-On AWS, Cube Cloud supports two main ways of establishing a private network connection:
-
-- [AWS PrivateLink][aws-private-link]
-- [VPC Peering][aws-vpc-peering]
-
-[dedicated-infrastructure]: /admin/deployment/infrastructure#dedicated-infrastructure
-[aws-private-link]: /docs/deployment/cloud/vpc/aws/private-link
-[aws-vpc-peering]: /docs/deployment/cloud/vpc/aws/vpc-peering
\ No newline at end of file
diff --git a/docs-mintlify/admin/deployment/vpc/aws/private-link.mdx b/docs-mintlify/admin/deployment/vpc/aws/private-link.mdx
deleted file mode 100644
index 4e2f69d515a2a..0000000000000
--- a/docs-mintlify/admin/deployment/vpc/aws/private-link.mdx
+++ /dev/null
@@ -1,59 +0,0 @@
----
-title: Connecting to your VPC using AWS PrivateLink
-sidebarTitle: AWS PrivateLink
-description: How to expose an AWS endpoint service and coordinate PrivateLink so Cube single-tenant infrastructure reaches your VPC privately.
----
-
-[AWS PrivateLink][aws-docs-private-link] provides private connectivity between virtual private clouds (VPCs), supported services and resources, and your on-premises networks, without exposing your traffic to the public internet.
-To set up a PrivateLink connection between Cube Cloud Dedicated Infrastructure and your own VPC,
-you'll need to prepare an Endpoint Service,
-share service details with the Cube team, and accept the incoming connection request.
-
-## Preparing the Endpoint Service
-
-There are two common scenarios for preparing the Endpoint Service:
-- Connecting to a service in your AWS infrastructure
-- Connecting to a service provided by a third party such as Snowflake, Databricks, Altinity Cloud, etc.
-
-In the case of your own infrastructure, please follow the [official AWS documentation][aws-docs-endpoint-service] to configure the Endpoint Service
-pointing at your data source.
-
-If your data source is hosted in a third-party infrastructure, please follow the vendor's documentation
-for creating and managing an Endpoint Service.
-
-## Allowing Cube Cloud Principal
-
-Cube Cloud needs to be added to the list of principals allowed to discover your Endpoint Service.
-To do so, please go to **AWS Console** -> **VPC** -> **Endpoint Services** -> **Your service** -> **Allow principals**
-and add `arn:aws:iam::331376342520:root` to the list.
-
-## Gathering required information
-
-To request establishing a PrivateLink connection, please share the following information with the Cube team:
-
-- **Service Name** (such as `com.amazonaws.vpce.us-west-2.vpce-svc-abcde`)
-- **Reference Name** for the record (such as "Snowflake-prod" or "clickhouse-dev")
-- **Ports**: a list of ports that will be accessed through this connection
-- **DNS Name** (optional): an internal DNS name of the upstream service in case SSL needs to be supported
-- **Dedicated Infrastructure Region:** VPC Peering requires Cube to be hosted in
- [single-tenant infrastructure][dedicated-infra]. Please specify what region the Cube Cloud
- single-tenant infrastructure should be hosted in.
-
-
-If a DNS name is provided, an internal DNS record will be created pointing at the established PrivateLink
-connection, and the service will be addressable by that name inside the Cube Cloud infrastructure.
-
-## Accepting the connection
-
-The Cube Cloud team will notify you once the connection request is sent. You can accept it by going to
-**AWS Console** -> **VPC** -> **Endpoint Services** -> **Your Service** -> **Endpoint Connections** and clicking
-**Accept Connection Request**.
-
-## Using the connection
-
-Once the connection is established, you can access your data source by addressing it either via the
-supplied DNS Name or an AWS internal DNS name returned to you by the Cube team.
-
-[aws-docs-private-link]: https://aws.amazon.com/privatelink/
-[aws-docs-endpoint-service]: https://docs.aws.amazon.com/vpc/latest/privatelink/configure-endpoint-service.html
-[dedicated-infra]: /admin/deployment/infrastructure#dedicated-infrastructure
\ No newline at end of file
diff --git a/docs-mintlify/admin/deployment/vpc/aws/vpc-peering.mdx b/docs-mintlify/admin/deployment/vpc/aws/vpc-peering.mdx
deleted file mode 100644
index f5fc8c9afcf53..0000000000000
--- a/docs-mintlify/admin/deployment/vpc/aws/vpc-peering.mdx
+++ /dev/null
@@ -1,147 +0,0 @@
----
-title: Setting up a VPC Peering connection on AWS
-sidebarTitle: VPC Peering
-description: End-to-end checklist for VPC peering Cube Cloud single-tenant infrastructure with your AWS VPC for private data access.
----
-
-To set up AWS VPC Peering, you need to collect the necessary information and
-hand it over to your Cube Cloud representative. Next, you'll have to accept a
-VPC peering request sent by Cube Cloud. Finally, you'll need to configure
-security groups and route tables to ensure Cube Cloud can connect to your data
-source.
-
-## Prerequisites
-
-To allow Cube Cloud to connect to a [VPC on AWS][aws-docs-vpc], the following
-information is required:
-
-- **AWS Account ID:** The AWS account ID of the VPC owner. This can be found in
- the top-right corner of [the AWS Console][aws-console].
-- **AWS Region:** [The AWS region][aws-docs-regions] that the VPC resides in.
-- **AWS VPC ID:** The ID of the VPC that Cube Cloud will connect to, for
- example, `vpc-0099aazz`
-- **AWS VPC CIDR:** The [CIDR block][wiki-cidr-block] of the VPC that Cube Cloud
- will connect to, for example, `10.0.0.0/16`
-- **Dedicated Infrastructure Region:** VPC Peering requires Cube to be hosted in
- [single-tenant infrastructure][dedicated-infra]. Please specify what region the Cube Cloud
- single-tenant infrastructure should be hosted in.
-
-## Setup
-
-### VPC Peering Request
-
-After receiving the information above, Cube Cloud will send a [VPC peering
-request][aws-docs-vpc-peering] that must be accepted. This can be done either
-through the [AWS Web Console][aws-console] or through an infrastructure-as-code
-tool.
-
-To [accept the VPC peering request][aws-docs-vpc-peering-accept] through the AWS
-Web Console, follow the instructions below:
-
-1. Open the [Amazon VPC console](https://console.aws.amazon.com/vpc/).
-
-
-
- Ensure you have the necessary permissions to accept a VPC peering request. If
- you are unsure, please contact your AWS administrator.
-
-
-
-2. Use the Region selector to choose the Region of the accepter VPC.
-
-3. In the navigation pane, choose **Peering connections**.
-
-4. Select the pending VPC peering connection (the status should be
- `pending-acceptance`), then choose **Actions**, followed by
- **Accept request**.
-
-
-
- Ensure the peering request is from Cube Cloud by checking that the **AWS account
- ID**, **region** and **VPC IDs** match those provided by your CSM.
-
-
-
-5. When prompted for confirmation, choose **Accept request**.
-
-6. Choose **Modify my route tables now** to add a route to the VPC route
- table so that you can send and receive traffic across the peering
- connection.
-
-
-
-For more information about peering connection lifecycle statuses, check out the
-[VPC peering connection lifecycle on AWS][aws-docs-vpc-peering-lifecycle].
-
-
-
-### Updating security groups
-
-The initial VPC setup will not allow traffic from Cube Cloud; this is because
-[the security group][aws-docs-vpc-security-group] for the database will need to
-allow access from the Cube Cloud CIDR block.
-
-This can be achieved by adding a new security group rule:
-
-| Protocol | Port Range | Source/Destination |
-| -------- | ---------- | --------------------------------------------- |
-| TCP | 3306 | The Cube Cloud CIDR block for the AWS region. |
-
-### Update route tables
-
-The final step is to update route tables in your VPC to allow traffic from Cube
-Cloud to reach your database. The Cube Cloud CIDR block must be added to the
-route tables of all subnets that connect to the database. To do this, follow the
-instructions on [the AWS documentation][aws-docs-vpc-peering-routing].
-
-## Troubleshooting
-
-Database connection issues with misconfigured VPCs often manifest as connection
-timeouts. If you are experiencing connection issues, please check the following:
-
-- Verify that
- [all security groups allow traffic](#setup-updating-security-groups) from the
- Cube Cloud provided CIDR block.
-- Verify that
- [a route exists to the Cube Cloud provided CIDR block](#setup-update-route-tables)
- from the subnets that connect to the database.
-
-## Using dedicated pre-aggregation storage
-
-On the Enterprise product tier, you get an option to supply your own S3 bucket to
-be used as an underlying storage for Cube Store pre-aggregated data. This
-allows you to keep all data at-rest fully within your infrastructure while
-still leveraging the full power of the Cube Cloud for managed compute.
-
-To activate this option, simply create an S3 bucket and generate a new AWS
-Access Key that would allow full bucket access for Cube Cloud. After it's done,
-request the dedicated pre-aggregation storage to be activated from your
-Customer Success Manager and share with them the following:
-
-- **AWS Access Key Id**
-- **AWS Secret Access Key**
-- **S3 Bucket ARN**
-
-[aws-console]: https://console.aws.amazon.com/
-[aws-docs-regions]:
- https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html#concepts-available-regions
-[aws-docs-vpc]:
- https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html
-[aws-docs-vpc-peering-accept]:
- https://docs.aws.amazon.com/vpc/latest/peering/create-vpc-peering-connection.html#different-account-different-region
-[aws-docs-vpc-peering-lifecycle]:
- https://docs.aws.amazon.com/vpc/latest/peering/vpc-peering-basics.html#vpc-peering-lifecycle
-[aws-docs-vpc-peering-routing]:
- https://docs.aws.amazon.com/vpc/latest/peering/vpc-peering-routing.html
-[aws-docs-vpc-peering]:
- https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html
-[aws-docs-vpc-security-group]: https://docs.aws.amazon.com/vpc/latest/userguide/security-group-rules.html
-[dedicated-infra]: /admin/deployment/infrastructure#dedicated-infrastructure
-[wiki-cidr-block]:
- https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing#CIDR_blocks
-
-## Supported Regions
-
-We support all general-purpose regions. Cube Store is currently located only in
-`US East 2` and `EU West 1` so pre-aggregations performance might depend on geographical
-proximity to it.
diff --git a/docs-mintlify/admin/deployment/vpc/azure/index.mdx b/docs-mintlify/admin/deployment/vpc/azure/index.mdx
deleted file mode 100644
index 684a983a62f6e..0000000000000
--- a/docs-mintlify/admin/deployment/vpc/azure/index.mdx
+++ /dev/null
@@ -1,20 +0,0 @@
----
-title: Azure VNet Connectivity
-description: Establish a private network connection between Cube Cloud and your Azure VNet using Private Link or VNet peering.
----
-
- Connecting with a VNet on Azure
-
-[Single-tenant infrastructure][dedicated-infrastructure] in Cube Cloud comes with
-an option of setting up a direct network connection between
-an Azure VNet on the Cube Cloud side and your own VNet(s). Such a connection allows you to
-access internal datasources without the need to expose any ports publicly.
-
-On Azure, Cube Cloud supports two main ways of establishing a private network connection:
-
-- [Azure Private Link][azure-private-link]
-- [VNet Peering][azure-vnet-peering]
-
-[dedicated-infrastructure]: /admin/deployment/infrastructure#dedicated-infrastructure
-[azure-private-link]: /admin/deployment/vpc/azure/private-link
-[azure-vnet-peering]: /admin/deployment/vpc/azure/vpc-peering
\ No newline at end of file
diff --git a/docs-mintlify/admin/deployment/vpc/azure/private-link.mdx b/docs-mintlify/admin/deployment/vpc/azure/private-link.mdx
deleted file mode 100644
index fd1fda5227c38..0000000000000
--- a/docs-mintlify/admin/deployment/vpc/azure/private-link.mdx
+++ /dev/null
@@ -1,79 +0,0 @@
----
-title: Connecting to your VNet using Azure Private Link
-sidebarTitle: Azure Private Link
-description: Configure Azure Private Link visibility and approvals so Cube single-tenant infrastructure connects to services in your VNet.
----
-
-[Azure Private Link][azure-docs-private-link] enables you to access Azure PaaS services and Azure hosted customer-owned/partner services over a private endpoint in your virtual network.
-To set up a Private Link connection between Cube Cloud single-tenant infrastructure and your own VNet,
-you'll need to prepare a Private Link Service,
-share service details with the Cube team, and approve the incoming connection request.
-
-## Preparing the Private Link Service
-
-There are two common scenarios for preparing the Private Link Service:
-- Connecting to a service in your Azure infrastructure
-- Connecting to a service provided by a third party such as Snowflake, Databricks, Confluent Cloud, etc.
-
-In the case of your own infrastructure, please follow the [official Azure documentation][azure-docs-private-link-service] to configure the Private Link Service
-behind a standard Azure Load Balancer.
-
-If your data source is hosted in a third-party infrastructure, please follow the vendor's documentation
-for creating and managing a Private Link Service.
-
-## Configuring Service Visibility
-
-Azure Private Link Service enables you to control the visibility of your private endpoint. You'll need to configure
-access permissions to allow Cube Cloud to connect to your service.
-
-To allow Cube Cloud access, please go to **Azure Portal** -> **Private Link Services** -> **Your service** -> **Manage visibility**
-and add the following subscription ID to the allowed list: `cd69336e-c628-4a88-a56e-86900a0df732`
-
-Alternatively, you can configure auto-approval for faster connection establishment by adding the same subscription ID
-to the auto-approval list under **Manage auto-approval**.
-
-## Gathering required information
-
-To request establishing a Private Link connection, please share the following information with the Cube team:
-
-- **Private Link Service Resource ID** (such as `/subscriptions/abc123/resourceGroups/myResourceGroup/providers/Microsoft.Network/privateLinkServices/myservice`)
-- **Reference Name** for the record (such as "Snowflake-prod" or "databricks-dev")
-- **Ports**: a list of ports that will be accessed through this connection
-- **DNS Name** (optional): an internal DNS name of the upstream service in case SSL needs to be supported
-- **Single-tenant Infrastructure Region:** Private Link requires Cube to be hosted in
- [single-tenant infrastructure][dedicated-infra]. Please specify what region the Cube Cloud
- single-tenant infrastructure should be hosted in.
-
-If a DNS name is provided, an internal DNS record will be created pointing at the established Private Link
-connection, and the service will be addressable by that name inside the Cube Cloud infrastructure.
-
-## Approving the connection
-
-The connection approval process depends on your visibility configuration:
-
-### Manual Approval
-If you haven't configured auto-approval, the Cube Cloud team will notify you once the Private Endpoint connection request is sent. You can approve it by:
-
-1. Going to **Azure Portal** -> **Private Link Center** -> **Private Link Services** -> **Your Service** -> **Private endpoint connections**
-2. Finding the pending connection from Cube Cloud
-3. Clicking **Approve** and optionally providing an approval message
-
-Alternatively, you can approve the connection from the resource itself if it supports Private Link natively (e.g., Storage Accounts, SQL Databases).
-
-### Auto-Approval
-If you've added Cube Cloud's subscription ID to the auto-approval list, the connection will be automatically approved
-upon creation, and no manual action is required.
-
-## Using the connection
-
-Once the connection is established, you can access your data source by addressing it either via the
-supplied DNS Name or an Azure internal DNS name returned to you by the Cube team.
-
-## Supported Regions
-
-Private Link connections are supported in all Azure regions where Cube Cloud single-tenant infrastructure is available.
-The Private Link Service and Private Endpoint must be in the same region as the Cube Cloud infrastructure.
-
-[azure-docs-private-link]: https://docs.microsoft.com/azure/private-link/
-[azure-docs-private-link-service]: https://docs.microsoft.com/azure/private-link/create-private-link-service-portal
-[dedicated-infra]: /admin/deployment/infrastructure#dedicated-infrastructure
\ No newline at end of file
diff --git a/docs-mintlify/admin/deployment/vpc/azure/vpc-peering.mdx b/docs-mintlify/admin/deployment/vpc/azure/vpc-peering.mdx
deleted file mode 100644
index 4d0608de1277e..0000000000000
--- a/docs-mintlify/admin/deployment/vpc/azure/vpc-peering.mdx
+++ /dev/null
@@ -1,99 +0,0 @@
----
-title: Connecting with a VNet on Azure
-sidebarTitle: VNet Peering
-description: For cross-tenant peering in Azure, you are supposed to assign the peering role to the service principal of the peering party.
----
-
-## Setup
-
-For cross-tenant peering in Azure, you are supposed to assign the peering role
-to the service principal of the peering party.
-
-Using the steps outlined below, you would register Cube Cloud tenant at your
-organization and grant peering access to Cube Cloud service principal.
-
-### Add Cube tenant to your organization
-
-First you should add the Cube Cloud tenant to your organization. To do this,
-open the [Azure Portal][azure-console] and go to **Azure Active
-Directory** → **External Identities** → **Cross-tenant
-access settings** → **Organizational Settings**
-→ **Add Organization**.
-
-For Tenant ID, enter `197e5263-87f4-4ce1-96c4-351b0c0c714a`.
-
-Make sure that **B2B Collaboration** → **Inbound Access**
-→ **Applications** is set to **Allows access**.
-
-### Register Cube Cloud service principal at your organization
-
-To register the Cube Cloud service principal for your organization, follow these
-steps:
-
-1. Log in with an account that has permissions to register Enterprise
- applications.
-2. Open a browser tab and go to the following URL, replacing `` with
- your tenant ID:
- `https://login.microsoftonline.com//oauth2/authorize?client_id=7f3afcf3-e061-4e1b-8261-f396646d7fc7&response_type=code&redirect_uri=https%3A%2F%2Fwww.microsoft.com%2F`
-3. The Cube Cloud service principal has specific credentials. Check that the
- following details match exactly what you see on the dialog box that pops up:
-
-- Client ID: `7f3afcf3-e061-4e1b-8261-f396646d7fc7`
-- Name: `cube-dedicated-infra-peering-sp`
-
-Once you have confirmed that all the information is correct,
-select **Consent on behalf of your organization** and
-click **Accept**.
-
-### Grant peering permissions to Cube Cloud service principal on your `Virtual Network`
-
-As `peering role` you can use built-in `Network Contributor` or create custom
-role (e.g. `cube-peering-role`) with the following permissions:
-
-- `Microsoft.Network/virtualNetworks/virtualNetworkPeerings/write`
-- `Microsoft.Network/virtualNetworks/peer/action`
-- `Microsoft.ClassicNetwork/virtualNetworks/peer/action`
-- `Microsoft.Network/virtualNetworks/virtualNetworkPeerings/read`
-- `Microsoft.Network/virtualNetworks/virtualNetworkPeerings/delete`
-
-On the [Azure Portal][azure-console], go to **Virtual networks**
-→ _Virtual Network Name_ → **Access Control (IAM)**
-→ **Add** → **Add role assignment** and fill
-in the following details:
-
-- Role: `Network Contributor` or `cube-peering-role`
-- Members: `cube-dedicated-infra-peering-sp`
-
-### Firewall
-
-Make sure that your firewall rules allow inbound and outbound traffic to IP/port
-your database is listening at.
-
-## Information required by Cube Cloud support
-
-When you are reaching out Cube Cloud support please provide following
-information:
-
-- **Virtual Network ID:** You can find it at **Virtual Networks**
- → _Virtual Network Name_ → **Overview** → **JSON
- view** → **Resource ID** on [Azure
- Portal][azure-console].
-- **Virtual Network Address Spaces:** You can find it at **Virtual
- Networks** → _Virtual Network Name_ → **Overview**
- → **JSON view** → **properties**
- → **addressSpace** on [Azure Portal][azure-console].
-- **Tenant ID:** You can find it in **Azure Active Directory**
- → **Properties** → **Tenant ID** section of
- [Azure Portal][azure-console].
-- **Single-tenant Infrastructure Region:** VNet Peering requires Cube to be hosted
- in [single-tenant infrastructure][dedicated-infra]. Please specify what region
- the Cube Cloud single-tenant infrastructure should be hosted in.
-
-## Supported Regions
-
-We support all general-purpose regions. Cube Store is currently located only in
-`US Central` so pre-aggregations performance might depend on geographical
-proximity to it.
-
-[azure-console]: https://portal.azure.com
-[dedicated-infra]: /admin/deployment/infrastructure#dedicated-infrastructure
\ No newline at end of file
diff --git a/docs-mintlify/admin/deployment/vpc/gcp.mdx b/docs-mintlify/admin/deployment/vpc/gcp.mdx
deleted file mode 100644
index 0eb3aabdc7387..0000000000000
--- a/docs-mintlify/admin/deployment/vpc/gcp.mdx
+++ /dev/null
@@ -1,55 +0,0 @@
----
-title: Connecting with a VPC on GCP
-sidebarTitle: GCP
-description: Work with your Cube sales or customer success team to initiate this process.
----
-
-- VPC Peering requires Cube to be hosted in [single-tenant infrastructure][dedicated-infra].
-Let the Cube team know your Cube Cloud tenant name (e.g. example.cubecloud.dev) and what region
-the single-tenant infrastructure should be hosted in.
-For best performance, select one of the "Supported Regions" listed below.
-- Cube will provision the dedicated VPC and provide the following
-information you can use to create the peering request:
- - [Google Cloud Project ID][gcp-docs-projects]
- - Google Cloud VPC Network Name
-
-## Setup
-
-### VPC Peering
-
-After receiving the information above, create a [VPC peering
-request][gcp-docs-vpc-peering], either through the [GCP Web
-Console][gcp-console] or an infrastructure-as-code tool. To send a VPC peering
-request through the Google Cloud Console, follow [the instructions
-here][gcp-docs-create-vpc-peering], with the following amendments:
-
-- In Step 6, use the project name `XXXXX`, and the project ID and network name(s) provided by Cube.
-- In Step 7, ensure **Import custom routes** and **Export custom routes** are
- selected so that the necessary routes are created.
-
-## Supported Regions
-
-We support all general-purpose regions. Cube Store is currently located only in
-`US Central 1` and `Europe West 2` so pre-aggregations performance might depend
-on geographical proximity to it.
-
-## Notes
-
-### Cloud SQL
-
-Google Cloud SQL databases [can only be peered to a VPC within the same GCP
-project][gcp-docs-vpc-peering-restrictions]. To work around this limitation, we
-recommend that customers provision a micro VM in their Google Cloud account to
-run the [Cloud SQL Auth Proxy][gcp-cloudsql-auth-proxy].
-
-[gcp-cloudsql-auth-proxy]:
- https://cloud.google.com/sql/docs/mysql/connect-admin-proxy
-[gcp-docs-vpc-peering-restrictions]:
- https://cloud.google.com/vpc/docs/vpc-peering#restrictions
-[gcp-console]: https://console.cloud.google.com/
-[gcp-docs-create-vpc-peering]:
- https://cloud.google.com/vpc/docs/using-vpc-peering#creating_a_peering_configuration
-[gcp-docs-projects]:
- https://cloud.google.com/resource-manager/docs/creating-managing-projects#before_you_begin
-[gcp-docs-vpc-peering]: https://cloud.google.com/vpc/docs/vpc-peering
-[dedicated-infra]: /admin/deployment/infrastructure#dedicated-infrastructure
\ No newline at end of file
diff --git a/docs-mintlify/admin/deployment/vpc/index.mdx b/docs-mintlify/admin/deployment/vpc/index.mdx
deleted file mode 100644
index 74590bc6c98c7..0000000000000
--- a/docs-mintlify/admin/deployment/vpc/index.mdx
+++ /dev/null
@@ -1,34 +0,0 @@
----
-title: Single-tenant Infrastructure (VPC)
-description: Connect Cube Cloud to your private cloud network on AWS, GCP, or Azure for secure access to internal data sources.
----
-
-For improved stability and security, Cube Cloud supports connecting to one or
-more VPCs (virtual private clouds) in your AWS or GCP accounts, or VNets
-(virtual networks) in your Azure accounts.
-
-
-
-Available on the [Enterprise plan](https://cube.dev/pricing) with the
-[Single-tenant infrastructure][ref-dedicated-infra] add-on.
-
-
-
-VPC connection improves stability through single-tenant infrastructure for a
-deployment and improves security by preventing your database traffic from being
-routed through the public internet.
-
-
-
- Connect via VPC on AWS.
-
-
- Connect via VPC on GCP.
-
-
- Connect via VNet on Azure.
-
-
-
-
-[ref-dedicated-infra]: /admin/deployment/infrastructure#dedicated-infrastructure
\ No newline at end of file
diff --git a/docs-mintlify/docs.json b/docs-mintlify/docs.json
index ce4e970f9f1b1..6b02fd661d840 100644
--- a/docs-mintlify/docs.json
+++ b/docs-mintlify/docs.json
@@ -313,42 +313,38 @@
"admin/deployment/limits",
"admin/deployment/infrastructure",
{
- "group": "VPC",
- "root": "admin/deployment/vpc/index",
+ "group": "Dedicated Infrastructure",
+ "root": "admin/deployment/dedicated/index",
"pages": [
- "admin/deployment/vpc/gcp",
{
"group": "AWS",
- "root": "admin/deployment/vpc/aws/index",
+ "root": "admin/deployment/dedicated/aws/index",
"pages": [
- "admin/deployment/vpc/aws/private-link",
- "admin/deployment/vpc/aws/vpc-peering"
+ "admin/deployment/dedicated/aws/private-link",
+ "admin/deployment/dedicated/aws/vpc-peering",
+ "admin/deployment/dedicated/aws/private-api-connectivity",
+ "admin/deployment/dedicated/aws/byoc"
]
},
{
"group": "Azure",
- "root": "admin/deployment/vpc/azure/index",
+ "root": "admin/deployment/dedicated/azure/index",
"pages": [
- "admin/deployment/vpc/azure/private-link",
- "admin/deployment/vpc/azure/vpc-peering"
+ "admin/deployment/dedicated/azure/private-link",
+ "admin/deployment/dedicated/azure/vpc-peering",
+ "admin/deployment/dedicated/azure/byoc"
]
- }
- ]
- },
- {
- "group": "BYOC",
- "root": "admin/deployment/byoc/index",
- "pages": [
- "admin/deployment/byoc/azure",
+ },
{
- "group": "AWS",
- "root": "admin/deployment/byoc/aws/index",
+ "group": "GCP",
+ "root": "admin/deployment/dedicated/gcp/index",
"pages": [
- "admin/deployment/byoc/aws/deployment",
- "admin/deployment/byoc/aws/privatelink"
+ "admin/deployment/dedicated/gcp/private-service-connect",
+ "admin/deployment/dedicated/gcp/vpc-peering",
+ "admin/deployment/dedicated/gcp/byoc"
]
},
- "admin/deployment/byoc/gcp/deployment"
+ "admin/deployment/dedicated/pre-aggregation-storage"
]
}
]
@@ -738,6 +734,86 @@
{
"source": "/reference/mcp-server",
"destination": "/docs/integrations/mcp-server"
+ },
+ {
+ "source": "/admin/deployment/byoc",
+ "destination": "/admin/deployment/dedicated"
+ },
+ {
+ "source": "/admin/deployment/byoc/aws",
+ "destination": "/admin/deployment/dedicated/aws/byoc"
+ },
+ {
+ "source": "/admin/deployment/byoc/aws/deployment",
+ "destination": "/admin/deployment/dedicated/aws/byoc"
+ },
+ {
+ "source": "/admin/deployment/byoc/aws/privatelink",
+ "destination": "/admin/deployment/dedicated/aws/private-api-connectivity"
+ },
+ {
+ "source": "/admin/deployment/byoc/azure",
+ "destination": "/admin/deployment/dedicated/azure/byoc"
+ },
+ {
+ "source": "/admin/deployment/byoc/gcp/deployment",
+ "destination": "/admin/deployment/dedicated/gcp/byoc"
+ },
+ {
+ "source": "/admin/deployment/vpc",
+ "destination": "/admin/deployment/dedicated"
+ },
+ {
+ "source": "/admin/deployment/vpc/aws",
+ "destination": "/admin/deployment/dedicated/aws"
+ },
+ {
+ "source": "/admin/deployment/vpc/aws/private-link",
+ "destination": "/admin/deployment/dedicated/aws/private-link"
+ },
+ {
+ "source": "/admin/deployment/vpc/aws/vpc-peering",
+ "destination": "/admin/deployment/dedicated/aws/vpc-peering"
+ },
+ {
+ "source": "/admin/deployment/vpc/aws/private-api-connectivity",
+ "destination": "/admin/deployment/dedicated/aws/private-api-connectivity"
+ },
+ {
+ "source": "/admin/deployment/vpc/aws/byoc",
+ "destination": "/admin/deployment/dedicated/aws/byoc"
+ },
+ {
+ "source": "/admin/deployment/vpc/azure",
+ "destination": "/admin/deployment/dedicated/azure"
+ },
+ {
+ "source": "/admin/deployment/vpc/azure/private-link",
+ "destination": "/admin/deployment/dedicated/azure/private-link"
+ },
+ {
+ "source": "/admin/deployment/vpc/azure/vpc-peering",
+ "destination": "/admin/deployment/dedicated/azure/vpc-peering"
+ },
+ {
+ "source": "/admin/deployment/vpc/azure/byoc",
+ "destination": "/admin/deployment/dedicated/azure/byoc"
+ },
+ {
+ "source": "/admin/deployment/vpc/gcp",
+ "destination": "/admin/deployment/dedicated/gcp"
+ },
+ {
+ "source": "/admin/deployment/vpc/gcp/private-service-connect",
+ "destination": "/admin/deployment/dedicated/gcp/private-service-connect"
+ },
+ {
+ "source": "/admin/deployment/vpc/gcp/vpc-peering",
+ "destination": "/admin/deployment/dedicated/gcp/vpc-peering"
+ },
+ {
+ "source": "/admin/deployment/vpc/gcp/byoc",
+ "destination": "/admin/deployment/dedicated/gcp/byoc"
}
]
}
\ No newline at end of file
diff --git a/docs-mintlify/docs/data-modeling/dev-mode.mdx b/docs-mintlify/docs/data-modeling/dev-mode.mdx
index 5d5349a657046..66086e5fbad47 100644
--- a/docs-mintlify/docs/data-modeling/dev-mode.mdx
+++ b/docs-mintlify/docs/data-modeling/dev-mode.mdx
@@ -75,6 +75,19 @@ They will be shown on the Overview page:
Read more about the available endpoints on the [Environments][ref-environments-endpoints] page.
+## Behavior with CLI deployments
+
+Development mode is fully available on deployments that are configured to
+[deploy with CLI][ref-deploy-with-cli]: you can enter dev mode, switch
+branches, save and commit changes, and merge into the production branch from
+the Cube Cloud UI.
+
+However, on CLI deployments, **none of these actions trigger a production
+build or redeploy** — production only changes when somebody explicitly runs
+`cubejs-cli deploy` against the deployment, and the next deploy overwrites
+any changes made through the UI. See [Deploy with CLI →
+Development mode][ref-deploy-with-cli-dev-mode] for the full behavior.
+
## Limitations
The Development API has some limitations compared to Production, and it is
@@ -94,4 +107,6 @@ different Git branch of the same repository.
[ref-environments-dev]: /admin/deployment/environments#development-environments
-[ref-environments-endpoints]: /admin/deployment/environments#api-endpoints
\ No newline at end of file
+[ref-environments-endpoints]: /admin/deployment/environments#api-endpoints
+[ref-deploy-with-cli]: /admin/deployment/continuous-deployment#deploy-with-cli
+[ref-deploy-with-cli-dev-mode]: /admin/deployment/continuous-deployment#development-mode-with-cli-deployments
\ No newline at end of file
diff --git a/docs/app/globals.css b/docs/app/globals.css
index 3aa82f205b401..4d26935d4b55b 100644
--- a/docs/app/globals.css
+++ b/docs/app/globals.css
@@ -253,6 +253,13 @@ header.nextra-navbar nav > div.x\:max-md\:hidden:has(button) {
}
}
+/* Legacy-docs Banner - taller bar so the "visit new docs" link is more prominent */
+.nextra-banner > div {
+ padding-top: 32px !important;
+ padding-bottom: 32px !important;
+ font-size: 1.125rem !important;
+}
+
/* Purple Banner wrapper - animated reveal */
.pb-wrapper {
--purple-banner-font: var(--font-cera-pro), system-ui, -apple-system, sans-serif;
-The instructions to set up Cube Cloud as a Git remote are also available on the
-same screen:
+Click **Generate Git credentials** to obtain Git credentials. The instructions
+to set up Cube Cloud as a Git remote are also available on the same screen:
```bash
git config credential.helper store
@@ -27,9 +49,10 @@ git push cubecloud master
## Deploy with GitHub
-First, ensure your deployment is configured to deploy with Git. Then connect
-your GitHub repository to your deployment by clicking the **Connect to
-GitHub** button, and selecting your repository.
+You can connect a GitHub repository to your deployment by clicking the
+**Connect to GitHub** button on the **Build & Deploy** tab of the
+**Settings** screen and selecting your repository. This works with both the
+**Deploy with Git** and **Deploy with CLI** deploy modes.
-
+
+
+
+
+
+## Cube Region
+
+The endpoint services described here are scoped to a **Cube Region** — the
+unit of infrastructure that hosts one or more of your deployments. Each region
+has a stable identifier of the form `
+
+
+HTTP and SQL APIs are typically published under two separate hostnames
+(`http.cube.internal` and `sql.cube.internal` in the diagram above), since
+the HTTP endpoint sits behind your TLS-terminating proxy on port 443 while
+the SQL endpoint is accessed directly on port 5432.
+
+## Provisioning checklist
+
+1. **Request PrivateLink for your tenant.** Contact Cube and provide your
+ tenant name and the AWS account ID(s) that will create the VPC endpoints.
+2. **Receive endpoint service names.** Cube provisions one HTTP and one SQL
+ VPC Endpoint Service per region and shares the service names
+ (`com.amazonaws.vpce.