Deployment · Architecture · Operations

On-premise and private-cloud customer data platform (CDP) deployment

Choose where to run your customer data platform (CDP): your datacenter, your cloud account or both. Assign an owner for hosting, access, backups and updates. Test the setup before using real customer data.

Deployment design · single-tenant · customer-owned boundary
Customer Deployment Boundary

Single-tenant · Customer cloud / on-premise / sovereign

Isolated

PrivyCDP Core

Identity Resolution

AI Decision Layer

Event Bus

Vector Store

Audit Ledger

Outside boundary — blocked egress
AdTech CloudMarTech SaaSPublic Analytics

Section 01 · Deployment Models

Four Deployment Models

Each setup serves one customer in their own systems. Scope hosting, hardware and operating work separately from the software licence.

On-PremiseAvailable

On-Premise Deployment

Run the software in your own datacenter. Your team or a chosen partner operates it. Ask about the requirements for an isolated network.

Customer-owned hardware
Private CloudAvailable

Private Cloud (VPC)

Run the software in your AWS, Azure, GCP or OCI account. Check the network paths, access rules and any outbound requests.

AWS · Azure · GCP · OCI
HybridAvailable

Hybrid Deployment

Keep core records in your datacenter and selected services in your cloud account. Test data movement and timing across regions.

On-prem core · Cloud edge
Sovereign / Air-GappedRestricted Access

Sovereign / Air-Gapped

Assess a sovereign cloud or an isolated network. Agree how updates reach the system and test the rules for your workload.

Offline update channel

Section 02 · Architecture Overview

Three-Layer Reference Architecture

Plan three parts of the setup. Assign capacity, access and audit checks to each one. Your team owns the systems that run them.

Edge

Ingestion · activation · external integration interface

EDGE-01

Event Collector

SDK / HTTP / Kafka

EDGE-02

Activation Gateway

Reverse-ETL / Webhook

EDGE-03

Integration Bus

MCP-ready connectors

Core

Identity · decisioning · AI inference · orchestration

CORE-01

Identity Resolution

Deterministic + probabilistic

CORE-02

Decision Engine

Real-time rules + ML scoring

CORE-03

AI Decision Layer

Private LLM · MCP

CORE-04

Journey Orchestrator

Workflow runtime

CORE-05

Segmentation Service

Streaming + batch

CORE-06

Policy Engine

Consent · residency · RBAC

Storage

Persistence · audit chain · vector indices

STORE-01

Profile Graph

Customer-owned DB

STORE-02

Event Log

Immutable, append-only

STORE-03

Vector Store

Embeddings · features

STORE-04

Audit Ledger

Hash-chained

Section 03 · DevOps & Update Model

Five-Phase Update Pipeline

Updates are delivered as versioned, signed artifacts. The customer's DevOps team controls the promotion of every release through a deterministic five-phase pipeline. There is no forced auto-update and no shared SaaS rollout.

  1. 01

    Stage

    Versioned release artifact is pulled into the customer's staging environment. Signed, hash-verified, and reproducible.

  2. 02

    Canary

    Release is exposed to a controlled traffic slice inside the customer boundary. Telemetry is observed locally — no telemetry egress to PrivyCDP.

  3. 03

    Audit

    Customer security and compliance teams review change manifests, dependency diff, and policy impact reports before promotion.

  4. 04

    Promote

    Promotion to production is executed by the customer's DevOps team on the customer's schedule. Roll-forward and roll-back are deterministic.

  5. 05

    Verify

    Post-deployment verification runs against the customer-owned audit ledger. Version, signature, and policy state are recorded immutably.

Section 04 · Support Boundaries

Clear Ownership of Every Operational Interface

PrivyCDP, the customer, and joint engagements own distinct interfaces. There is no overlap and no implicit responsibility — every boundary is documented in the deployment runbook.

Customer Owns
  • 01Cloud account, VPC, network
  • 02Hardware, hypervisor, OS
  • 03Identity provider & access policy
  • 04Backup, DR, and data residency
PrivyCDP Owns
  • 01Software release & signed artifacts
  • 02Reference architecture & runbooks
  • 03Update entitlement & version compatibility
  • 04Architect-led deployment review
Joint
  • 01Initial architecture sign-off
  • 02Capacity & performance modeling
  • 03Incident triage on PrivyCDP layer
  • 04Compliance documentation alignment

Section 05 · Infrastructure Separation

Software, Infrastructure, and Operations Are Scoped Separately

Infrastructure, DevOps, cloud, and hardware are scoped separately from the software license. This separation is intentional — it keeps total cost of ownership transparent, prevents vendor lock-in to a specific cloud, and ensures the customer retains full operational control of the environment in which PrivyCDP runs. Architecture review, deployment partnership, and managed support are available as distinct enterprise engagements.

Designed to support SOC 2, ISO 27001, GDPR, HIPAA, PCI DSS and FedRAMP evaluations; deployment evidence required

Planning your evaluation

What is required before a private CDP rollout?

Use workload assumptions to size the environment. This is a planning checklist; a fixed hardware minimum or production SLA needs a configuration-specific proposal.

Size the workload, not just the profile count

Provide average and peak events per second, payload size, retention, profile count, concurrent queries, activation volume and latency objectives. Reserve capacity for replay and recovery; benchmark synthetic peak load before acceptance.

Choose the operating boundary

For a VPC, identify cloud-account ownership, regional services, networking and managed-service permissions. On-premise, include hardware capacity, storage growth and replacement responsibility. Hybrid deployments also need measured inter-site latency and explicit transfer rules.

Prepare identity, networking and access

Approve the runtime and database versions for the selected release. Document DNS, TLS, secrets, identity-provider integration, inbound routes and allowed outbound destinations. A deployment diagram alone does not validate those prerequisites.

Stage, restore and then promote

Load synthetic data into staging, test one integration end to end and restore from backup. Agree recovery point and recovery time targets with named owners. Rehearse rollback and migration recovery before approving the first production release.

Related engineering context: Privacy-first data-flow planning. Use it with the page-specific evaluation questions above.

Discuss your deployment with engineers.

Bring your data flow, operating owners and evaluation questions.

Request an architecture reviewReview Enterprise TCO Model →Request permissioned references and release-specific evidence during evaluation.

Further reading

Published: · Updated:

Editorial dates describe content changes. Confirm current sources before making legal, security or purchasing decisions.