Skip to content

Customer Deployment Process

This is the recommended process from closed sale through production handoff.

Phase 0: Commercial and Technical Kickoff

Goal: align scope, stakeholders, deployment model, and success criteria.

Tasks:

  1. Confirm the customer will run Paridity in their own environment.
  2. Identify cloud provider, region, and platform team.
  3. Identify source systems, target systems, and replication tools in scope.
  4. Confirm whether this is a pilot, production deployment, or regulated/SOX deployment.
  5. Assign owners using the responsibility matrix.
  6. Complete the customer intake checklist.
  7. Define success criteria for the first production mapping.

Exit criteria:

  • Stakeholders identified
  • Deployment tier selected provisionally
  • Data systems and replication tools listed
  • Security review path known

Phase 1: Architecture and Security Review

Goal: agree how Paridity will fit into the customer's cloud and control model.

Tasks:

  1. Review the customer deployment overview.
  2. Confirm runtime target: EKS, AKS, GKE, OpenShift, or equivalent.
  3. Confirm PostgreSQL strategy: managed Postgres preferred.
  4. Confirm Temporal strategy: embedded only for pilot; persistent external/dedicated for production.
  5. Assign a customer platform/SRE owner for Temporal operations.
  6. Confirm IdP protocol and role/group mappings.
  7. Confirm secret backend and workload identity pattern.
  8. Confirm network egress destinations and CIDR allow-lists.
  9. Confirm evidence retention, backup, and audit requirements.
  10. Review license and cost considerations.

Exit criteria:

  • Security team approves deployment pattern
  • Network flow list approved
  • Identity and secret manager designs approved
  • Sizing tier selected

Phase 2: Infrastructure Provisioning

Goal: create the customer-owned infrastructure Paridity needs.

Typical Terraform-backed path:

cd deploy/terraform/aws    # or azure / gcp
terraform init
terraform apply \
  -var region=<region> \
  -var sizing_tier=<small|medium|large> \
  -var 'allowed_egress_cidrs=["<source>","<target>","<secret-backend>"]'

Tasks:

  1. Provision or identify Kubernetes cluster.
  2. Provision or identify managed PostgreSQL.
  3. Provision or identify Temporal and its persistence backend.
  4. Enable backups and point-in-time recovery for PostgreSQL and Temporal persistence.
  5. Create database URL secret for the Helm chart.
  6. Configure workload identity for secret manager access.
  7. Configure ingress controller, DNS, and TLS secret.
  8. Configure network policies/firewall allow-lists.
  9. Mirror the release images from Paridity's private GHCR into the customer registry with the issued read-only pull token, and verify digests survived the mirror (docs/runbooks/deployment.md §2.0). Digests come from the release's digests-vX.Y.Z.md manifest on the GitHub Release.

Exit criteria:

  • Kubernetes access available
  • PostgreSQL reachable from cluster
  • Temporal reachable from API and worker pods
  • Secret backend access configured
  • DNS/TLS path ready
  • Network allow-lists implemented

Phase 3: Identity and Secret Setup

Goal: make authentication and runtime credentials work without embedding secrets in Paridity.

Tasks:

  1. Create OIDC or SAML application in the customer IdP.
  2. Configure redirect URLs, issuer/entity ID, audience/client ID. For SAML, list the email domains your users sign in with on the provider (Settings -> Authentication). The login page finds a SAML provider only by email domain, so an enabled provider with no domains is not offered at sign-in; the settings page flags it. A domain can route to only one enabled SAML provider. To move from one IdP to another, add the domains to the new provider while it is still disabled, then disable the old one and enable the new one. The SSO URL, signing certificate and domains can be changed later without re-registering, so rotating an expiring IdP certificate keeps the same ACS URL. Only the entity ID is fixed after creation.
  3. Map customer groups to Paridity roles.
  4. Create source/target/replication service accounts.
  5. Store credentials in the customer secret backend.
  6. Create a preflight canary secret.
  7. Validate workload identity can read the canary secret.

Exit criteria:

  • Login path defined
  • Role mapping approved
  • Secret references created
  • Preflight canary available

Phase 4: Paridity Installation

Goal: install the application stack.

Example Helm install:

helm install recon deploy/helm/paridity \
  -f deploy/helm/paridity/values-medium.yaml \
  --namespace paridity --create-namespace \
  --set image.backend.repository=<customer-registry>/paridity-api \
  --set image.frontend.repository=<customer-registry>/paridity-ui \
  --set image.docs.repository=<customer-registry>/paridity-docs \
  --set image.backend.digest=sha256:<backend-image-digest> \
  --set image.frontend.digest=sha256:<frontend-image-digest> \
  --set image.docs.digest=sha256:<docs-image-digest> \
  --set database.external.existingSecret=recon-db \
  --set temporal.host=<temporal-host:7233> \
  --set oidc.issuer=<customer-idp-issuer> \
  --set oidc.audience=recon-platform-api \
  --set app.publicBaseUrl=https://<paridity-hostname> \
  --set preflight.connectionRef=<customer-secret-ref> \
  --set app.audit.signingKeyRef=<kms-key-ref>            # required in production (#2134) \
  --set app.evidenceBundles.signingKeyRef=<kms-key-ref>  # evidence-bundle signer - see below (#2558) \
  --set networkPolicy.enabled=true \
  --set ingress.enabled=true \
  --set ingress.host=<paridity-hostname> \
  --set ingress.tlsSecret=<tls-secret>

Two signers, two keys

Paridity signs two different things, and each has its own setting. Setting one does not set the other.

Setting What it signs Who checks it If you leave it empty
app.audit.signingKeyRef The audit log's hash-chain checkpoints Paridity's chain verification A production install refuses to start
app.evidenceBundles.signingKeyRef Exported evidence bundles (manifest.json.sig) Your auditor, offline, with verify_bundle.py Bundles ship unsigned, and the offline verifier refuses to call them verified

Use an asymmetric key for the evidence-bundle signer - a cloud KMS key ref (awskms://, azurekv://, gcpkms://), or a secrets-backend URI whose secret is a private ECDSA P-256 PEM. Your auditor then verifies bundles with the PUBLIC key alone. An HMAC key also signs, but only someone who holds that key can verify it, so it does not give an auditor independent verification.

The value sets the platform-wide default when Paridity first starts, and again after a database rebuild. After that, the product setting wins: an administrator can change the default on the configuration screen, or set a different signer for a tenant, and the Audit page shows which signer is in effect. If you choose to ship unsigned bundles, the API logs a warning at every production start that names this setting.

What happens during install:

  1. Preflight job verifies the customer secret backend.
  2. Migration job bootstraps or upgrades Paridity PostgreSQL.
  3. API, UI, Temporal, and workers roll out.
  4. Ingress exposes the UI/API.

Exit criteria:

  • All pods ready
  • API /health returns healthy
  • UI loads over HTTPS
  • User can authenticate through customer IdP
  • Workers connect to Temporal
  • The Audit page shows the evidence-bundle signer as configured, and one exported evidence bundle verifies offline with verify_bundle.py --public-key <your public key> (skip only if you have chosen unsigned bundles)

Phase 5: Connectivity Validation

Goal: confirm Paridity can reach only the approved systems and can perform its minimum required work.

Tasks:

  1. Validate source system connection.
  2. Validate target system connection.
  3. Validate replication metadata access if applicable.
  4. Validate secret references resolve at runtime.
  5. Confirm no plaintext credentials are stored in Paridity tables.
  6. Confirm network policies block unapproved destinations.
  7. Confirm logs do not contain secrets or row payloads.

Exit criteria:

  • Source, target, and replication connectivity verified
  • Network/security checks pass
  • Customer security team accepts the runtime path

Phase 6: First Mapping and Reconciliation Run

Goal: prove an end-to-end reconciliation using a representative but controlled dataset.

Tasks:

  1. Configure systems.
  2. Configure replication profile.
  3. Create mapping and fields.
  4. Refresh schema.
  5. Configure schedule or manual run.
  6. Run full mode.
  7. Run auto mode, if incremental reconciliation is in scope.
  8. Review proof results, mismatch evidence, and audit records.

Exit criteria:

  • First run completes successfully
  • Evidence is visible to authorized users
  • Audit log contains expected actions
  • Customer understands how to interpret pass/fail statuses

Phase 7: Production Readiness Review

Goal: verify the deployment is ready for business use.

Checklist:

  • Security checklist complete
  • Backups enabled
  • Restore test completed or scheduled before regulated use
  • Monitoring dashboards configured
  • Alerts configured
  • Runbook owners assigned
  • Temporal operations owner assigned
  • Temporal restart, backup/restore, and upgrade procedure reviewed
  • Evidence retention policy configured
  • Upgrade procedure reviewed
  • Incident process documented
  • Initial mappings and schedules approved

Exit criteria:

  • Customer production owner signs off
  • Security/compliance signs off
  • Paridity implementation team signs off

Phase 8: Handoff and Day-2 Operations

Goal: transfer normal operation to the customer operations team.

Handoff package:

  • Installed version and image digests
  • Helm values used
  • Terraform outputs or infrastructure notes
  • IdP configuration summary
  • Secret backend configuration summary
  • Network allow-list summary
  • Backup/restore details
  • Temporal operations owner and runbook
  • Monitoring and alert details
  • Known limitations and agreed follow-ups
  • Support escalation path

Normal operations include:

  • Monitoring API, workers, Temporal, and PostgreSQL
  • Restarting Temporal when required by the runbook
  • Reviewing failed or delayed runs
  • Adding mappings and schedules
  • Managing user access through IdP groups
  • Rotating source/target credentials in the customer secret manager
  • Applying Paridity upgrades through Helm
  • Applying Paridity-approved Temporal patches/upgrades
  • Running periodic restore validation