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
Section titled “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.
2. Agree the network paths
Section titled “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 and Azure Firewall rules.
3. Set administrator and application access requirements
Section titled “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 and Privileged Identity Management.
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
Section titled “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
Section titled “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
Section titled “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.
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.
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
Section titled “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
Section titled “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.
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
Section titled “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.
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
Section titled “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
Section titled “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.
Guide source and mirror
Section titled “Guide source and mirror”This guide follows the approved on-prem deployment guide at revision 274ea8c (repository access required). A public GitHub Pages mirror is also available. Updates to deployment requirements are reviewed in the on-prem repository before this page is refreshed.