How infrastructure scale and environment count grow as you move from evaluation to enterprise production — without re-architecting the platform.
Purpose
Architects and platform operators use this page to plan capacity and separation — sizing presets at tenant activation, additional environments for promotion, and scale-out patterns. This is product and operating guidance, not a SKU price list. Your Marketplace offer and Azure region determine exact resources.
Pair with Tenant activation wizard (size selection step) and Evaluation guide.
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 is not a substitute for governance — full Operational Trust capabilities apply at every preset.
Environment progression
Environments isolate change risk. Integrations and policy promote across them — they do not share live credentials blindly.
Phase 1 — Evaluation
Single environment (dev or dedicated pilot)
Full governance + certification at pilot scope
Phase 2 — Initial production
Dev + Prod (or Dev + Staging + Prod per your naming)
Formal promotion for manifests, protection, Role Assistant config
Phase 3 — Enterprise scale-out
Dev + Test + Prod (standard three-environment model)
Shared metadata standards; multiple systemKeys and workers
| Phase | Environments | Sizing | Primary goal |
|---|---|---|---|
| Evaluation | 1 | S (sometimes M if perf testing required) | Prove model with real identity and data |
| Initial production | 2 | S or M | Controlled production for one team/domain |
| Enterprise platform | 3+ | M / L / XL | Shared platform for many teams and use cases |
Environment keys (dev, tst, pro) must match Builder CLI and controller configuration — integrators target the correct environment on every upload and certification run.
What scales with size
| Component | Scales with preset / env count |
|---|---|
| Controller (Miso) | Policy, identity, deployment governance |
| Dataplane | Sync volume, governed search, CIP execution, MCP traffic |
| Integrations | Number of systemKeys and datasources — not duplicated per worker |
| Role Assistants | Concurrent tasks and evidence volume |
| Azure backing services | Compute, storage, networking — billed in your subscription |
Adding environments increases operational surface (promotion, secrets, certification per env) — not necessarily linear Azure cost.
Scale-out without rework
- Same integration manifests — promote via upload/deploy to next environment after certification in prior env
- Same business roles and dimensions — standardize keys before onboarding team two
- Re-certify after change — vendor API, protection, or policy changes trigger certification again
- Resize when metrics demand — CPU, sync latency, worker queue depth — via platform team process (not ad-hoc VM edits in docs)
Avoid “PoC shortcuts” (admin-only tests, skipped protection) that cannot transfer to production sizing.
Governance maturity vs infrastructure
Infrastructure size does not replace governance maturity:
| Maturity | Infrastructure | Governance behavior |
|---|---|---|
| Experimental | S, one env | Certification at pilot scope; limited subjects |
| Controlled adoption | S/M, two envs | Promotion rules; scoped production users |
| Enterprise platform | M/L/XL, three envs | Standard metadata; reuse integrations |
| Regulated optimized | L/XL, hardened network | ABAC, evidence reporting, cost/risk managed |
See Adoption roadmap for activity sequencing; KPI framing belongs with operator and executive adopt pages.
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.