Customer Deployment Requirements¶
This document lists what must exist before Paridity can be deployed into a customer environment.
1. Cloud and Runtime Requirements¶
| Requirement | Production expectation |
|---|---|
| Cloud account or subscription | Customer-owned AWS, Azure, GCP, or private cloud account |
| Container platform | Kubernetes preferred: EKS, AKS, GKE, OpenShift, or private Kubernetes |
| Container registry access | A customer-owned registry (ECR/ACR/GAR) to mirror the Paridity images into, plus one-time-per-release read access to Paridity's private GHCR via an issued pull token (crane copy, digest-preserving - see docs/runbooks/deployment.md §2.0). Installs pin by digest from the release manifest |
| Helm | Used to install and upgrade Paridity |
| Terraform | Optional reference path for infrastructure provisioning |
| DNS | Customer-owned DNS name for the UI/API, such as paridity.customer.example |
| TLS certificate | Customer-issued or managed TLS certificate for ingress |
Kubernetes is recommended, not conceptually mandatory. If the customer requires ECS, Azure Container Apps, Cloud Run, or VM-based deployment, that becomes a customer-specific packaging project.
2. Database Requirements¶
Paridity requires PostgreSQL for its own metadata, run lifecycle, and evidence.
| Requirement | Production expectation |
|---|---|
| PostgreSQL version | Managed PostgreSQL compatible with the application's migrations |
| Network access | Private network access from Paridity pods to PostgreSQL |
| Encryption | Storage encryption enabled |
| TLS | TLS required for application connections where supported |
| Backups | Automated backups and point-in-time recovery |
| Extensions | uuid-ossp, pgcrypto, and ltree available or pre-created |
| Database user | Privileges to run migrations or a DBA-supported migration process |
For production, use RDS, Azure Database for PostgreSQL Flexible Server, Cloud SQL for PostgreSQL, or an approved customer-managed PostgreSQL service.
3. Temporal Requirements¶
Temporal is required for durable reconciliation workflows. Paridity is currently built on Temporal as its orchestration engine; alternative customer schedulers such as Airflow, Control-M, Step Functions, or Argo can trigger Paridity through the API, but they do not replace Paridity's internal Temporal runtime.
| Requirement | Production expectation |
|---|---|
| Temporal server | Deployed in the customer environment |
| Persistence | PostgreSQL-backed persistence with backup coverage |
| Network access | API and worker pods can reach Temporal on the configured host/port |
| Namespace | default or customer-approved namespace |
| Operations owner | Customer platform/SRE owner assigned for Temporal monitoring, restart, patch, upgrade, backup, and restore |
| Version control | Temporal version stays within the Paridity-supported compatibility range |
Small pilots may use embedded Temporal. Production should use a persistent, operationally supported Temporal deployment.
Customer users do not need direct Temporal access. Customer operations teams do need runbooks and permissions to restart Temporal, review logs, monitor health, apply Paridity-approved upgrades, and restore Temporal persistence during DR.
4. Identity and Access Requirements¶
Paridity authenticates users through the customer's identity provider.
| Requirement | Production expectation |
|---|---|
| IdP | OIDC or SAML-capable provider |
| Issuer/entity ID | Stable issuer URL or SAML entity ID |
| Audience/client ID | API audience and UI client configuration |
| User claims | Email/subject, tenant identifier if applicable, role/group claims |
| Role mapping | Mapping from IdP groups to Paridity roles |
| Break-glass policy | Customer-approved emergency admin access procedure |
Main application roles:
| Role | Typical use |
|---|---|
platform_admin |
Deployment-wide administration |
tenant_admin |
Tenant-scoped administration |
operator |
Configure mappings, schedules, and runs |
analyst |
Investigate reconciliation results |
auditor |
Read audit and evidence records |
5. Secret Manager Requirements¶
Paridity must be able to resolve customer-owned connection references at runtime.
| Requirement | Production expectation |
|---|---|
| Secret backend | AWS Secrets Manager, Azure Key Vault, GCP Secret Manager, Vault, or Infisical |
| Workload identity | IRSA, Azure Workload Identity, GKE Workload Identity, or equivalent |
| No static cloud keys | Static keys should not be stored in Kubernetes secrets |
| Connection references | URI-style references stored in Paridity, credentials stored only in the secret backend |
| Canary secret | A test connection_ref for install-time preflight validation |
Example connection reference:
aws-secrets://arn:aws:secretsmanager:us-east-1:123456789012:secret:paridity/oracle-prod
6. Network Requirements¶
Paridity workers need controlled outbound access to the systems they reconcile.
| Destination | Required from |
|---|---|
| Source databases | SQL/readiness workers |
| Target databases/warehouses | SQL/diff workers |
| Replication metadata APIs or databases | Readiness workers |
| Customer secret backend | API and worker pods |
| Paridity PostgreSQL | API, workers, migration job |
| Temporal | API and workers |
| OIDC/JWKS or SAML IdP endpoints | API and UI/browser flow |
| OpenTelemetry/SIEM/log endpoints | Optional, if customer requires telemetry export |
Production deployments should use default-deny egress with explicit allow-lists.
7. Source and Target Access Requirements¶
Paridity needs least-privilege access to compare data.
Typical permissions:
- Read metadata for schemas, tables, columns, and keys
- Read selected source and target tables/views
- Execute hash/proof SQL functions where supported
- Read replication state or CDC metadata where configured
- Create no objects in source/target systems unless a specific connector path requires customer-approved staging
Credentials should be service accounts created and owned by the customer.
8. Operational Requirements¶
| Area | Requirement |
|---|---|
| Monitoring | Pod health, API health, worker queues, Temporal health, PostgreSQL metrics |
| Logging | Application logs retained according to customer policy |
| Audit | cfg.audit_log retained and optionally exported to SIEM |
| Backup | PostgreSQL and Temporal persistence backups enabled and tested |
| Restore testing | Restore validation before production go-live |
| Upgrade window | Customer-approved maintenance window for Helm upgrades and migrations |
| Evidence retention | Customer-approved retention and purge policy |
| Temporal operations | Customer-owned operational procedure for Temporal health, restart, patch, upgrade, backup, and restore |
9. Sizing Inputs¶
Before sizing the deployment, collect:
- Number of mappings
- Largest table sizes
- Expected schedule frequency
- Required concurrency
- Source and target systems involved
- Whether proof-only mode is acceptable for some mappings
- Whether field-level diff evidence is required for every mismatch
- Evidence retention duration
- Required RPO/RTO
- Cloud region and data residency constraints