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

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: 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.

​

Next steps