> ## Documentation Index
> Fetch the complete documentation index at: https://docs.pavoai.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Customer VPC (BYOC)
In a Customer VPC deployment, Pavo deploys and operates the **entire platform inside your own cloud account** — the application, the sandbox, and every supporting store (database, cache, queues, object storage) run in your AWS or GCP account, inside your VPC. The deployment is single-tenant, encrypted with your customer-managed keys, and has **no customer-data egress by default**: any egress is a choice you make, from your own account.
You keep the cloud boundary, billing relationship, network policy, and governance controls. Pavo handles provisioning, upgrades, service health, and operational response.
## Responsibility boundary
* **Pavo** provisions the platform into your account and operates upgrades, scaling, monitoring, and incident response for the deployment.
* **Your team** owns the cloud account, billing, governance, network policy, and audit, and provides the access path and cloud inputs Pavo needs to operate the deployment.
Pavo has no standing access to your environment. Support access is time-boxed, authorized, and audited.
## What you provide
* A dedicated cloud account or project (AWS or GCP) with billing enabled and an agreed deployment region.
* An IAM bootstrap step that creates the scoped access path for Pavo's provisioning automation and approved support events.
* Confirmation that required quotas and regional capacity are available in the selected region.
* Networking inputs: the VPC/subnets to deploy into (or approval to create them), DNS and TLS requirements, and private connectivity for reaching the Pavo UI (for example, VPN or peering).
* Read-only credentials for the sources you connect, and SSO configuration through your identity provider (OIDC).
## Architecture
```mermaid theme={null}
flowchart TB
subgraph acct["Your cloud account (AWS or GCP)"]
subgraph sources["Read-only sources — same account or peered"]
direction LR
repos["Code
repositories"]
wh["Data
warehouse"]
exp["Experimentation"]
dash["Dashboards"]
docs["Documentation"]
end
sources -->|"Read-only ingest — traffic stays inside your cloud"| app
subgraph vpc["Pavo deployment — single-tenant · your VPC · your CMEK keys"]
app["Pavo application
agents · knowledge pipeline · connectors · sandbox"]
obj["Object storage
S3 / GCS"]
pg["Postgres
RDS / Cloud SQL"]
rq["Redis + queues"]
inf["Model inference
Bedrock / Vertex — in account"]
idp["Zitadel
deployed in your VPC"]
kms["Your KMS + secrets"]
core["Elasticsearch · Temporal · Grafana
self-hosted (one-click) or managed from your account"]
app --- obj
app --- pg
app --- rq
app --- inf
app --- core
end
end
cp["Pavo control plane
(Omnistrate)"] -.->|"Provisioning & upgrades only — never customer data"| vpc
```
*Figure — Customer VPC: the entire platform, including supporting stores, deployed inside your own account.*
Provisioning and upgrades run through Pavo's control plane (Omnistrate), which orchestrates deployments only and **never touches customer data**. Upgrades are coordinated with your team.
## Core services: self-hosted or managed — your choice
The three core platform services can each run in one of two ways, chosen per service:
| Service | Self-hosted in your VPC | Managed cloud from your account |
| :---------------- | :---------------------------------------- | :---------------------------------------------------------------------- |
| **Elasticsearch** | One-click deployment by Pavo; zero egress | Managed Elasticsearch; egress from your own account, under your control |
| **Temporal** | One-click deployment by Pavo; zero egress | Temporal Cloud; egress from your own account, under your control |
| **Grafana** | One-click deployment by Pavo; zero egress | Grafana Cloud; metrics only — no customer data |
Amplitude and Brevo are **not present** in VPC deployments. Optional integrations (Modal, Langfuse, Parallel) are individually gated per instance and disabled unless you enable them.
## Model inference
By default, inference runs **in-account** through your cloud's native endpoints — AWS Bedrock or Vertex AI — so prompts and retrieved context never leave your cloud. External APIs (OpenAI, Anthropic) can be enabled instead, and run only under zero-data-retention agreements. No customer data is used for training in either configuration.
## Network and egress
* No customer-data egress by default; no public data endpoints.
* The sandbox runs agent-generated code behind a **default-deny egress allowlist proxy**. The allowlist is tiered — a minimum tier (open-source package registries needed for data/ML work), an opt-in tier enabled only with your approval, and customer-specific entries for your own cloud endpoints. The full allowlist is agreed per deployment.
* Access to the Pavo UI runs over private connectivity (for example, VPN or peering), integrated with your SSO.
## Hardened VPC — for regulated industries
For highly regulated environments — healthcare, insurance, financial services — Pavo supports a stricter profile of the VPC deployment:
* **Everything self-hosted.** Elasticsearch, Temporal, and Grafana are deployed inside your VPC; no managed cloud services are used.
* **No third-party integrations.** Optional integrations are not deployed at all, and only the bare-minimum sub-processors remain.
* **Inference in-account only.** Bedrock or Vertex AI; no external model APIs.
* **No customer data leaves your VPC.** The egress allowlist is reduced to the agreed minimum and can be tightened further per deployment.
Hardened VPC deployments go through a deployment review so the component set, allowlist, and operating model are agreed explicitly before provisioning. [Contact us](mailto:srijan@pavoai.com) to scope one.
## Next steps
Compare Pavo Cloud, Customer VPC, and Hardened VPC side by side.
Every third party, the data it processes, and how it runs per deployment.