I recently read this post from my colleague Marnix on using Dev Containers to isolate your service logins for a project . This is especially useful for Azure and GitHub accounts, as they are configured per system in the ~/.azure and ~/.config/gh folders.
As a consultant, I’m often hopping between multiple customers. Even someone working solely for one company might have side projects in different environments. This system configuration is often suboptimal and requires you to think about where you’re logged in and switch around. Marnix has done a great job describing why Dev Containers are a great solution to this problem, so I won’t repeat that here.

One annoying aspect is working with worktrees. Currently, coding agents default to Git worktrees, so you can work on multiple things at the same time without conflicts. This is great, but they create a copy of the repository in a random folder. This also creates a new Dev Container for you to use, which means you have to log in again. Having to log in to every Dev Container is quite cumbersome, and I don’t like that.
What I want is a shared login for my repositories that works for all the worktrees I have.
After playing around with this feature, I found out that this is quite possible!

The project I’m working on is in a maturing state. This means it needs to remain stable while still delivering new features. This is where feature toggles come into play. By adding these toggles and conditional execution paths to your code, you can keep the functionality unchanged until you turn a toggle on and then return to the previous behavior by turning it off again.

In the Azure ecosystem, we have the App Configuration resource with fairly basic feature toggle capabilities, so that’s what I’m using because it fits our current needs.

July 2026 update

There is no need to create your own App Configuration emulator image for macOS anymore.
The team has pushed an official image to the MCR .

https://mcr.microsoft.com/en-us/artifact/mar/azure-app-configuration/app-configuration-emulator/tags amd64 arch image has been released!

Setup in Aspire

For ease of local development, we use Aspire. To enable App Configuration, you’ll need the Aspire.Hosting.Azure.AppConfiguration package.
This lets you add a new resource to the AppHost: var appConfig = builder.AddAzureAppConfiguration("config");.

On your local machine, you probably don’t want to use an actual Azure resource, but an emulator. This can be configured using these lines of code:

appConfig.RunAsEmulator(emulator =>
{
    emulator.WithLifetime(ContainerLifetime.Persistent);
    emulator.WithDataVolume();
});

This works like a charm on Windows.
If you’re on Apple Silicon, like I am, it won’t.