Customer-managed Azure deployment
Use Customer-managed Azure when your organization will operate VeriProof in its own Azure subscription. Supported services and data stores run within the approved network boundary.
The repository and some runtime settings use the internal value Hybrid. Use that exact value only where the supplied deployment artifacts require it.
Agree on responsibilities
| Area | Customer responsibility | VeriProof responsibility |
|---|---|---|
| Identity and access | Approve tenant identity, privileged access, service identities, and access reviews | Document required identities, permissions, and product roles |
| Network | Approve ingress, egress, private connectivity, DNS, firewall, and certificates | Document supported endpoints, dependencies, and health checks |
| Keys and secrets | Own Key Vault policy, rotation, recovery, and emergency access | Document required secrets and supported reference patterns |
| Data | Approve capture, region, retention, backup, restore, deletion, and export | Document product stores, fields, and supported controls |
| Proof | Approve the provider and verifier access | Document supported Azure SQL Ledger or Solana configuration and proof fields |
| Operations | Own Azure monitoring, incidents, capacity, patch windows, and environment access | Provide release requirements, diagnostics, and agreed support |
Deployment process
Complete solution design
Record the applications, identities, network paths, data stores, and proof provider in scope. Assign operating owners and resolve requirements that could change the architecture before provisioning.
Obtain the release package
Use the infrastructure templates, application artifacts, database scripts, configuration schema, and runbook supplied for the selected release.
Check the package against the release record. Commands and secret names from another deployment may not apply.
Provision the approved Azure architecture
Deploy through your controlled delivery pipeline. Use managed identities and Key Vault references where the release supports them.
Configure the deployment
Set the values named by the release runbook. This includes the internal operating model, environment, service URLs, identity configuration, proof provider, and required secret references.
Apply database scripts
Apply the supplied scripts through the approved database workflow. Record the exact release and script results.
Validate the customer portal and APIs
Test sign-in and permitted application access, then confirm that out-of-scope requests are denied in an authorized test. Check SDK ingest, policy evaluation, review callbacks, evidence export, health checks, and failure behavior for the enabled workflows.
Verify the proof provider
Verify a representative evidence pack against the configured provider. Keep the result with the deployment record, and monitor later submissions separately.
Accept operating ownership
Name the owners for monitoring, incident response, backup and restore, retention, deletion, upgrades, vulnerability remediation, and support escalation.
This page does not replace the release runbook. Resource names, settings, versions, and supported Azure services can change between releases.
Release evidence
Keep the following evidence with the deployment record:
- approved architecture and responsibility matrix
- infrastructure deployment output and policy results
- identity and least-privilege validation
- database script results
- portal and API qualification results
- backup and restore evidence
- proof-provider verification
- monitoring and alert tests
- release, dependency, and vulnerability records