Azure Deployment Guide
This guide prepares a customer-controlled Azure environment for Siesta AI. The platform remains a managed product with coordinated releases and support, while the customer owns the Azure subscription, policy boundary, networking decisions, and agreed operational responsibilities.
Use this guide with the Deployment Models, Reference Architecture, and the customer-specific implementation package supplied for the engagement. Do not copy example identifiers into production.
Deployment Outcome
A completed deployment has:
- an approved Azure tenant, subscription, region, and billing owner,
- named customer and Siesta AI deployment contacts,
- an isolated resource and policy boundary,
- approved identity, network, DNS, egress, and private-connectivity decisions,
- secrets stored in an approved secret store,
- infrastructure provisioned from reviewed Infrastructure as Code,
- working sign-in, application, retrieval, tool, model, and monitoring paths,
- documented acceptance evidence, support access, upgrade process, and handover owners.
1. Confirm the Operating Model
Before provisioning, agree who owns each activity.
| Area | Customer responsibility | Siesta AI responsibility |
|---|---|---|
| Azure boundary | Tenant, subscription, billing, policy, region approval | Required capabilities and deployment guidance |
| Infrastructure | Approve and provide the target boundary | Supply and operate the approved IaC and application release process |
| Identity | Entra ID, groups, SSO approval, privileged-access policy | Application roles and workload-identity requirements |
| Networking | VNet integration, DNS, firewall, private endpoints, egress approval | Document required service flows and validate application connectivity |
| Secrets | Approve store, access policy, rotation owners | Use the agreed secret references and avoid secrets in source control |
| Monitoring | SIEM integration, customer alerts, escalation contacts | Product health signals, deployment diagnostics, and support runbooks |
| Updates | Change windows and customer approval gates | Versioned releases, deployment instructions, validation, and rollback guidance |
Customer-controlled does not automatically mean customer-operated. Record the actual deployment, monitoring, support, backup, and incident responsibilities in the implementation agreement.
2. Prepare the Azure Boundary
A dedicated Azure subscription is the recommended default for production. It gives the clearest cost, policy, access, and lifecycle boundary. If the customer uses a shared subscription, use dedicated resource groups and confirm that inherited policy cannot block required services or grant unintended access.
Prepare:
- Azure tenant and subscription IDs.
- Subscription display name and billing owner.
- Primary region and approved paired or recovery region, if required.
- Mandatory resource tags such as owner, environment, cost center, data classification, and service.
- Azure Policy assignments and exemptions that affect the deployment.
- Resource-provider registration and quotas for compute, networking, storage, search, databases, AI/model services, monitoring, and secrets.
- Naming rules that do not expose customer-sensitive data.
Do not start until region availability and model quota have been validated. Resource location and model deployment type are separate data-residency decisions; see Model Deployment and Data Residency.
3. Establish Identity and Access
Use Microsoft Entra ID groups instead of assigning production access to individual users wherever possible.
Define:
- a customer deployment approver group,
- a least-privileged deployment identity for the approved IaC pipeline,
- workload identities or managed identities for runtime services,
- read-only operations and security-review groups,
- time-bound privileged or break-glass access with auditable approval,
- support access, its expiry, and the procedure for enabling and removing it.
Avoid long-lived owner credentials and secrets in local configuration. Separate deployment authority from routine monitoring. See Identity and Access.
4. Approve Networking and DNS
Decide whether ingress and managed-service traffic use public endpoints with restrictions, private endpoints, or a hybrid pattern. Document every required flow before applying deny-by-default controls.
Review:
- VNet and subnet ownership, address space, delegation, and peering,
- private DNS zones and resolution from customer networks,
- ingress, TLS certificates, WAF or reverse-proxy ownership,
- fixed or controlled egress and required external destinations,
- private endpoints for data, search, secret, registry, database, and model services where supported,
- connectivity to customer systems and identity providers,
- diagnostic routing to Azure Monitor, Log Analytics, or the customer SIEM.
Do not infer that successful resource deployment proves runtime connectivity. Test DNS, TLS, identity, and application calls separately. See Network Security and Firewall and Egress.
5. Prepare Secrets and Configuration
Use the customer-approved Azure Key Vault or equivalent secret store. The deployment package should receive secret references, not secret values committed to a repository or pasted into tickets.
Before deployment, identify owners and rotation procedures for application credentials, model/provider credentials, storage access, external integrations, signing keys, and certificates. Confirm that runtime identities can read only the secrets they need and that deployment identities cannot silently broaden runtime access.
6. Review and Run Infrastructure as Code
Siesta AI supplies the customer-specific, versioned Bicep or Terraform package agreed for the engagement. Treat that package as the deployment contract.
- Verify the package version, checksum or release reference, and target environment.
- Review parameter files without adding secrets.
- Run the platform-native validation and preview operation, such as Bicep validation/what-if or a Terraform plan.
- Review resource types, regions, role assignments, network changes, policy exceptions, and destructive operations.
- Obtain the required customer approval.
- Execute through the approved deployment identity and pipeline.
- Store the deployment output and approval evidence in the controlled implementation record.
Do not manually rename, replace, or modify managed resources after deployment. Feed required changes back into the IaC package so the next release remains repeatable. See Infrastructure as Code.
7. Configure the Platform
After infrastructure provisioning:
- Configure application URLs, identity settings, and approved redirect URIs.
- Connect model deployments and verify their region, deployment type, quota, and content-safety settings.
- Configure storage, search, databases, queues, and background processing through managed identity or approved secret references.
- Enable monitoring, audit, backup, and retention settings.
- Create the initial Siesta AI Owner/Admin identities through the approved process.
- Add only the pilot Connections, Data sources, agents, and workflows required for acceptance.
8. Validate the Deployment
Acceptance must cover behavior, not only successful provisioning.
| Test | Expected evidence |
|---|---|
| Identity | Approved users can sign in; unauthorized users cannot |
| Application health | Frontend, API, background processing, and scheduled work are healthy |
| Retrieval | A controlled document can be ingested, indexed, retrieved, and cited |
| Models | Approved model deployment responds and usage appears in monitoring |
| Tools | A read action succeeds and a protected write action requires approval |
| Networking | Required private/public paths work; unapproved paths remain blocked |
| Secrets | Runtime reads required secrets without exposing them in logs or configuration output |
| Observability | Logs, metrics, alerts, audit records, and escalation routing are visible |
| Recovery | Backup/restore or the agreed recovery check is recorded |
Record failures, owners, and retest evidence. Do not attach production users or data until critical acceptance items are closed.
9. Handover and Ongoing Operations
The handover package should contain the approved architecture, resource inventory, owners, support contacts, monitoring links, alert thresholds, backup and recovery targets, credential-rotation schedule, deployment version, change process, and rollback procedure. Keep customer-specific endpoints and identifiers in the access-controlled handover record, not public documentation.
Upgrades follow the same controlled path: versioned release, reviewed IaC preview, approved change window, deployment, smoke tests, and rollback decision. Emergency access must be time-bound and reviewed after use.