Getting started

Three doors in. Pick by what you are building.

Each repo carries its own authoritative quickstart, so this page routes rather than duplicates: a command copied here would drift from the repo that owns it.

Door 1: the Azure family, in one command

The certified Azure set: six emulators, pinned and chain-tested together. Start here if you are building an application that needs identity, authorization or secrets.

git clone https://github.com/calvinchengx/azure-emulators
cd azure-emulators
docker compose up                        # entra + keyvault + arm
docker compose --profile fabric up       # ...and fabric
docker compose --profile apim up         # ...or apim
docker compose --profile databricks up   # ...or the Databricks workspace

The compose defaults are the bill of materials, a combination of released images chain-tested together. A bare docker compose up runs exactly that set.

“The family” means those six, not every emulator here. The line is bill-of-materials membership: an emulator is in it when its version is pinned in this compose, gated by the pins check and exercised by the chain test. snowflake-emulator keeps the same discipline (graded ledger, witness manifest, checker enforcing both) and is deliberately outside it, so it does not appear in this door. Emulators outside the Azure BOM run standalone through Door 2, which is where any future non-Microsoft one will arrive too. The adjacent one makes the full argument.

ARM governs the vault, as it does in Azure: role assignments decide who may do what, and no assignment means no access. The stack seeds what the portal gives you when you create a vault, so the quickstart works without hand-writing a role assignment.

State persists. up, down, up keeps your data. down -v is the reset, and it is the command to give an agent between attempts.

Full detail: azure-emulators docs.

Door 2: one emulator

Nothing requires the family, and not every emulator is in it. Each ships its own image and its own quickstart, and the single-service cases are real:

You are working on	Run
Sign-in, tokens, MSAL, protected APIs	entra-emulator
Role assignments, scopes, revocation	arm-emulator with entra
Secrets, keys, certificates	azure-keyvault-emulator
APIM policies and the gateway	azure-apim-emulator
Fabric workspaces, items, OneLake	fabric-emulator
Databricks jobs and workspace REST	databricks-emulator
Snowflake SQL and account objects	snowflake-emulator, outside the Azure BOM, so it runs standalone rather than through Door 1

entra-emulator is the highest-value one to adopt first, because identity is usually the first thing that blocks local development.

Door 3: a working data product

One product, seven cells of engine × orchestrator, and one command that knows which repositories make a cell, which verb runs it and which port it answers on. It reads all three from the registry, so it cannot be wrong about any of them, and it refuses a third stack because the Docker VM this was measured on holds two.

git clone https://github.com/calvinchengx/emulators
cd emulators
./family ls                          # every cell, its two repos, its ports
./family up fabric-airflow3          # tells you which siblings to clone, if any
./family witness fabric-airflow3     # the medallion, exit 0 only if the numbers hold
./family down fabric-airflow3

A cell is <engine>-<orchestrator>; naming either of its repositories means the same thing. ./family ps says what is running and whose it is. The emulators answer the same verbs on their own: ./family up entra-emulator.

What each cell demonstrates is in the matrix. Every platform takes PRODUCT=<path> and holds no product logic of its own, which a test in each enforces; the pieces they compose are contoso-sources for the vendor systems and contoso-data-product for the transforms, contracts and expected numbers.

Pointing an AI agent at this

Give the agent four things and it will mostly look after itself:

1. The stack and the reset. docker compose up and docker compose down -v. The reset is what stops one corrupted run from poisoning the next twenty.
2. The parity ledger for whichever emulator it is working against (docs/parity.md in that repo). When it hits a wall, the first question is whether the surface exists, and the ledger answers that in seconds.
3. The chain test, e2e/chain/run.py in azure-emulators: a worked example of the whole trust chain in one readable Python file.
4. The real-tenant switch in configuration from day one, not as a port at the end.

More on this in Building with AI agents.

Moving to real Azure

By design, nothing you build is emulator-specific. Point the issuer variables at your tenant instead of https://entra-emulator:8443/<tenant>/v2.0, set the platform’s target flag to the real service, and the rest is unchanged. That is the constraint the platform repos exist to prove.