# Azure enterprise deployment requirements

QualityMax can be evaluated on an organization-controlled Azure Linux virtual
machine using Docker Compose. The organization supplies the Azure environment,
access controls and operating policies; QualityMax supplies the application
release and deployment configuration.

This guide helps an application owner, Azure platform team and security team
agree what must be ready before a pilot and what must be proven before
production. It assumes a private VM deployment. Kubernetes and high availability
require a separate deployment design.

**Deployment acceptance:** approve the application release and licence, provision
accounts, and validate representative workflows, execution isolation and recovery
before enterprise use. VM provisioning completes the infrastructure stage;
application acceptance is a separate decision.

## 1. Assign owners and define the pilot

Choose an application owner who can decide which workflows and data are in
scope. Involve the Azure platform owner, network team, identity/security team
and the person responsible for operations. One person can hold several roles.

| Decision | Required outcome | Suggested owner |
| --- | --- | --- |
| Purpose | Named pilot users, test workflows and success criteria | Application owner |
| Environment | Tenant, subscription, resource group and approved Azure region | Azure platform team |
| Separation | Pilot and production resources and credentials are kept separate | Platform and security teams |
| Governance | Naming, ownership tags, cost centre, budget and applicable Azure policies | Azure platform team |
| Operation | Named support contact, maintenance window and incident process | Operations owner |

Use the organization's existing Azure landing zone when available. A landing
zone is the established foundation for identity, networking, resource management
and governance. Creating a new organization-wide platform is not a prerequisite
when these services already exist. See [Microsoft's landing zone design areas](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/design-areas).

## 2. Agree the network paths

The pilot VM has a private IP address. Employees and administrators need an
approved private route to it, such as the corporate network, VPN or peered
network. Bastion can provide administrator access when the organization uses it.
The current template does not create these shared network services.

| Connection | Required decision |
| --- | --- |
| Administrator to VM | Approved management source range and SSH access on TCP 22 |
| User to QualityMax | Approved client source range and HTTPS access on TCP 8443 |
| VM during installation | Access to Ubuntu package mirrors, Docker packages and approved image/source registries |
| QualityMax to systems under test | Explicit destinations, ports, DNS resolution and permitted execution identities |
| QualityMax to AI services | Local model endpoint or an explicitly approved connected provider |
| VM to organization services | Required monitoring, backup, identity and other platform endpoints |

The NIC network security group permits SSH and HTTPS from the supplied source
ranges and denies other inbound traffic. Subnet security groups, firewalls and
routes must also allow the intended paths. The current application entry port
is 8443; using standard HTTPS port 443 requires an agreed proxy or ingress change.

**Connectivity to test targets needs its own validation.** The default Compose
application and worker networks block off-host connections, including private
corporate URLs. VM connectivity does not automatically give the execution
runtime access. Define controlled execution networking before testing real
applications, and verify both permitted and denied destinations.

Configure an explicit outbound method for the VM. Do not assume internet access
because the VM exists in Azure. Private subnets need an explicit route to reach
public endpoints. A NAT gateway supplies outbound connectivity; use a firewall
or approved proxy when destination filtering is required. See [Azure outbound connectivity](https://learn.microsoft.com/en-us/azure/virtual-network/ip-services/default-outbound-access)
and [Azure Firewall rules](https://learn.microsoft.com/en-us/azure/firewall/rule-processing).

## 3. Set administrator and application access requirements

Use named administrator identities, the organization's multifactor
authentication policy and narrowly scoped Azure role assignments. Separate
deployment permissions from everyday application use. Where the organization
uses Privileged Identity Management, use its time-limited access process rather
than permanent broad privileges. See [Azure RBAC best practices](https://learn.microsoft.com/en-us/azure/role-based-access-control/best-practices)
and [Privileged Identity Management](https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/pim-configure).

Application login is a separate requirement. Establish whether employees need
Microsoft Entra single sign-on, group-to-role mapping, account removal and
emergency access. Confirm these capabilities against the accepted application
release. Configuring Azure administrator access does not implement application
SSO.

For test execution, agree and validate isolation boundaries, permitted network
destinations and credential access. Give any VM managed identity minimal
permissions and ensure execution workloads cannot acquire privileged host
credentials.

## 4. Provide DNS and TLS

Choose a hostname, for example `qualitymax.internal.example.com`, and arrange
DNS resolution from user devices and administrator networks. Supply a valid TLS
certificate for that name, its certificate chain and the private key through
the organization's secure delivery process.

Assign responsibility for certificate renewal and expiry alerts. Client devices
must trust the issuing certificate authority. Configure QualityMax with its
exact external HTTPS origin, including port 8443 when used, so redirects and
browser authentication use the intended address.

## 5. Approve compute and storage

The pilot template defaults to AMD64 Ubuntu 24.04, `Standard_D8s_v5` with 8 vCPU
and 32 GiB RAM, a 64 GiB OS disk and a 256 GiB Premium SSD data disk. It has no
GPU. Confirm regional VM availability and quota before provisioning.

Size the application using concurrent users, parallel browser executions,
database growth and the number and retention of screenshots, videos and traces.
AI model size and latency requirements may require additional CPU, RAM or a
separately designed GPU service. The defaults are a starting point for a pilot;
measure representative workloads before committing to production capacity.

The data disk stores Docker volumes and containerd data, plus protected runtime
configuration, releases and audit data. Keep it separate from temporary VM
storage. Disk retention on VM deletion is useful, but it is not a backup and
does not protect against deleting the disk or resource group.

Check organization policy before deployment. The initial installer expects a
clean stock Ubuntu VM and downloads packages during first boot. Mandatory
corporate images, preinstalled container runtimes, image allowlists,
customer-managed encryption keys, required extensions and tagging policies may
require changes to the template or installer. Adapt and test the implementation
rather than bypassing organization controls.

## 6. Protect secrets and control release images

Agree where database passwords, signing keys, application tokens, licences and
TLS keys are stored, who may retrieve them and how rotation works. They must
not be placed in source control, VM custom data, Bicep parameters, deployment
outputs, support logs or the documentation site.

Azure Key Vault and a narrowly scoped VM managed identity are possible
integrations. They require implementation: the current VM template does not
configure Key Vault retrieval or managed identity. Runtime files still need
protected permissions and coordinated updates when credentials rotate. See
[Key Vault authentication](https://learn.microsoft.com/en-us/azure/key-vault/general/authentication).

Use an approved registry and immutable application image digests. An
organization-managed Azure Container Registry can hold approved copies, provided
the release transfer preserves the required image identity and provenance.
Managed identity can authenticate a VM to ACR when configured with the
appropriate repository access. See [ACR managed identity authentication](https://learn.microsoft.com/en-us/azure/container-registry/container-registry-authentication-managed-identity).

Keep the accepted application image, release metadata and matching database
migrations together. Do not substitute a mutable tag or skip release acceptance
to make a deployment start.

## 7. Set data handling and AI boundaries

Identify the information the deployment may process: uploaded documents, test
credentials, page content, screenshots, recordings, generated scripts and audit
records. Decide what may be captured, who may access it and how long it is kept.
Use synthetic or sanitized pilot data until the relevant owners approve real
business data.

Choose approved regions for the VM, backups and logs. Decide whether inference
must run within the organization-controlled environment or whether an approved
external provider may receive selected data. Hosting the application in the
organization's Azure subscription does not, by itself, approve all data flows or
establish regulatory compliance.

For an offline operating requirement, provide approved images, model weights,
browser dependencies and updates through a controlled transfer process. The
initial VM installer currently requires outbound package downloads.

## 8. Establish monitoring and maintenance

Monitor host availability, CPU/RAM pressure, disk capacity, container health,
application dependencies, certificate expiry and backup results. Send actionable
alerts to a named responder. Define log access, retention and redaction so
credentials and captured customer data do not leak into centralized logs.

Azure Monitor and the organization's security monitoring can provide the host
integration. Configure container/application monitoring and any required
Defender controls explicitly; they are not enabled by the current template.
See [Azure VM monitoring](https://learn.microsoft.com/en-us/azure/azure-monitor/vm/monitor-virtual-machine).

Assign responsibility for Ubuntu security updates, Docker updates, application
releases and emergency fixes. Test approved updates in the pilot environment,
schedule disruptive reboots and keep an incident runbook. Include VM, disks,
network services, registry, logging, backups and model compute in the budget.

## 9. Agree recovery and availability requirements

Record the acceptable data loss and downtime. The recovery point objective
(RPO) is how much recent data the organization can afford to lose; the recovery
time objective (RTO) is how long restoration may take. These decisions determine
backup frequency, retention and the recovery design.

Back up the database, storage objects, artifacts, generated frameworks, audit
records and protected configuration. Keep recovery copies outside the VM and
its data disk. Database consistency requires an application-aware backup or a
coordinated stop before taking a cold snapshot. For Azure Linux VM backups,
configure the required application-consistency coordination. See [Linux application-consistent backup](https://learn.microsoft.com/en-us/azure/backup/backup-azure-linux-app-consistent).

Restore into an isolated replacement environment and prove that the application
and representative data work. Never restore an archive into a running database
volume. Review database compatibility before an application rollback because
migrations are forward-only.

The current Compose topology runs on one VM. A VM or host outage can interrupt
the complete application. Multi-node failover, multi-zone availability and
zero-downtime upgrades need separate design and validation; VM placement alone
does not supply them.

## 10. Complete acceptance in stages

| Stage | Evidence required before proceeding |
| --- | --- |
| Organization preparation | Owners, subscription, region, network paths, DNS/TLS, access policy and budget agreed |
| Host provisioning | Infrastructure validation succeeds; first boot completes; storage mounts and Docker work |
| Release acceptance | Approved image, matching bundle and migrations, licence and account provisioning available |
| Application pilot | Login and a representative QA workflow succeed; artifacts persist; test targets are reachable only as approved |
| Operations validation | Host reboot recovery, alert delivery and a full restore drill succeed |
| Production decision | Performance, isolation, data handling, recovery and availability meet the organization's recorded requirements |

## Information to request from the Azure team

Use this list as the handoff for the first pilot. Replace placeholders in a
private environment record; do not publish actual infrastructure identifiers,
network ranges, keys or customer details on this site.

- Tenant, subscription, resource group and approved Azure region.
- VNet/subnet resource ID, routes and relevant Azure Policy requirements.
- Administrator connection method, SSH public key and allowed management range.
- Allowed user network range, application hostname and certificate owner.
- Approved outbound destinations, image registry and systems under test.
- Expected users, parallel tests, artifact retention and local AI requirements.
- Secret-management approach and any required SSO integration.
- Monitoring/security contacts, backup policy, RPO/RTO and maintenance window.
- Application owner, operational owner, cost centre and pilot acceptance criteria.