Kamil Mrzygłód

Every team that tests against real Azure services in CI eventually hits the same four problems. You need credentials for the pipeline. Those credentials need to be stored somewhere, rotated, and audited, and if they leak they affect a real environment. The tests themselves become flaky because Azure provisioning has variable latency and your Service Bus namespace occasionally takes three minutes to appear. And if you run on private agents, you need to add networking complexity on top of all of that.

These are not Azure-specific problems. They show up in any pipeline that depends on external cloud services. But the fix for them often is Azure-specific, and the usual answers (use a dedicated test subscription, use Managed Identity, sanitize your test fixtures) treat the symptoms without changing the fundamental structure of the problem.

I wanted to see whether running tests against a local Azure emulator in CI could close those gaps cleanly. The short version is: it can, and the job runs in 38 seconds.

One of the fundamental rules of Topaz is that it must not require sudo or admin rights. There is nothing more frustrating than having to request elevated permissions on your machine just to run a dev tool.

For most Azure CLI operations this is not a problem. You point the CLI at https://topaz.local.dev:8899, it talks to port 8899, done. ROPC login is the exception - az login --username --password triggers a user-realm discovery pre-flight inside MSAL that always targets port 443, regardless of what port you configured in the authority URL. On a non-Docker Topaz install, nothing is listening on port 443, because binding that port requires root. The result is a connection timeout that surfaces as an opaque account-not-found error with no indication that port 443 is involved at all.

This post explains the MSAL assumption behind that behavior, why the straightforward fixes do not work without elevated permissions, and how a built-in HTTP CONNECT proxy on port 44380 closes the gap cleanly.

I had a simple target in mind: open a project, run docker compose up, and have a working local Azure environment — Key Vault, Blob Storage, ARM API. No manual steps on the host machine, no az login, no cloud subscription. Additionally, I wanted to avoid those pesky manual changes in the hosts file like echo 127.0.0.1 topaz.local.dev >> /etc/hosts, that someone will inevitably skip.

It sounds like a two-hour job. It took longer because three things that should be straightforward each had a non-obvious edge case.

I wanted to see whether Topaz could run a real PeekLock consumer, not just accept AMQP frames and pass a basic SDK smoke test. The first MassTransit run failed in two different ways. CompleteAsync waited 60 seconds for a management response that never arrived, and after fixing that, the consumer still stalled after a single message.

That was the point where "supports AMQP" stopped being a useful statement. This post explains what MassTransit was actually doing on the wire, which parts of the protocol Topaz was still missing, and which traces made the root causes obvious.

The concrete examples use MassTransit and the Azure Service Bus SDK for .NET. The AMQP behaviour described applies to any framework driving PeekLock, but the code is C#. If you are not working in .NET, the protocol sections may still be useful context for evaluating any AMQP emulator.

This week in Topaz: Azure App Service lands as a first-class service with Plans and Sites. Virtual Machines gain full CLI coverage. Storage gets end-to-end SAS and stored-access-policy enforcement. Key Vault now handles symmetric AES keys. The Portal grows a live CLI terminal and universal tag editing.

I wanted GitHub Copilot to do more than generate a bash script that calls az group create. I wanted to describe the local Azure stack in natural language and have the assistant provision it while I worked on the application code. Instead of tab-switching to a terminal, remembering the right parameter names, and sequencing five CLI commands in the right order, I wanted the infrastructure to be created directly from the chat, with connection strings returned in a form I could paste into the application configuration.

Topaz ships a Model Context Protocol (MCP) server that makes this possible against the local emulator. The interesting part was not the tool call itself, but getting the container networking, DNS, and certificate setup right so those tool calls returned endpoints that were actually usable. This post covers how the MCP server works, why the Docker networking setup is non-trivial, and what the full setup looks like end to end.

This week in Topaz: Table Storage learns OData, Virtual Networks reach full CRUD, Network Security Groups arrive, Key Vault gets auto-purge, and the repo ships an official Dev Container.

I wanted the "Open in Dev Container" badge for Topaz to do the obvious thing: open the repository in VS Code with the emulator already running, the certificates trusted, and *.topaz.local.dev resolving without any manual setup. That target experience sounds simple. Getting there was not.

The tricky part was not Docker Compose itself. The tricky part was figuring out why workspace mounts were unreliable in Compose mode, how to distribute certificates without depending on bind mounts, and why /etc/resolv.conf kept defeating otherwise reasonable DNS ideas. This post is a technical account of building the Topaz devcontainer, the three services that ended up in the Docker Compose file, and the architecture that finally worked.

This week in Topaz: Key Vault certificates land, Management Groups reach full CRUD maturity, Storage gets Entra ID auth, and the Portal grows a real dashboard.

If you have ever written a line of Azure code on a laptop, you have used Azurite. It is the official local emulator for Azure Storage, ships in every Visual Studio install, and runs unchanged in tens of thousands of CI pipelines. For Storage-only workloads it is an excellent tool. Microsoft maintains it, Azure SDKs target it, and the parity with the real Azure Storage REST API is strong.

The problem is that real applications stop at Azure Storage roughly never. The moment you reach for a secret in Key Vault, publish a message to Service Bus, push an image to a Container Registry, or want a DefaultAzureCredential chain that does not silently fall back to interactive browser auth, Azurite has nothing to offer. You are left bolting together a Service Bus emulator from a community Docker image, mocking the Key Vault SDK in tests, and hoping that the way your CI fakes Entra tokens does not drift away from how production behaves.

Topaz is a single .NET 10 binary that emulates Azure Storage, Key Vault, Service Bus, Event Hubs, Container Registry, Managed Identity, RBAC, ARM, and a working Entra ID layer in one process. This post is an honest comparison between the two, focused on what developers who already know Azurite actually run into.