CERTHIX / Cloud deployment

A deployment plan that covers the working day—and recovery.

Separate the browser application, API, database and evidence storage responsibilities.
Use controlled releases and distinct environments for testing and live work.
Define recovery and service ownership alongside the hosting region.

Cloud deployment

Architecture and operations

A Next.js server sits between the browser and the NestJS API. It provides the browser session boundary while the API enforces permissions and record rules.
PostgreSQL holds structured operational data. Evidence uploads use a separate Azure Blob Storage route with short-lived authorisation.
Background work and trusted storage events have their own execution path. Uploading evidence is separate from deciding whether that evidence may be used.

The repository contains Azure infrastructure definitions for the hosted demonstration: a container registry, Container Apps environment, API container and PostgreSQL Flexible Server.
Production architecture and the demonstration environment have different operating requirements. The demonstration stack is not evidence of a production availability commitment.
AWS and Google Cloud are not established deployment implementations in the reviewed source. A different provider requires a separate engineering and service assessment.

Development, acceptance testing and production need separate configuration, credentials and data boundaries. Use synthetic records for demonstrations.
Database migrations are versioned with the application. Release planning must consider schema compatibility and recovery if a deployment fails.
Customer identity, storage access and background processing must be tested together before live records are introduced.

The production authentication path uses Microsoft Entra ID; the application then evaluates its own memberships and permissions.
The evidence integration is designed to use managed identity in Azure production, avoiding a storage account key in browser code.
Private networking, edge protection, secret management and permitted service connections form part of production infrastructure configuration.

A recovery plan needs an agreed recovery point objective: how much recent work could be lost after a failure.
It also needs a recovery time objective: how long the service may take to return. These targets depend on the configured environment and service agreement.
Test restoration of both database records and evidence. A backup that has never been restored does not demonstrate recovery.

Assign owners for infrastructure updates, application releases, access changes, monitoring alerts and incident response.
Monitor API health, database connectivity and the evidence processing path; a working home page alone is not a complete health check.
Document maintenance arrangements, restore procedures and escalation contacts for the production service.

Illustrative workflows

Create the production environment and configure the organisation’s identity and access model.
Test an inspection, evidence upload, review and correction across the complete service path.
Validate monitoring and restoration before introducing live operational records.

Establish the recovery point and restore the required database and evidence copies.
Check access permissions and linked records before reopening the service.
Record the outcome and any work that needs to be re-entered.