Skip to main content
BYOC is in public preview on AWS, GCP, and Azure.
Pinecone BYOC (bring your own cloud) is designed for organizations with strict requirements around data sovereignty, network isolation, and data residency. With BYOC, you deploy the Pinecone data plane in your own cloud account (AWS, GCP, or Azure), and you get the benefits of a managed service — upgrades, scaling, and maintenance — without giving up control of your data or infrastructure. Pinecone never has direct access to your cloud account. Your vectors, metadata, and queries never leave your environment, and no inbound network access is required. An agent in your cluster pulls operations from Pinecone and executes them locally. BYOC architecture diagram BYOC architecture diagram BYOC uses a split architecture:
  • The data plane runs entirely in your cloud account within a dedicated VPC, storing and processing your vectors, executing queries, and managing index data in object storage (S3 on AWS, GCS on GCP, or Azure Blob Storage on Azure).
  • The control plane is managed by Pinecone globally and handles index lifecycle management, authentication, billing, and user management, but never stores or processes your vectors.
For maintenance, the agent authenticates with Pinecone’s control plane, pulls pending operations (upgrades, scaling, etc.), and executes them locally. All operations are stored as Kubernetes CRDs, providing a complete audit trail. Only operational metrics (CPU, memory, latency) and traces are transmitted to Pinecone for monitoring; customer data is filtered out before transmission.

​
Prerequisites

Before deploying BYOC, ensure you have the following tools installed on your local machine:
ToolPurposeInstall
Python 3.12+Runtimepython.org
uvPackage managerdocs.astral.sh/uv
PulumiInfrastructure-as-codepulumi.com/docs/install
kubectlCluster accesskubernetes.io
You also need:
  • The CLI for your cloud provider:
  • A cloud account with admin-level permissions:
    • AWS: AdministratorAccess. PowerUserAccess is not sufficient because BYOC creates IAM roles and policies.
    • GCP: roles/owner. roles/editor is not sufficient because BYOC creates IAM service accounts and bindings.
    • Azure: Owner on the subscription. Contributor is not sufficient because BYOC creates managed identities and role assignments.
  • Sufficient cloud quota for the resources (the setup wizard validates this)
  • A Pinecone API key from the Pinecone console.
  • A Pinecone Enterprise plan (required for BYOC access)
If you install any new tools, open a new terminal session before proceeding so that your shell picks up the updated PATH and environment.

​
Deploy BYOC

To deploy BYOC, follow these steps:
1

Run the setup wizard

Run the bootstrap script from the BYOC deployment repository (github.com/pinecone-io/pulumi-pinecone-byoc) to start the interactive setup wizard:
curl -fsSL https://raw.githubusercontent.com/pinecone-io/pulumi-pinecone-byoc/main/bootstrap.sh | bash
You can also pre-select your cloud provider:
# AWS
curl -fsSL https://raw.githubusercontent.com/pinecone-io/pulumi-pinecone-byoc/main/bootstrap.sh | bash -s -- --cloud aws

# GCP
curl -fsSL https://raw.githubusercontent.com/pinecone-io/pulumi-pinecone-byoc/main/bootstrap.sh | bash -s -- --cloud gcp

# Azure
curl -fsSL https://raw.githubusercontent.com/pinecone-io/pulumi-pinecone-byoc/main/bootstrap.sh | bash -s -- --cloud azure
The script selects your cloud provider, checks that required tools are installed, verifies your cloud credentials, then launches an interactive wizard that collects your configuration choices, validates your quotas, and generates a Pulumi project. No cloud resources are created during this step.
The wizard prompts you for the following:
PromptDescriptionDefault
Cloud providerSelect AWS, GCP, or Azure (skipped if pre-selected via --cloud).-
Pinecone API keyYour API key from the Pinecone console (or uses PINECONE_API_KEY env var).-
Cloud credentialsValidates credentials and displays your account/project/subscription ID.-
GCP project ID(GCP only) Your GCP project ID.Detected from gcloud
Azure subscription ID(Azure only) Your Azure subscription ID.Detected from az account show
RegionRegion for deployment.us-east-1 (AWS) / us-central1 (GCP) / eastus (Azure)
Availability zonesZones for high availability. Wizard fetches available options.First two zones
Custom AMI(AWS only) Custom AMI ID for EKS nodes. Leave blank for the default AWS AMI.None
VPC CIDR blockIP range for your VPC/VNet. Choose a range that doesn’t conflict with existing networks.10.0.0.0/16 (AWS/Azure) / 10.112.0.0/12 (GCP)
Deletion protectionProtect databases and storage from accidental deletion.Enabled
Network accessPublic access (connect from anywhere) or private only (requires PrivateLink on AWS, Private Service Connect on GCP, or Private Link on Azure).Public enabled
Resource tags/labelsCustom tags (AWS/Azure) or labels (GCP) for cost tracking (e.g., team=platform,env=prod).None
Preflight checksValidates cloud quotas. If checks fail, request quota increases before proceeding.-
Project nameName for your deployment.pinecone-byoc
Pulumi backendWhere to store state: local (~/.pulumi with passphrase) or Pulumi Cloud.Local
After completing the wizard, a Pulumi project is generated in your project directory.
The wizard creates a Pulumi.<stack>.yaml file with configurable options. The options vary by cloud provider:
OptionDescriptionDefault
pinecone-versionPinecone release version-
regionAWS regionus-east-1
availability-zonesAvailability zones for high availability["us-east-1a", "us-east-1b"]
vpc-cidrVPC IP range10.0.0.0/16
deletion-protectionProtect RDS and S3 from accidental deletiontrue
public-access-enabledEnable public endpoint (false = PrivateLink only)true
custom-ami-idCustom AMI ID for EKS nodesDefault AWS AMI
tagsCustom tags for all AWS resources{}
To change configuration after initial setup, edit Pulumi.<stack>.yaml and run pulumi up.
For advanced users who want to integrate BYOC into existing Pulumi infrastructure, the pulumi-pinecone-byoc package is available on PyPI. Install with cloud-specific dependencies:
# For AWS
uv add 'pulumi-pinecone-byoc[aws]'

# For GCP
uv add 'pulumi-pinecone-byoc[gcp]'

# For Azure
uv add 'pulumi-pinecone-byoc[azure]'
Import the cluster class for your cloud provider:
# AWS
from pulumi_pinecone_byoc.aws import PineconeAWSCluster, PineconeAWSClusterArgs

# GCP
from pulumi_pinecone_byoc.gcp import PineconeGCPCluster, PineconeGCPClusterArgs

# Azure
from pulumi_pinecone_byoc.azure import PineconeAzureCluster, PineconeAzureClusterArgs
See the repository README for full usage examples.
2

Deploy the infrastructure

Deploy the generated Pulumi project to create your cloud resources:
cd pinecone-byoc
pulumi up
Pulumi shows a preview of all resources to be created. Confirm to proceed. Provisioning takes approximately 25-30 minutes.When complete, the output displays:
  • Your BYOC environment name (used when creating indexes).
  • The kubectl command to configure cluster access.
The deployment creates the following resources in your cloud account:
ComponentAWSGCPAzure
VPC / NetworkingVPC, public and private subnets, NAT gateways, internet gatewayVPC network, subnets, Cloud NAT, Cloud RouterVNet, subnets, NAT gateway
KubernetesEKS cluster with managed node groupsGKE cluster with node poolsAKS cluster with agent pools
Object storageS3 buckets (data, WAL, backups)GCS buckets (data, WAL, backups)Blob Storage containers (data, WAL, backups)
DatabaseAurora PostgreSQL (RDS)AlloyDBPostgreSQL Flexible Server
Load balancingNetwork Load BalancerInternal load balancer with Private Service ConnectInternal load balancer with Private Link Service
DNSRoute 53 hosted zoneCloud DNS managed zoneAzure DNS zone
TLS certificatesAWS Certificate Managercert-managercert-manager
IAMIAM roles and policiesService accounts and Workload IdentityManaged identities and Workload Identity
The initial deployment provisions 3 Kubernetes nodes. After setup, the cluster autoscales based on the services Pinecone deploys and your workload.
3

Verify the deployment

Configure kubectl to connect to your cluster using the command from the deployment output:
aws eks update-kubeconfig --region <region> --name <cluster-name>
The above command configures your local kubectl tool to communicate with your Kubernetes cluster. You’ll use cluster access for administrative tasks like viewing operations and troubleshooting. Creating indexes and reading/writing vectors still use the standard Pinecone API.Verify all components are running:
# Check that all pods are running
kubectl get pods -A | grep -E "(pinecone|pc-)"
All pods should show Running status. If any pods are in Pending or CrashLoopBackOff, check the Troubleshooting section.You can also verify the cluster operations CRD is installed:
kubectl get cluster-operations
It’s normal to see “No resources found” on a fresh deployment. Operations appear here as Pinecone performs upgrades and other management tasks.

​
Use BYOC

Once your BYOC environment is deployed, you can create indexes and read/write data using the standard Pinecone API.

​
Control plane operations

Control plane operations like creating, listing, and deleting indexes work via the standard Pinecone API regardless of your network access mode.
BYOC supports dedicated read nodes indexes, but not on-demand indexes.
Use the environment name from the deployment output to create indexes in your BYOC environment. BYOC supports dedicated read nodes indexes only.
PINECONE_API_KEY="YOUR_API_KEY"

curl -X POST "https://api.pinecone.io/indexes" \
     -H "Accept: application/json" \
     -H "Content-Type: application/json" \
     -H "Api-Key: $PINECONE_API_KEY" \
     -H "X-Pinecone-Api-Version: 2025-10" \
     -d '{
           "name": "example-byoc-index",
           "dimension": 1536,
           "metric": "cosine",
           "vector_type": "dense",
           "spec": {
             "byoc": {
               "environment": "aws-us-east-1-26bf.byoc",
               "read_capacity": {
                 "mode": "Dedicated",
                 "dedicated": {
                   "node_type": "b1",
                   "scaling": "Manual",
                   "manual": {
                     "shards": 1,
                     "replicas": 1
                   }
                 }
               }
             }
           },
           "deletion_protection": "disabled"
         }'

​
Data plane operations

Data plane operations like querying, upserting, and fetching vectors depend on your network access mode.
BYOC does not support reading and writing data from the index browser in the Pinecone console.
Use the host URL from the Pinecone console or the Describe an index API response. For example:
https://my-index-abc123.svc.us-east-1.byoc.pinecone.io
Connect from anywhere using the standard Pinecone SDK or API.
With public access disabled, you can only connect from within your VPC via private connectivity. You cannot use the Pinecone console for data plane operations (query, upsert, fetch), though control plane operations (create, delete, list indexes) still work.After deployment, the Pulumi stack outputs include the service name needed to create a private endpoint for your cloud provider. Use this service name to set up private connectivity:
1

Create a VPC endpoint

Follow the instructions in the AWS documentation to create a VPC endpoint for connecting to your indexes via AWS PrivateLink.For Resource configurations, use the VPC endpoint service name from the Pulumi stack outputs.
2

Select network settings

For Network settings, select the VPC for your BYOC deployment.
3

Enable DNS name

In Additional settings, select Enable DNS name to allow you to access your indexes using a DNS name.
Once configured, use the private_host URL from the Pinecone console or the Describe an index API response. For example:
https://my-index-abc123.svc.private.us-east-1.byoc.pinecone.io

​
Manage BYOC

​
Operations and upgrades

Pinecone uses a pull-based model for cluster operations:
  1. When upgrades, scaling, or maintenance are needed, Pinecone queues operations in the control plane.
  2. An agent running in your cluster (deployed automatically during setup) continuously pulls pending operations.
  3. Operations execute locally within your cluster.
  4. Status is reported back to Pinecone for monitoring.
This model ensures Pinecone never needs direct access to your infrastructure. All operations are stored as Kubernetes CRDs, providing a complete audit trail.

​
Monitoring

You can monitor your BYOC deployment through multiple channels:
View index metrics (read/write units, latency, storage) in the Pinecone console. Control plane operations and metrics work regardless of your network access mode.
To use Prometheus, configure your monitoring tool within your VPC to scrape metrics from the cluster. Your Prometheus instance must have network access to the BYOC VPC. The deployment output includes the metrics endpoint URL and port for configuration.
All cluster operations are persisted as Kubernetes CRDs for compliance and auditing:
kubectl get cluster-operations

​
Cleanup

To destroy your BYOC deployment:
Delete all BYOC indexes before destroying the cluster. Indexes cannot be properly terminated if the cluster is destroyed first.
# 1. Delete all indexes via Pinecone API or console
# 2. Then destroy the infrastructure
pulumi destroy
If deletion_protection is enabled (the default), you must either disable it in Pulumi.<stack>.yaml and run pulumi up, or manually delete protected resources via the cloud console before running pulumi destroy:
  • AWS: RDS instances and S3 buckets
  • GCP: AlloyDB instances and GCS buckets
  • Azure: PostgreSQL Flexible Server instances and Storage accounts

​
Reference

​
Troubleshooting

Common issues and how to resolve them:
The setup wizard validates cloud quotas before deployment. If checks fail:
CheckResolution
VPC / network quotaRequest a limit increase via your cloud provider’s quota console
Kubernetes cluster quotaRequest an EKS, GKE, or AKS cluster limit increase
IP address quotaRelease unused IPs or request a limit increase
Instance / machine type availabilityVerify the required type is available in your region
vCPU quota (Azure)Request a “Total Regional vCPUs” increase via the Azure Portal (minimum 8 required)
VM SKU availability (Azure)Verify Standard_D4s_v5 and L-series SKUs are available in your region
Resource providers (Azure)Register required providers: Microsoft.Compute, Microsoft.ContainerService, Microsoft.DBforPostgreSQL, Microsoft.Storage, Microsoft.Network, Microsoft.KeyVault, Microsoft.ManagedIdentity, Microsoft.Authorization
Required APIs (GCP only)Enable Compute Engine, GKE, AlloyDB, Cloud Storage, and Cloud DNS
If pulumi up fails partway through:
pulumi refresh  # Sync state with actual resources
pulumi up       # Retry deployment
Ensure your cloud credentials match the account where the cluster is deployed:
aws sts get-caller-identity
If you destroyed the cluster before deleting indexes, indexes may be stuck in a “terminating” state. Contact Pinecone support for assistance.
For additional help, see the GitHub Issues for the deployment repository.

​
Limitations

Some features available in the standard Pinecone service are not yet supported or have constraints in BYOC:
  • Each organization can have up to 2 BYOC environments. To request an increase, contact Pinecone support.
  • Integrated embedding and inference, which relies on models hosted by Pinecone outside your cloud account.
  • Reading and writing data from the index browser in the Pinecone console.
  • Pinecone CLI data plane operations (queries, upserts, fetches). Control plane operations (create, list, delete indexes) work as expected.
  • Imports from private cloud storage buckets, unless the bucket is in the same cloud account as your BYOC deployment.
  • Customer-managed encryption keys (CMEK).
  • On-demand indexes (initial release supports DRN indexes only).
To monitor with Prometheus, you must configure Prometheus within your VPC.

​
FAQs

Answers to common questions about BYOC:
No. BYOC is designed so Pinecone never needs direct access to your infrastructure. Specifically:
  • Pinecone does not need SSH, VPN, or inbound access to your cluster.
  • You control cloud account boundaries, networking, and Kubernetes access.
  • Operational changes run through explicit, software-mediated workflows.
  • You don’t open inbound firewall ports for Pinecone operations.
Operations are executed via a pull-based model where your cluster retrieves and runs operations locally. All communication is outbound from your cluster.
Does not leave your cloud account:
  • Vectors, metadata, and index contents
  • Query and upsert payloads
  • Customer data
Can leave your cloud account:
  • Operational metrics and traces (for example, CPU, memory, latency)
  • Cluster health and operation status
Customer data is filtered out before transmission and never leaves your cloud account.
In the standard service, Pinecone manages all cloud resources and includes their cost in the service fee. In BYOC, you provision and pay for cloud resources directly through your own cloud account, providing greater control, data sovereignty, and access to available cloud credits or discounts.
You use API keys from the Pinecone console, just like with the standard Pinecone service. Authentication is handled by Pinecone’s global control plane, and your data plane caches API keys locally. This means you manage users and API keys through the console as usual.
Data is stored and processed exclusively within your cloud account, with encryption at rest and in transit. Communication between the data plane and control plane is encrypted using TLS. Private connectivity (AWS PrivateLink, GCP Private Service Connect, or Azure Private Link) can be used for additional network isolation.
BYOC is available on AWS, GCP, and Azure.
Indexes cannot be properly terminated if the cluster is destroyed first. Always delete indexes via the Pinecone API or console before running pulumi destroy.
Deploying a BYOC environment creates an internal project named __SLI__ in your organization. This is used by Pinecone to enforce SLAs for your BYOC environment. Do not modify or delete this project.

​
Pricing

BYOC pricing is based on provisioned resources (compute and storage) in your deployment, metered over time. Usage is measured by the Pinecone BYOC agent running in your cluster, which periodically reports the resources that are provisioned. What you pay:
  • Pinecone fees: Based on provisioned compute (vCPU and RAM) and storage (NVMe) resources
  • Cloud provider fees: You pay your cloud provider directly for the underlying infrastructure (Kubernetes nodes, object storage, databases, networking, etc.)
Billing follows the agent heartbeat connection to Pinecone’s control plane:
  • When heartbeats are received, you are billed for the provisioned compute and storage the agent reports, even if the cluster is unhealthy.
  • Short heartbeat interruptions (under 60 minutes) are treated as a grace period.
  • If heartbeats are missing for more than 60 minutes, billing stops and the deployment is marked disconnected.
Billing is based on provisioned resources, not query volume. Resources that are running in your cluster are billed whether they are idle, actively processing queries, or experiencing errors.