Skip to content
VeraFrame Docs

Deployment

This page is an orientation for Integration deployments. It is not a runbook — VeraFrame’s operations team delivers and operates the deployment. The goal here is to give your architects and security teams enough of a picture to assess fit.

Architecture at a glance

VeraFrame deploys as a serverless stack in your cloud account:

AWS deployment

API Gateway
  → Lambda (verification engine)
      → Bedrock (LLM inference)
      → DynamoDB (history + audit)
      → S3 (source material + rendered outputs)
      → internal async dispatch and persistence

Azure deployment

HTTPS endpoint
  → Azure Functions (verification engine)
      → Azure OpenAI (LLM inference)
      → Cosmos DB (history + audit)
      → Blob Storage (source material + rendered outputs)
      → internal HTTP self-invoke for async work

The frontend is a static React bundle served from the deployment’s frontend hosting layer and configured to talk to your deployment’s API.

Everything runs in a single cloud account and region that your team controls. There is no cross-tenant shared infrastructure.

Region and residency

By default, Integration deployments run in an EU region:

  • AWS: eu-west-1 (Ireland) or eu-central-1 (Frankfurt), your choice.
  • Azure: westeurope (Netherlands) or northeurope (Ireland), your choice.

Other regions are available by agreement. Data never crosses out of the region you choose.

Data ownership

  • Source material — stored in your S3 / Blob Storage, in buckets / containers provisioned into your account.
  • Validation history and audit events — stored in your DynamoDB / Cosmos DB instance.
  • Rendered documents — stored in your S3 / Blob Storage with short-lived download URLs.
  • Secrets — stored in your Secrets Manager / Key Vault.

VeraFrame operations staff access your deployment through a clearly scoped, time-limited role (for support, incident response, or deployment changes). All operator access is logged.

Identity and access

  • User authentication — OIDC integration with your identity provider (Azure AD, Okta, Keycloak, etc.) or local accounts managed by the VeraFrame admin.
  • Service authentication — bearer token authentication or tenant-scoped API keys, depending on deployment setup.
  • Operator access — a cross-account role VeraFrame ops uses during scheduled maintenance windows. You approve and can revoke this access.

In enterprise JWT/OIDC deployments, a common setup is:

  • App-role mapping — customer identity-provider roles are mapped into VeraFrame’s own admin / user / viewer roles for UI and admin permissions.
  • Data-access roles — separate JWT/OIDC roles or claims are used to control which source groups a user is allowed to query.

This keeps VeraFrame’s app permissions and your source-data permissions separate.

Observability

VeraFrame emits logs and metrics to your native platform:

  • CloudWatch (AWS) or Azure Monitor (Azure).
  • Optional: forwarding to your SIEM (Splunk, Datadog, Elastic) is supported via standard log shipping.

No telemetry leaves your account unless you configure it to.

For enterprise operations, use the following default split:

  • Technical runtime logs: CloudWatch or Azure Monitor / Application Insights.
  • Business and audit logs: VeraFrame’s POST /api/v1/audit/export endpoint.

This keeps application observability separate from the customer-facing audit trail. Your platform team can ship native cloud logs to a SIEM, while compliance or reporting teams can ingest the structured audit export independently.

Deployment process

The typical onboarding sequence:

  1. Scoping call. Use case, data volumes, compliance profile, region.
  2. Architecture review. Your security team reviews VeraFrame’s deployment diagram and IaC. A cross-account role is agreed for VeraFrame operations.
  3. IaC deployment. VeraFrame supplies the deployment IaC used for your target environment. All infrastructure is declared as code; nothing depends on manual cloud-console setup.
  4. Configuration. Tenant config, feature flags, compliance profile, OIDC connection.
  5. Data onboarding. Initial source groups created; role-based source access and any downstream REST API context forwarding configured; test validations run end-to-end.
  6. User onboarding. Admin users provisioned; OIDC SSO validated; first team onboarded.
  7. Go-live. Deployment is promoted to production use.

This process typically runs in weeks, not months, because the infrastructure is already codified and the decision points are primarily about your security review rather than about VeraFrame’s engineering.

Updates

New VeraFrame versions are delivered as updated IaC + Lambda / Function deployment artifacts. Your team reviews the release notes, runs the update in a staging environment, and promotes it when ready. VeraFrame does not force updates onto Integration deployments.

Security patches are offered on a fast track with clear severity guidance; urgent patches may be recommended within 72 hours of release.

What VeraFrame does not do in your cloud

  • Does not phone home with your data. No telemetry of source material, validation content, or audit events leaves your account.
  • Does not train models on your data. VeraFrame does not fine-tune or train LLMs.
  • Does not retain backups outside your cloud. Any backups VeraFrame takes during operations live in your account.