Bring Your Own Cloud (BYOC)

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 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). Cluster metadata lives in FoundationDB, which runs inside your Kubernetes cluster, so there's no managed database to operate.
• 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.

In the standard Pinecone service, customer-managed encryption keys (CMEK) are how you connect Pinecone-managed storage to your AWS KMS keys through the Pinecone console.

In BYOC, that console CMEK flow doesn't apply. Your vectors and index data are stored in your cloud account (for example, object storage and block storage), so you apply your cloud provider’s KMS to those resources using the same native controls you use for other workloads (key policies, rotation, and compliance programs such as PCI or ISO 27001). When you deploy with pulumi-pinecone-byoc, you can supply your KMS key where the template supports it. For the current options, see the pulumi-pinecone-byoc README.

Before deploying BYOC, ensure you have the following tools installed on your local machine:

You also need:

• The CLI for your cloud provider:
  • AWS: AWS CLI v2
  • GCP: gcloud CLI
  • Azure: Azure CLI
• A cloud account with admin-level permissions:
  • AWS: AdministratorAccess. PowerUserAccess isn't sufficient because BYOC creates IAM roles and policies.
  • GCP: roles/owner. roles/editor isn't sufficient because BYOC creates IAM service accounts and bindings.
  • Azure: Owner on the subscription. Contributor isn't 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)

To deploy BYOC, follow these steps:

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

Control plane operations like creating, listing, and deleting indexes work via the standard Pinecone API regardless of your network access mode.

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"
         }'

from pinecone import Pinecone
from pinecone.db_control.models import ByocSpec

pc = Pinecone(api_key="YOUR_API_KEY")

pc.db.index.create(
    name="example-byoc-index",
    dimension=1536,
    metric="cosine",
    vector_type="dense",
    spec=ByocSpec(
        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 like querying, upserting, and fetching vectors depend on your network access mode.

https://my-index-abc123.svc.us-east-1.byoc.pinecone.io

https://my-index-abc123.svc.private.us-east-1.byoc.pinecone.io

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.

You can monitor your BYOC deployment through multiple channels:

kubectl get cluster-operations

To destroy your BYOC deployment:

# 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: S3 buckets
• GCP: GCS buckets
• Azure: storage accounts

Common issues and how to resolve them:

pulumi refresh  # Sync state with actual resources
pulumi up       # Retry deployment

aws sts get-caller-identity

gcloud auth list
gcloud config get-value project

az account show

For additional help, see the GitHub Issues for the deployment repository.

Some features available in the standard Pinecone service aren't 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.
• On-demand indexes. BYOC supports dedicated read node indexes only.

To monitor with Prometheus, you must configure Prometheus within your VPC.

Answers to common questions about BYOC:

Your Pinecone bill for a BYOC environment has two parts: a flat platform fee and a rate for each dedicated read node you run. Separately, you pay your cloud provider directly for the underlying infrastructure (Kubernetes nodes, object storage, block storage, networking, etc.).

Pinecone bill = platform fee + (node rate × number of nodes)

If an environment runs both b1 and t1 nodes, calculate the node cost for each type and add the results.

Unlike dedicated read nodes in the standard service, BYOC has no separate Pinecone charges for storage or writes. That data lives in your own cloud account, so you pay your cloud provider for it instead of Pinecone.

Example: An environment with one index using two shards and two replicas runs four b1 nodes, so its monthly bill is the platform fee plus four times the b1 node rate, plus what you pay your cloud provider.

The Pinecone BYOC agent running in your cluster measures node usage, periodically reporting which nodes are provisioned. Billing follows the agent heartbeat connection to Pinecone's control plane:

• When Pinecone receives heartbeats, you're billed for the nodes 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.