Private Deployment on Azure

Use this guide as the technical entrypoint for deploying Siesta AI into a customer-controlled Azure environment. It defines the boundary between the customer platform, the versioned Siesta AI deployment package, application private mode, and the release evidence needed for production handover.

Detailed operating procedures remain in Deployment and Operations. The implementation agreement and the customer-specific deployment package are authoritative for the exact topology, regions, service tiers, recovery targets, and delivery route.

Deployment Contract

A private deployment runs in an Azure tenant and subscription controlled by the customer. Customer-controlled does not necessarily mean customer-operated: the responsibility split must name who deploys, approves, monitors, supports, and restores each layer.

The customer owns or explicitly delegates:

• subscription and tenant governance, Azure Policy, resource-provider registration, quotas, and cost controls;
• virtual networks, private DNS, ingress, TLS certificates, outbound access, firewalls, and connectivity to corporate services;
• Microsoft Entra administration, security groups, privileged access, and approval of application permissions;
• monitoring destinations, SIEM integration, retention, incident routing, backup policy, and recovery objectives;
• change windows and the identities permitted to review, import, deploy, and roll back releases.

Siesta AI supplies the agreed, versioned infrastructure and application artifacts, documents their required inputs, and validates the deployed application with the customer. Treat the package as one release unit: do not combine unreviewed infrastructure from one version with application artifacts from another.

IaC package layout

The reference package uses a subscription-scoped Bicep entrypoint and a resource-group-scoped orchestrator. Read the delivered version before changing parameters because it is the executable contract for that release.

Path	Technical purpose
bicep/deploy.bicep	Subscription-scope entrypoint. It creates the deployment resource group, invokes the resource-group deployment, and returns the application and API endpoints.
bicep/main.bicep	Resource-group orchestrator. It connects module outputs to downstream inputs and defines the deployment dependency graph.
bicep/modules/*.bicep	Resource modules for network, monitoring, identities, registry, data, secrets, AI services, compute, Private DNS, and Private Endpoints.
bicep/parameters/<ENVIRONMENT>.json	Customer-controlled, non-secret values for one environment. Keep customer parameter files in the approved private delivery location, not in public examples.
bicep/deploy.ps1	Optional helper that validates the package and previews changes before an explicitly requested deployment. Review the script from the delivered release before running it.

The reference package does not replace the customer's enterprise edge, corporate DNS, TLS lifecycle, firewall governance, model-capacity approval, or release approvals. Those inputs connect to the package through the customer-specific implementation agreement.

Top-level parameter contract

The subscription entrypoint currently accepts the following parameter groups. Do not infer production values from defaults in a module or an example file.

Parameter group	Contract and review points
Placement	Azure location must satisfy customer policy and the availability requirements of every selected service.
Naming	clientCode is a one-to-three-character deployment code. environment accepts tst, tes, dev, stg, or pro. Confirm that the resulting names meet customer naming rules before apply.
Service tiers	Registry, primary database, retrieval database, AI Services, AI Search, and Storage tiers are explicit inputs. Confirm private-link support, capacity, resilience, and cost rather than copying sample values.
Microsoft Entra administration	Supply the display name and object ID of the approved SQL administrator group. Use a group, not a personal identity.
Resource protection	enableLocks controls CanNotDelete locks on supported critical resources. Align it with the environment lifecycle and documented break-glass process.

Nested modules can contain additional network and runtime parameters. The delivery review must confirm that the subscription entrypoint exposes or intentionally fixes every customer-controlled value. In particular, reject a broad catch-all ingress source before production and scope ingress to the approved gateway or upstream network.

Validate, preview, and apply

Run validation at the same scope as the entrypoint. Use an access-controlled parameter file and a unique deployment name that can be traced to the approved release.

az bicep build --file bicep/deploy.bicep

az deployment sub validate \
  --location "<DEPLOYMENT_LOCATION>" \
  --name "<DEPLOYMENT_NAME>" \
  --template-file bicep/deploy.bicep \
  --parameters @bicep/parameters/<ENVIRONMENT>.json

az deployment sub what-if \
  --location "<DEPLOYMENT_LOCATION>" \
  --name "<DEPLOYMENT_NAME>" \
  --template-file bicep/deploy.bicep \
  --parameters @bicep/parameters/<ENVIRONMENT>.json

Review the complete what-if result, including role assignments, network rules, Private DNS links, resource replacements, and deletions. Apply exactly the reviewed template and parameter file only after approval:

az deployment sub create \
  --location "<DEPLOYMENT_LOCATION>" \
  --name "<DEPLOYMENT_NAME>" \
  --template-file bicep/deploy.bicep \
  --parameters @bicep/parameters/<ENVIRONMENT>.json

az deployment sub show \
  --name "<DEPLOYMENT_NAME>" \
  --query properties.outputs

Archive the compiled-template hash, parameter-file hash, what-if, approval, deployment operations, and outputs as one evidence set. Outputs are deployment metadata for downstream bootstrap; do not treat them as authorization to expose a private endpoint or copy secrets into a pipeline log.

Customer Prerequisites

Resolve these inputs before the implementation window. Record customer-specific values only in the access-controlled deployment workbook or handover package, never in public documentation or source examples.

Area	Required decision or input
Azure scope	Tenant, subscription, approved regions, resource providers, policy assignments, naming and tagging rules, budget, and service quotas
Network and DNS	Virtual network and subnet ownership, private DNS integration, ingress hostname, TLS ownership, approved egress, proxy or firewall path, and connectivity tests
Identity and access	Deployment identity, Microsoft Entra administrators, operator groups, database administrator group, workload identities, RBAC approvers, and access-review process
Artifact delivery	Customer Azure Container Registry, import or transfer identity, permitted source, digest-verification process, and audit owner
AI capacity	Approved model deployments, regional availability, token and throughput quotas, content-safety requirements, and fallback decisions
Operations	Log Analytics or equivalent destinations, alert owners, SIEM forwarding, support contacts, maintenance windows, and escalation route
Resilience	Backup scope and retention, restore owner, tested RTO/RPO targets, rollback decision maker, and an approved change window
Application identity	Organization-owned Microsoft Entra app registration, tenant and client IDs, redirect URIs for enabled surfaces, Graph permissions, and admin consent

Use Deployment Lifecycle to turn the inputs into a reviewed implementation sequence.

Reference Architecture

The reference Infrastructure as Code package provisions logical layers rather than a fixed universal resource count. The exact modules enabled, topology, SKUs, and regional placement are defined by the customer-specific package.

Layer	Typical responsibility in the reference package
Identity and secrets	Managed identities, RBAC assignments, Microsoft Entra integration, and Key Vault references
Network and name resolution	Virtual network integration, Private Endpoints, Private DNS zones and links, ingress controls, and approved egress
Registry and workloads	Azure Container Registry, Container Apps, Functions, workload identity, image pull, health probes, and scale configuration
Data and messaging	Azure SQL, Storage, queues or messaging dependencies, backup configuration, and private service access
AI and retrieval	Azure AI Services, approved model deployments, AI Search, and Document Intelligence where required
Operations	Azure Monitor, Application Insights, Log Analytics, diagnostic settings, alerts, and customer SIEM forwarding

See Reference Architecture, Runtime Services, and Network Security for the canonical service and trust boundaries.

Module dependency graph

main.bicep wires resources in dependency order. Bicep derives most dependencies from module outputs, so preserve those references rather than replacing them with reconstructed resource names.

Stage	Modules and dependency purpose
1. Foundation	Network, Log Analytics/Application Insights, and separate user-assigned managed identities for API, retrieval, tools, and frontend workloads.
2. Data plane	Container Registry, Storage, two Key Vault boundaries, SQL databases, Azure AI Services and AI Search. These modules consume identity principal IDs and monitoring outputs.
3. Compute	An internal Container Apps managed environment and its application workloads, followed by an App Service plan and Function Apps. Compute consumes registry, identity, subnet, Key Vault, Storage, and monitoring outputs.
4. Supporting services	Communication Services and Document Intelligence where included by the delivered package.
5. Private access	Private DNS zones linked to the virtual network, then Private Endpoints and DNS zone groups for supported PaaS resources.
6. Bootstrap	Computed endpoints and identity-aware connection metadata are seeded after their producers exist. Customer secrets and approved application artifacts are supplied through the controlled release path.

This is a dependency model, not a recommendation to run six independent deployments. The subscription entrypoint remains the normal unit for validation and apply.

Network and private DNS contract

The reference network separates three traffic purposes:

Subnet purpose	Azure delegation or policy	Expected traffic
Container Apps infrastructure	Delegated to Microsoft.App/environments	Internal managed-environment infrastructure and application ingress from the approved upstream source
Private Endpoints	Private Endpoint network policies enabled	Private Link connections to data, registry, secrets, AI, and Function resources
Service integration	Delegated to Microsoft.Web/serverfarms	Function App VNet integration and outbound access to approved platform dependencies

The package creates service-specific Private DNS zones and virtual-network links for the enabled Azure services. The current reference set covers Storage blob, file and queue endpoints; Key Vault; Azure SQL; Cognitive Services; AI Search; App Service/Functions; Container Apps; and Container Registry. Each Private Endpoint is associated with the matching zone through a Private DNS zone group.

Do not validate private connectivity from a public workstation. From a host using the customer resolver and connected network, confirm that each service FQDN resolves through the intended private zone and that the connection reaches the expected resource. A successful DNS lookup alone does not prove NSG, route, firewall, RBAC, or application-layer access.

Managed identity and RBAC contract

The reference package uses separate user-assigned identities to keep frontend, API, retrieval, and tool permissions distinct.

Principal	Reference access boundary
Frontend workload identity	Pull approved frontend images from the customer registry. It does not inherit the service data-plane role set.
API identity	Pull images and access the approved Key Vault, Storage, Azure AI Services, AI Search, and Document Intelligence data planes required by the API and API Functions.
Retrieval identity	Pull images and access the same approved service data planes for retrieval workloads, background processing, and retrieval Functions.
Tools identity	Pull images and access the approved service data planes required by the tools workload.
Customer administrator group	Operate the registry and supported data services, administer Key Vault, and act as the Microsoft Entra administrator for Azure SQL according to the delivered package.

Representative built-in data-plane assignments include AcrPull, Key Vault Secrets User, Key Vault Crypto User, Storage Blob Data Owner, Storage Queue Data Contributor, Storage Table Data Contributor, Cognitive Services User, Search Index Data Contributor, and Search Service Contributor. Customer operator assignments are broader and must remain group-based, approved, time-bounded where required, and reviewed separately from workload identity.

Azure role assignments can take time to propagate. Before declaring a workload unhealthy, verify that the expected principal ID received the expected assignment at the intended resource scope and retry only after propagation. Do not add a shared credential as a workaround.

Runtime and bootstrap contract

The current reference compute topology contains:

• frontend and API Container Apps with application-facing ingress inside an internal Container Apps environment;
• internal retrieval and tools Container Apps;
• a retrieval worker without ingress;
• private API and retrieval Function Apps integrated with the service subnet.

Container Apps pull from the customer registry with their user-assigned identities and expose readiness or liveness probes appropriate to each workload. Function Apps disable public network access, require authentication, enforce HTTPS and TLS 1.2, integrate with the service subnet, and use managed identity for their Storage binding.

Infrastructure deployment can create workload shells and computed configuration, but it does not make a release production-ready by itself. Before acceptance:

1. replace every bootstrap image reference with the approved application artifact and verify the digest in the customer registry;
2. replace every unresolved secret marker through the approved secret-delivery path without placing secret values in Bicep parameters, source control, deployment outputs, or logs;
3. provision and approve the required model deployments and quotas for the selected region;
4. apply database migrations and application bootstrap steps from the matching release package;
5. confirm that Container App revisions and Function deployments use the expected identities, configuration, and artifact versions.

Public network access is disabled for the reference Registry, Storage, Key Vault, SQL, AI/Search, Document Intelligence, and Function resources. Local-key or shared-key authentication is also disabled where the service supports the managed-identity path. Treat any customer-specific exception as an explicit, reviewed deviation with an owner and removal date.

Private Mode and Identity

Private mode is activated as part of the delivered deployment package and must be applied consistently to the frontend and API. It is not an independent product switch to enable after deployment.

In private mode:

• sign-in uses the customer-owned Microsoft Entra application;
• password, local-account, Google, and open self-service registration paths are unavailable;
• onboarding is scoped to the configured organization and tenant;
• invitation-based onboarding, automatic account creation on first Microsoft sign-in, and Microsoft Entra group synchronization remain separate organization decisions;
• organization roles and permissions still govern what an authenticated user can do.

Create the identity contract before broad onboarding. Follow Configure Microsoft Entra ID App Registration for web, mobile, Windows, macOS, and browser-extension parameters. Review Identity and Access for administrator, deployment, workload, and support identities.

Enterprise Client Configuration

Enabled client surfaces receive a versioned siestaEnterpriseConfig document. It identifies the deployment and Microsoft public client; it must not contain a client secret, certificate private key, token, or authorization code.

{
  "schemaVersion": 1,
  "type": "siestaEnterpriseConfig",
  "workspaceId": "<WORKSPACE_ID>",
  "displayName": "<ORGANIZATION_NAME>",
  "apiBaseUrl": "https://<API_HOST>",
  "frontendUrl": "https://<APP_HOST>",
  "organizationId": "<ORGANIZATION_ID>",
  "microsoft": {
    "tenantId": "<DIRECTORY_TENANT_ID>",
    "clientId": "<APPLICATION_CLIENT_ID>"
  },
  "loginMode": "microsoftOnly"
}

The configuration is available only when private mode is active, the organization has enabled at least one supported app surface, the Microsoft identity provider is enabled with its tenant and client ID, and both application URLs are absolute HTTPS URLs.

The Mobile App can import the configuration from the QR code shown in Profile → Apps & Extensions. Enabled browser and desktop surfaces can download the JSON configuration from the same area. Use the generated file or QR code; do not reconstruct or edit the document manually. Although the file contains identifiers rather than credentials, handle it as deployment metadata and distribute it only through the approved customer channel.

Register each enabled surface before distributing the configuration: Mobile App, Windows App, macOS App, and Browser Extension.

Artifacts and Release Flow

Infrastructure and application delivery are separate reviewed paths that converge on one approved release.

Infrastructure path

1. Pin the versioned Infrastructure as Code package and collect the approved customer inputs.
2. Run syntax and validation checks, then review Azure what-if output for creates, updates, replacements, and deletions.
3. Resolve policy, quota, role-assignment, name-resolution, and placeholder failures before approval.
4. Apply the reviewed package with the approved deployment identity and retain deployment evidence.

See Infrastructure as Code for repeatability, parameter handling, and drift controls.

Application path

1. Select the approved immutable application artifacts for the same release and record their versions and image digests.
2. Transfer the approved images into the customer registry and verify the resulting digests.
3. Update Container Apps and Functions to the approved versions without rebuilding the release in the customer environment unless the implementation agreement explicitly requires it.
4. Run health, identity, data, model, tool, background-processing, and observability checks before promoting the release.

Artifact delivery can use cross-tenant registry import, an approved jumpbox, or another customer-approved route. Whichever route is selected must preserve the source version and digest, separation of duties, approvals, scan evidence, and an auditable transfer record.

Validation, Rollback, and Handover

Do not declare the environment ready from deployment success alone. Record evidence for every applicable gate.

Gate	Minimum evidence before go-live
Inputs, policy, and quota	No unresolved placeholders; required providers and quotas available; policy and regional constraints accepted
DNS, TLS, and private access	Public and private names resolve from the intended networks; certificate chain and hostname are valid; Private Endpoints use the expected DNS zones
Identity and secrets	Managed identities and RBAC are least-privilege and functional; workloads resolve Key Vault references; no secret is embedded in configuration or an image
Artifact integrity	Deployed tags resolve to the approved digests; customer registry pull succeeds; provenance and scan evidence are retained
Workload health	Container and Function startup, readiness and liveness probes, dependency checks, scaling, and restart behavior pass
User identity	Microsoft-only sign-in, tenant restrictions, organization-scoped onboarding, invitations, and any approved group synchronization behave as agreed
Product paths	Chat, retrieval, approved model deployments, agent tools, uploads, and background processing pass representative tests
Operations	Logs, traces, metrics, alerts, dashboards, retention, SIEM forwarding, and support routing are observable by the assigned owners
Recovery	The previous artifact versions and configuration are available; rollback steps and decision authority are recorded; backup restore is tested against the agreed objectives

Use Observability for monitoring evidence and Rollout and Handover for acceptance, runbooks, ownership, and support transition.

Troubleshooting

Symptom	Check first
Microsoft sign-in or redirect fails	Tenant and client IDs, enabled provider, registered redirect for the exact client surface, HTTPS application URL, admin consent, and organization onboarding policy
Enterprise configuration is unavailable	Private-mode activation, organization app-surface switches, enabled Microsoft provider, tenant/client identifiers, and absolute HTTPS frontend/API URLs
Frontend opens but API calls fail	API hostname and TLS, ingress routing, CORS or origin policy, bearer-token audience, API health, and private DNS from the caller's network
A private Azure service is unreachable	Private Endpoint state, subnet policy, private DNS zone links and records, firewall rules, route tables, and approved egress path
A workload cannot pull its image	Customer registry digest, workload identity or registry RBAC, network reachability, tag-to-digest match, and registry policy
Retrieval, ingestion, or background work stalls	Function health, queue or storage access, SQL and Search connectivity, AI service quota, Document Intelligence where used, and diagnostic traces
Infrastructure validation or apply is blocked	Unresolved parameters, Azure Policy, provider registration, permissions, quota, regional availability, and reviewed what-if changes
Rollback or restore does not meet the target	Artifact retention, configuration version, database compatibility, backup integrity, restore permissions, and the latest recorded recovery test

Escalate with the release version, timestamp, correlation ID, affected component, sanitized error, and the checks already completed. Never attach secrets, tokens, private keys, full configuration exports, customer resource inventories, or unrestricted diagnostic archives.