Skip to main content
Kamil Mrzygłód
Topaz maintainer & contributor
View all authors

Topaz Weekly Pulse #5: Azure App Service, Virtual Machines, Storage SAS security, Key Vault AES keys, and a live Portal terminal

· 6 min read
Kamil Mrzygłód
Topaz maintainer & contributor

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.

Using Topaz with GitHub Copilot via MCP Server

· 12 min read
Kamil Mrzygłód
Topaz maintainer & contributor

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.

Building a devcontainer for Topaz: workspace mounts, DNS wildcards, and why /etc/resolv.conf always wins

· 13 min read
Kamil Mrzygłód
Topaz maintainer & contributor

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.

Topaz vs Azurite: what actually works locally and what doesn't

· 22 min read
Kamil Mrzygłód
Topaz maintainer & contributor

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.

Two days chasing a SharedKey signature mismatch: how we fixed azurerm_storage_table_entity in Topaz

· 10 min read
Kamil Mrzygłód
Topaz maintainer & contributor

Some bugs announce themselves loudly. A null pointer in a hot path, a missing route that returns 404 to every request — the kind of thing that fails immediately and points straight at the cause. Others are quieter. They let most of the stack work correctly and only reveal themselves at the intersection of two independently correct but mutually incompatible assumptions. The azurerm_storage_table_entity failure was the second kind.

This post is an account of a two-day investigation into a persistent 401 Unauthorized response on Terraform table entity operations, the four separate bugs we found along the way, and how pairing with GitHub Copilot shaped the investigation. The fix touched authentication, HTTP routing, upsert semantics, and stream lifecycle — each uncovered only after the previous one was resolved.

Cancelling ARM deployments in Topaz — what it means for an emulator

· 5 min read
Kamil Mrzygłód
Topaz maintainer & contributor

Cancelling an in-progress deployment is one of those ARM operations that looks simple from the outside — you POST to a /cancel endpoint and the deployment stops. Under the hood, what "stop" means depends entirely on whether the engine executing the deployment can be interrupted mid-flight. In a real emulator, that question has a more nuanced answer than in the real Azure control plane.

This post walks through how Topaz implements POST .../deployments/{name}/cancel, what constraints the orchestrator model imposes, and where the emulation intentionally diverges from Azure's behaviour.

Topaz Weekly Pulse #1: Major Storage milestones and cleaner automation workflows

· 5 min read
Kamil Mrzygłód
Topaz maintainer & contributor

This week in Topaz: from page blobs to health-checked host orchestration.

This is the first post in a new weekly series: Topaz Ship Log.

Each edition is a concise, case-by-case summary of what changed in Topaz during the week, why it matters, and what it unlocks for local Azure development. This first issue covers the last 7 days of work.

Star on GitHub