Deployment and control for an Enterprise Architect: where AI Fabrix actually runs, who controls what, and how infrastructure scale and environment count grow from evaluation to enterprise production — without re-architecting the platform.
For a local Docker installation, use Set up a local platform. The Azure resource and Key Vault descriptions below apply to that deployment model; they are not local Docker prerequisites.
Purpose
This page closes the Architecture overview's question of what runs in your Azure tenant and what stays under your control. Identity, secrets, network boundaries, and environment lifecycle come first; sizing presets and capacity planning are supporting detail for architects and platform operators, not the main story.
Pair with Tenant activation wizard (size selection step), Azure services created, and Evaluation guide.
Where AI Fabrix runs, and who controls what
In the Azure Marketplace deployment described here, AI Fabrix's governed foundation is deployed into your own Azure subscription — not a shared AI Fabrix runtime tenant. Azure Marketplace provisions the platform's resource group, application services, database, storage, key vault, and networking directly there; see Azure services created for the resource list. There is no separate AI Fabrix-hosted environment that your data, identities, or Evidence pass through to reach the platform:
- Customer data and system-of-record content stay in your connected enterprise systems and the platform database/storage deployed in your subscription — not copied into a shared AI Fabrix tenant.
- Governed state — the Enterprise Reality, Enterprise Knowledge, and Process Execution state described in Architecture overview and Process Execution Output — is held in that same customer-owned deployment.
- Identities and Evidence stay yours (see below) — not a parallel AI Fabrix store or export target.
Deployment itself is a customer action, not a vendor-operated rollout: your cloud team approves the subscription, region, and sizing parameters at Marketplace deploy time, then completes tenant activation to bring the tenant to ACTIVE — see Azure Marketplace installation for the sequence. From that point, you control the subscription, resource group, network placement, and administrator accounts; AI Fabrix controls platform behavior behind that boundary — the certification, protection, and runtime rules in Trust boundaries and Capability gateway — not the infrastructure it runs on. Environment promotion and re-certification after change stay your platform team's process, not an automatic vendor action.
Identity, secrets, and network boundaries
AI Fabrix connects to your existing identity provider (typically Microsoft Entra ID) instead of creating a separate user store — see Authentication for trust for how human, platform, and Connected System credentials stay apart. In an Azure deployment, Key Vault holds configured platform and Connected System secrets. Credential ownership matters: deployment may generate local service credentials, while issuer-owned signing material must come from its authorized issuer. A public verification key does not grant authority to mint issuer credentials. Keep secret values out of public outputs and AI context. A virtual network and subnets isolate deployed services from public exposure by default — exact topology depends on your deployment configuration and Azure landing-zone standards. This is the architecture-level boundary, not a security runbook.
Environment lifecycle and promotion
Environments isolate change risk and progress through the same three phases across deployments:
| Phase | Environments | Sizing | Primary goal |
|---|---|---|---|
| Evaluation | 1 (dev or dedicated pilot) | S (sometimes M if perf testing required) | Prove model with real identity and data; full governance and certification at pilot scope |
| Initial production | 2–3 (Dev + Prod, or Dev + Staging + Prod) | S or M | Controlled production for one team/domain; formal promotion for manifests, protection, Role Assistant config |
| Enterprise platform | 3+ (standard Dev + Test + Prod) | M / L / XL | Shared platform for many teams; shared metadata standards, multiple integrations and workers |
Promotion carries governed definitions forward — integration manifests, protection rules, Role Assistant configuration — after certification in the prior environment. It does not carry live credentials forward: each environment holds its own secrets and re-certifies after material change (vendor API, protection, or policy updates) — see Validation and certification.
Platform application updates also preserve the environment boundary. Missing
declared settings may be added, while an existing installation value that
differs from the application default is held for operator review. The update
preview identifies those held names without exposing their secret values. This
lets a platform team distinguish an intended application default from an
installation-owned choice before deployment. Retain the resulting installed
image from deployment status as promotion evidence; a requested tag by itself
does not identify the image that actually ran.
Sizing presets (tenant activation)
During activation you choose a sizing preset aligned with expected load (labels vary by offer; commonly small through extra-large).
| Preset | Typical use | Characteristics |
|---|---|---|
| Small (S) | Evaluation, single-team pilot, low concurrent workers | Minimal compute; sufficient for certification ladder |
| Medium (M) | Initial production for one domain | Headroom for sync, search, and Role Assistant tasks |
| Large (L) | Multi-team production | Higher throughput for dataplane and orchestration |
| Extra-large (XL) | Enterprise scale-out | Multiple integrations, many workers, heavy sync |
Guidance: Start at S for proof-of-concept only if performance stays acceptable under real sync and governance tests. Move to M before declaring production for a business domain. Sizing scales controller policy/identity workload, dataplane sync and CIP execution, and Role Assistant concurrency together — Azure backing services are billed in your subscription. It is not a substitute for governance: the same certification and protection rules apply at every preset, and adding environments grows operational surface — more promotion steps, more secrets to manage, more re-certification events — without requiring a different platform architecture.
Scale-out reuses the same integration manifests, business roles, and dimensions rather than redefining them per team or environment; resize when metrics (CPU, sync latency, queue depth) demand it, via your platform team's process. Avoid "PoC shortcuts" (admin-only tests, skipped protection) that cannot transfer to production. See Adoption roadmap for how governance maturity progresses alongside infrastructure over time.
Limits
- Exact vCPU, memory, and Azure SKUs depend on Marketplace offer version and region — confirm in deployment outputs and your platform team runbook.
- This page does not replace Azure Well-Architected or your landing-zone standards.
- Edition or licensing names on invoices may differ from preset labels in the wizard UI.
- Installed-image reporting depends on the deployment path returning a concrete
provider image reference. Treat a missing reference as incomplete deployment
evidence and verify it through the platform team's approved environment tools.