# Create a BYOC Cluster on GCP

> For the complete documentation index, see [llms.txt](https://docs.redpanda.com/llms.txt). Component-specific: [cloud-data-platform-full.txt](https://docs.redpanda.com/cloud-data-platform-full.txt)

---
title: Create a BYOC Cluster on GCP
latest-operator-version: v26.1.4
latest-console-tag: v3.7.3
latest-connect-version: 4.93.0
latest-redpanda-tag: v26.1.9
docname: cluster-types/byoc/gcp/create-byoc-cluster-gcp
page-component-name: cloud-data-platform
page-version: master
page-component-version: master
page-component-title: Cloud
page-relative-src-path: cluster-types/byoc/gcp/create-byoc-cluster-gcp.adoc
page-edit-url: https://github.com/redpanda-data/cloud-docs/edit/main/modules/get-started/pages/cluster-types/byoc/gcp/create-byoc-cluster-gcp.adoc
description: Use the Redpanda Cloud UI to create a BYOC cluster on GCP.
page-git-created-date: "2024-10-24"
page-git-modified-date: "2026-04-21"
---

<!-- Source: https://docs.redpanda.com/cloud-data-platform/get-started/cluster-types/byoc/gcp/create-byoc-cluster-gcp.md -->

To create a Redpanda cluster in your virtual private cloud (VPC), follow the instructions in the Redpanda Cloud UI. The UI contains the parameters necessary to successfully run `rpk cloud byoc apply`. See also: [BYOC architecture](https://docs.redpanda.com/cloud-data-platform/get-started/byoc-arch/).

> 📝 **NOTE**
>
> With standard BYOC clusters, Redpanda manages security policies and resources for your VPC, including subnetworks, service accounts, IAM roles, firewall rules, and storage buckets. For the highest level of security, you can manage these resources yourself with a [BYOVPC cluster on GCP](https://docs.redpanda.com/cloud-data-platform/get-started/cluster-types/byoc/gcp/vpc-byo-gcp/).

If your clients need to connect from different GCP regions than where your cluster will be deployed, you must enable global access during cluster creation using the Cloud API. To create a BYOC cluster with global access enabled, see [Enable Global Access](https://docs.redpanda.com/cloud-data-platform/networking/byoc/gcp/enable-global-access/).

## [](#prerequisites)Prerequisites

Before you deploy a BYOC cluster on GCP, verify the following prerequisites:

-   A minimum version of Redpanda `rpk` v24.1. See [Install or Update rpk](https://docs.redpanda.com/cloud-data-platform/manage/rpk/rpk-install/).

-   Assign the `roles/editor` role (or higher, such as `roles/owner`) to the GCP user or service account that runs the bootstrap on the target GCP project. This grants the permissions needed to create VPC networks, GKE clusters, service accounts, and other infrastructure during the initial bootstrap. These bootstrap permissions are separate from the [agent permissions](https://docs.redpanda.com/cloud-data-platform/security/authorization/cloud-iam-policies-gcp/) that Redpanda assigns after bootstrap.

-   The user has the [Google Cloud CLI](https://cloud.google.com/sdk/docs/install) installed and authenticated, with the target project selected. To verify, run:

    ```bash
    gcloud auth list
    gcloud config get-value project
    ```


### [](#gcp-quotas)GCP quotas

Ensure at least three nodes of headroom in the relevant GCP quotas in the same region as your cluster. During maintenance, Redpanda may temporarily create extra nodes. Quotas such as vCPUs per VM family (for example, N2D) and Local SSD total per VM family (quota key: `LOCAL_SSD_TOTAL_GB_PER_VM_FAMILY`) are listed for each tier on the **Create BYOC cluster** page in the Redpanda Cloud UI.

Headroom formulas:

-   vCPU spare = `3 x (vCPUs per node)`

-   Local SSD spare (GB) = `3 x (Storage size per node in GB)`


For example, with per-node storage **1500 GB** (4 × 375 GB Local SSD) and machine type **n2d-standard-4** (4 vCPUs), keep **4500 GB** Local SSD and **12 vCPUs** of spare quota.

## [](#create-a-byoc-cluster)Create a BYOC cluster

1.  Log in to [Redpanda Cloud](https://cloud.redpanda.com).

2.  On the Clusters page, click **Create cluster**, then click **Create** for BYOC.

    Enter a cluster name, then select the resource group, provider (GCP), [region, tier](https://docs.redpanda.com/cloud-data-platform/reference/tiers/byoc-tiers/), availability, and Redpanda version.

    > 📝 **NOTE**
    >
    > -   If you plan to create a private network in your own VPC, select the region where your VPC is located.
    >
    > -   Three availability zones provide two backups in case one availability zone goes down.

    Optionally, click **Advanced settings** to specify up to five key-value custom GCP labels. If a label key starts with `gcp.network-tag.<tag>`, then the agent interprets it as a request to apply the `<tag>` [network tag](https://cloud.google.com/vpc/docs/add-remove-network-tags) to GCE instances in the cluster. Use labels for organization/metadata; use network tags to target firewall rules and routes. After the cluster is created, labels are applied to applicable GCP resources (for example, instances and disks), and network tags are applied to instances. For more information, see the [GCP documentation](https://cloud.google.com/compute/docs/labeling-resources). After the cluster is created, you can [specify more labels with the Cloud API](#manage-custom-resource-labels-and-network-tags).

3.  Click **Next**.

4.  On the Network page, select the connection type: either public or private. For BYOC clusters, private is best-practice.

    -   Your network name is used to identify this network.

    -   For a [CIDR range](https://docs.redpanda.com/cloud-data-platform/networking/cidr-ranges/), choose one that does not overlap with your existing VPCs or your Redpanda network.

    -   Clusters with private networking include a setting for API Gateway network access. Public access exposes endpoints for Redpanda Console, the Data Plane API, but they remain protected by your authentication and authorization controls. Private access restricts endpoint access to your VPC only.

        > 📝 **NOTE**
        >
        > After the cluster is created, you can change the API Gateway access on the Dataplane settings page. If you change from public to private access, users without VPN access to the Redpanda VPC will lose access to these services.


5.  Click **Next**.

6.  On the Deploy page, follow the steps to log in to Redpanda Cloud and deploy the agent.

    As part of agent deployment, Redpanda assigns the permissions required to run the agent. For details about these permissions, see [GCP IAM permissions](https://docs.redpanda.com/cloud-data-platform/security/authorization/cloud-iam-policies-gcp/).


> 📝 **NOTE**
>
> Redpanda Cloud does not support customer access or modifications to any of the internal data plane resources. This restriction allows Redpanda Data to manage all configuration changes internally to ensure a 99.99% service level agreement (SLA) for BYOC clusters.

## [](#manage-custom-resource-labels-and-network-tags)Manage custom resource labels and network tags

Your organization might require custom resource labels and network tags for cost allocation, audit compliance, or governance policies. After cluster creation, you can manage this with the [Cloud Control Plane API](https://docs.redpanda.com/cloud-data-platform/manage/api/cloud-byoc-controlplane-api/). The Control Plane API allows up to 16 custom resource labels and network tags in GCP.

Make sure you have:

-   The cluster ID. You can find this in the Redpanda Cloud UI, in the **Details** section of the cluster overview.

-   A valid bearer token for the Cloud Control Plane API. For details, see [Authenticate to the API](https://docs.redpanda.com/api/doc/cloud-controlplane/authentication).


> ❗ **IMPORTANT**
>
> To unlock this feature for your account, contact [Redpanda Support](https://support.redpanda.com/hc/en-us/requests/new).

1.  To refresh agent permissions so the Redpanda agent can update labels and network tags, run:

    ```bash
    export CLUSTER_ID="<cluster-id>"
    export PROJECT_ID="<gcp-project-id>"

    rpk cloud byoc gcp apply --redpanda-id="$CLUSTER_ID" --project-id="$PROJECT_ID"
    ```

    This step is required because label/tag management requires additional IAM permissions that may not have been granted during initial cluster creation:

    -   `compute.disks.get`

    -   `compute.disks.list`

    -   `compute.disks.setLabels`

    -   `compute.instances.setLabels`


2.  To update labels and network tags, invoke the Cloud API.

    First, set your authentication token:

    ```bash
    export AUTH_TOKEN="<your-bearer-token>"
    ```

    The `PATCH` call sets the labels and network tags specified under `"cloud_provider_tags"`. It replaces the existing labels and tags with the specified labels and tags. Include all desired labels and tags in the request. To remove a single entry, omit it from the map you send.

    ```bash
    cluster_patch_body=$(cat <<'JSON'
    {
      "cloud_provider_tags": {
        "environment": "production",
        "cost-center": "engineering",
        "gcp.network-tag.web-servers": "true",
        "gcp.network-tag.database-access": "true"
      }
    }
    JSON
    )

    curl -X PATCH "https://api.redpanda.com/v1/clusters/$CLUSTER_ID" \
       -H "Content-Type: application/json" \
       -H "Authorization: Bearer $AUTH_TOKEN" \
       -d "$cluster_patch_body"
    ```

    To remove all labels and network tags, send an empty `cloud_provider_tags` object:

    ```bash
    cluster_patch_body='{"cloud_provider_tags": {}}'

    curl -X PATCH "https://api.redpanda.com/v1/clusters/$CLUSTER_ID" \
      -H "Content-Type: application/json" \
      -H "Authorization: Bearer $AUTH_TOKEN" \
      -d "$cluster_patch_body"
    ```


## [](#next-steps)Next steps

[Configure private networking](https://docs.redpanda.com/cloud-data-platform/networking/byoc/gcp/)