Documentation·Deployment

Deployment.

BackPro deploys inside the client's Azure, AWS, or GCP tenancy via an automated provisioning pipeline. Discovery, hardening, integration, handover, the same sequence every time. Four weeks. Reversible. The client owns every artefact at the end.

The shape

Four weeks. One sequence. Always.

Every deployment follows the same four phases. We do not invent process for each engagement, repeatability is what keeps the timeline honest. The phases are sequential, not parallel: integration cannot begin until hardening is signed off, and handover cannot begin until integration is verified.

Week 1                Week 2                Week 3                Week 4
─────────────────     ─────────────────     ─────────────────     ─────────────────
DISCOVERY             PROVISIONING          INTEGRATION           HANDOVER
─────────────────     ─────────────────     ─────────────────     ─────────────────
· Cloud account       · Terraform apply     · Connector setup     · Evidence pack
  enumeration         · Helm install        · SSO wired           · Decommissioning
· Identity model      · CIS benchmarks      · Read connectors     · Runbook handover
  workshop            · Network policy      · Write surfaces      · Client-owned ops
· Network design      · Observability       · Audit log routing   · Final sign-off
· BCP requirements    · DR backups          · UAT (paraplanner +
                                              compliance officer)
─────────────────     ─────────────────     ─────────────────     ─────────────────
        ▼                     ▼                     ▼                     ▼
   Architecture           Hardening              UAT-signed           Production
   sign-off               sign-off               handover             go-live
                                                                      + Day-1 oncall
I
Pre-flight

What we need before Week 1.

Three things, all client-owned. We ask for them in advance so Week 1 is a workshop, not a procurement exercise.

  1. A dedicated cloud account or subscription. BackPro lives in its own boundary, never the firm's shared prod account. The blast radius is naturally contained.
  2. An identity provider stub. An Entra ID enterprise application, Okta SAML application, or equivalent on the IdP of choice. We map roles in Week 1.
  3. An observability sink. An existing Splunk index, Datadog org, or Sentinel workspace we can stream signed audit events to. We do not host observability, the client's SIEM is the system of record.
II
Provisioning

Terraform first. Helm second. No clicks.

Everything that can be code is code. The Terraform module provisions the network, the IAM, the storage, the Kubernetes cluster (or equivalent compute), and the egress gateway. Helm installs the application workloads against the cluster. There is no manual cloud-console step, if it cannot be reviewed in a diff, it does not happen.

Terraform module shape (illustrative)
module "backpro" {
  source = "git::https://artifacts.backpro.ai/tf/backpro.git//modules/backpro?ref=v3.2.0"

  # Tenancy boundary
  cloud_provider   = "azure"          # azure | aws | gcp
  tenancy_name     = "acme-funds-prod"
  region           = "australiaeast"

  # Network — caller supplies the VNet; module builds subnets + NSGs
  vnet_id          = azurerm_virtual_network.acme.id
  allowed_egress_fqdns = [
    "api.anthropic.com",
    "api.openai.com",
    "generativelanguage.googleapis.com",
  ]

  # Identity — IdP integration
  identity_provider = "entra"
  idp_tenant_id     = var.acme_entra_tenant_id
  idp_app_id        = var.acme_entra_app_id

  # Observability — SIEM sink the audit log streams into
  audit_sink_type   = "splunk_hec"
  audit_sink_url    = var.acme_splunk_hec_url
  audit_sink_token  = var.acme_splunk_hec_token   # sensitive

  # Vector store — managed inside the tenancy
  vector_store      = {
    flavor      = "azure_pg_pgvector"   # azure_pg_pgvector | aws_opensearch_knn | gcp_alloydb
    sku         = "GP_Gen5_4"
    backup_rpo  = "1h"
  }

  # Tags for the firm's existing cost-allocation regime
  tags = local.acme_tags
}
III
Hardening

CIS benchmarks, end of story.

Hardening is not bespoke. Every cluster passes the CIS Kubernetes Benchmark (currently v1.9.0); the OS image passes the CIS Distribution-Independent Linux Benchmark. The benchmark report is generated automatically at the end of Week 2 and attached to the evidence pack.

Firm-specific overrides happen at the namespace policy level (e.g., stricter NetworkPolicy, tighter PodSecurity admission) rather than the cluster level. The cluster is uniform across deployments; the policies above it can vary.

kube-bench output (excerpt, pass status only)
[INFO] 1 Control Plane Security Configuration
[INFO] 1.1 Control Plane Node Configuration Files
[PASS] 1.1.1 Ensure that the API server pod specification file permissions are set to 600 or more restrictive
[PASS] 1.1.2 Ensure that the API server pod specification file ownership is set to root:root
[PASS] 1.1.3 Ensure that the controller manager pod specification file permissions are set to 600 or more restrictive
...
[INFO] 4 Worker Node Security Configuration
[INFO] 4.2 Kubelet
[PASS] 4.2.1 Ensure that the --anonymous-auth argument is set to false
[PASS] 4.2.2 Ensure that the --authorization-mode argument is not set to AlwaysAllow
[PASS] 4.2.3 Ensure that the --client-ca-file argument is set as appropriate
...
== Summary master ==
51 checks PASS
0 checks FAIL
0 checks WARN
0 checks INFO
IV
Integration

Read connectors, write surfaces, UAT.

Week 3 is where BackPro starts talking to the firm's systems of record. Read connectors come first (read-only access to SharePoint, OneDrive, the CRM, Xero, etc.). Write surfaces follow, gated by the named-approver workflow. User-acceptance testing runs at the end of Week 3 with a real paraplanner and a real compliance officer, not a stunt double.

UAT signs off when both can complete one full workflow end-to-end: DDQ draft → review → approve → send; or SoA draft → review → approve → file. If anything blocks, Week 3 extends. We do not advance to handover on a half-working integration.

V
Handover

The audit-ready pack on day 28.

Handover is not a meeting. It is a directory of artefacts the client owns at the end of Week 4 and can hand to a regulator without further redaction. The manifest below is the standard set; firms can request additional artefacts.

Evidence-pack manifest · standard set
  • Architecture diagram (PDF)
    Tenancy boundary, components, data-flow per surface. As-built.
  • Terraform state
    The exact module version + variable values applied. Reproducible build.
  • CIS benchmark report
    kube-bench + Linux-Distro-Independent results. Pass/fail/warn per check.
  • Network policy bundle
    Every applied NetworkPolicy YAML, ordered and namespaced.
  • IAM model export
    Roles, role bindings, service accounts. SoD-reviewable.
  • Identity-provider integration record
    SAML metadata exchange, OIDC client config, the test sign-in trace.
  • Connector inventory
    Each enabled connector, the auth method, the scopes granted, the data classes it reads.
  • UAT sign-off
    Paraplanner + compliance officer signatures against the workflow checklists.
  • BCP plug-in
    BackPro section for the firm BCP: RTO/RPO commitments, failover procedure, contact tree.
VI
Reversibility

You can leave. Cleanly.

A deployment is reversible by design. At any point, the client can terraform destroy the module and the entire BackPro footprint is gone: cluster, vector store, audit log archive, without leaving cross-account references. Source documents stay where they always lived (in the firm's SharePoint / Xero / CRM); BackPro never owned them.

The decommissioning runbook covers data export (vector store dump + audit log export to the client's SIEM), connector revocation, and the final integrity check. We will not unilaterally retain anything.

Under NDA

The deployment runbook, the actual sequence with the actual commands and the actual sign-off forms, releases under NDA on request. contact@backpro.ai.