Skip to content
HomeFabric Emulator

Overview

A local Microsoft Fabric: the control plane, OneLake, and engines that genuinely run your code. Workspaces, items and their CI/CD definitions, workspace RBAC, git integration, jobs and the 202/poll long-running-operation contract — validating Microsoft Entra bearer tokens against entra-emulator exactly as real Fabric validates against Entra. The same pipeline runs unmodified here and against a real tenant (FABRIC_TARGET).

It computes. docker compose up attaches Sail and a SQL Server sidecar: a notebook runs on Spark and writes Delta to OneLake, a warehouse query executes over a real TDS connection, and KQL runs on Microsoft’s own Kusto engine. Microsoft’s own tools drive it — fabric-cicd, the Fabric CLI, dbt-fabric, the Terraform provider, the VS Code extension — with no capacity and no cloud tenant.

The gap this is built around

Section titled “The gap this is built around”

Testing Fabric work against Fabric means a tenant, a capacity and a cloud round trip for every iteration. A capacity is shared and always on, so a pull request cannot have one of its own, and a workspace is shared state, so one run’s cleanup is another run’s broken fixture. The usual outcome is that the Fabric-specific parts (the deployment pipeline, the OneLake writes, the notebook that only fails on real data) are the parts nobody tests until they break in someone else’s run.

This puts the whole tenant on a laptop: up in seconds, offline, torn down and recreated per test. What it cannot do is assert that it behaves like Fabric, which is why every supported claim below names the test that witnesses it, and the known differences are written down rather than left to be discovered.

Start here

Section titled “Start here”
  • Quickstart — compose up the family, mint a token, create a workspace, write to OneLake
  • Installation — brew, winget, go install, Docker, compose
  • Tutorial — a medallion pipeline end to end, bronze through gold
  • Running modes — default stack, lite, JVM overlay, profiles, optional DAX oracle
  • Architecture — the emulator family, token acceptance, the LRO engine

What it runs

Section titled “What it runs”

How the claims are checked

Section titled “How the claims are checked”

Parity here is not self-assessed. Every supported capability names the test that witnesses it, CI fails if one loses its witness, and the strongest witnesses are third-party clients rather than our own tests.

Going further

Section titled “Going further”