Skip to content

Deployment (June 2026)

Archived 2026-10-09

This June-2026 narrative page was superseded by the rewritten page at planes/execution/environments/deployment.md. Deployment, manifest, GitOps sync, drift, scaling, pool and runtime-catalog services became one provisioning owner with plan/apply receipts and reconciliation proposals, an observed-state inventory, and execution capacity with pools, quotas and leases. It is kept for provenance.

Historical — archived

This page is kept for provenance. Its dates, targets and technology statements are not current direction. See the linked replacement page.

Reviewed 2026-10-09

Target; the Factory provisions nothing yet; each repository's pipeline runs its own Pulumi program (ADR-0004, verified).

Target Architecture — Final-State Design

The topology below describes how generated SaaS runtimes are deployed and operated across Azure compute surfaces. All infrastructure is declared as Pulumi (.NET/C#) programs, planned and applied by RuntimeEnvironmentService and reconciled by the DriftDetectionWorker.

Runtime Topology

Each generated component is placed on the Azure compute surface that fits its workload shape:

Component Compute Surface Rationale
Generated API Gateway AKS (ingress) / Azure Container Apps Stable, scalable HTTP front door
Backend Microservices AKS node pools Long-running, high-throughput, mesh-integrated
Workers Azure Container Apps / Azure Functions Event-driven, scale-to-zero capable
Admin & Customer Portals Azure App Service Managed web hosting for Blazor/MFE front ends
Mobile App backends AKS / Container Apps Shared API surface for MAUI clients
Scheduled / bursty jobs Azure Functions Consumption-based, event/timer triggered

Topology Diagram

flowchart TB
    subgraph Region["Azure Region (per environment)"]
        subgraph AKS["AKS Cluster"]
            SysPool["System Node Pool"]
            AppPool["App Node Pool (microservices)"]
            GWPool["Gateway Node Pool (ingress)"]
        end
        subgraph ACA["Container Apps Environment"]
            WorkerApps["Worker Container Apps"]
        end
        subgraph Func["Azure Functions"]
            JobsFunc["Scheduled / Event Functions"]
        end
        subgraph AppSvc["Azure App Service Plan"]
            Portals["Admin & Customer Portals"]
        end
        subgraph Data["Data & Messaging"]
            SQL["('Azure SQL / PostgreSQL')"]
            Cosmos["('Cosmos DB')"]
            Bus["('Azure Service Bus')"]
            Blob["('Azure Blob')"]
        end
        KV["('Azure Key Vault')"]
        AppI["('Application Insights')"]
    end
    ACR["('Azure Container Registry')"] --> AppPool
    ACR --> GWPool
    ACR --> WorkerApps
    GWPool --> AppPool
    AppPool --> Data
    WorkerApps --> Bus
    JobsFunc --> Bus
    Portals --> GWPool
    AppPool --> KV
    WorkerApps --> KV
    AKS --> AppI
    ACA --> AppI
    Func --> AppI
    AppSvc --> AppI
Hold "Alt" / "Option" to enable pan & zoom

Scaling

  • AKS — Horizontal Pod Autoscaler and KEDA scalers driven by ScalingPolicy; cluster autoscaler grows/shrinks node pools; gateway and app pools scale independently.
  • Container Apps — built-in HTTP/queue-based scaling rules, including scale-to-zero for idle workers.
  • Functions — consumption/elastic-premium scaling for event and timer triggers.
  • App Service — autoscale rules per plan for portal traffic.
  • All scaling is governed by ScalingPolicy aggregates and enforced by the ScalingPolicyWorker against live Application Insights metrics.

Configuration

  • Runtime configuration is delivered as versioned RuntimeConfiguration and synced by the ConfigurationSyncWorker (e.g. AKS ConfigMaps, Container Apps env vars, App Service settings).
  • Configuration is immutable per version and never contains secret values — only SecretBinding references.

Secrets

  • Secrets are resolved at runtime from Azure Key Vault via managed identity (AKS workload identity; system/user-assigned identities elsewhere).
  • The SecretRotationWorker rotates on schedule; bindings refresh without redeploy.

Health Checks

  • Every workload exposes liveness/readiness/dependency probes via ConnectSoft.Extensions.Diagnostics.HealthChecks.
  • AKS/Container Apps use these probes for traffic gating; RuntimeHealthService aggregates them into HealthCheckResults that gate deployment promotion.

Multi-Region

Target Architecture — Final-State Design

Multi-region is a first-class option of the environment model. A RuntimeEnvironment carries a region; production workloads can be provisioned across paired Azure regions for resilience.

  • Active-passive — primary region serves traffic; a paired region is provisioned and kept warm via the same Pulumi program, promoted on failover.
  • Active-active (selected workloads) — traffic distributed via Azure Front Door / Traffic Manager, with data replicated (Azure SQL geo-replication, Cosmos DB multi-region writes).
  • Drift detection runs per region; tenant data residency is honoured per RuntimeTenantBinding (a tenant's region constrains placement).

Self-Hosting Note

The platform's own 9 services are deployed the same way they deploy generated workloads — as containerized .NET 10 services on AKS/Container Apps, provisioned by Pulumi, observed via Application Insights — so the platform operates itself with the exact mechanisms it offers.