Tech blog by Tobias Fenster

Using Docker Sandbox Kits

Thu, 21 May 2026 10:24:07 +0000

Have you ever felt the urge to just let your AI agents run in YOLO mode, but been too much of a responsible adult to do that? Or seen that new MCP Server with the tempting functionality that is just an npx call away from being used, but some security training (or actually common sense) told you that this isn’t such a great idea? Not sure what that says about my character, but I certainly have. It’s really tempting to let those agents just do their thing and pull in all the MCPs you can get to make them more poweful, but do I really want to give them access to my machine, let them run scripts on it, control my containers, have access to credentials, send data to whereever? Or let one of those claws run my business or personal life with access to all my credentials? Actually, that’s a hard no.

So what can I do? Fortunately, Docker came up with a cool new technology to safeguard against those issues and keep the AI in check: Sandboxes (and Sandbox Kits, but more on that later).

The TL;DR

First let me show you how that actually works. Safety often comes at the price of increased complexity and decreased efficiency, so I want to show you how it easy it is to use Sandboxes, improved with Kits, to set up an environment that GitHub Copilot can securely use to develop for Dynamics 365 Business Central and get input from Azure DevOps. My point is not that Copilot can do that¹, but how easy it is to set up an environment dramatically ramping up the security of that approach, so I’ll only show the initialization and proof that the interactions work:

So why is this more secure? Check out the official docs linked above, but in a nutshell: You get to run your agent with MCPs and whatever else it might use in a hardened micro-VM, which means that it doesn’t have access to the filesystem (other than the workspace), environment or Docker daemon on your host. It also has networking policies, blocking access to everything you don’t allow and it has a very cool feature to inject credentials in a way so that they are not visible inside the micro-VM. If you want to learn more, check the following details. There I will be using Kits as you can also see with the --kit parameters in the video above, which are one way to customize Sandboxes (another is Templates, more on that potentially in another blog post).

The details: Why more secure - networking

To illustrate the networking part, I want to show you the first kit I am using. It enables the usage of the AL MCP Server through the ALTool provided by Microsoft:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
schemaVersion: "1"
kind: mixin
name: al
displayName: al
description: altool installation

network:
  allowedDomains:
    - dot.net
    - ci.dot.net
    - builds.dotnet.microsoft.com
    - api.nuget.org
    - "**.lencr.org"
    - fps-alpaca.westeurope.cloudapp.azure.com

commands:
  install:
    - command: "curl -fsSL https://dot.net/v1/dotnet-install.sh | bash -s -- --channel 8.0 && /home/agent/.dotnet/dotnet tool install --global Microsoft.Dynamics.BusinessCentral.Development.Tools"
      user: "1000"
      description: Install altool

I want to focus on the network part (lines 7-14): Here you can see that I need to give it access to a few dot.net and microsoft.com URLs as we first need to install dotnet 8 (more on installation in another detail chapter). Then we need nuget.org access to install the ALTool as it is provided as dotnet tool. And to interact with my Business Central instance running on COSMO Alpaca, the agent also has to reach the fps-alpaca… URL. The tricky one was the **.lencr.org as I ran into SSL errors. Those were caused by dotnet checking the validity of the Let’s Encrypt certificate also against online revocation lists, so I had to enable that as well.

Now why is this relevant: With this you make sure that an agent (potentially running in YOLO mode) isn’t up- or downloading secrets, information, scripts or whatever might be harmful to and from sources and targets that you don’t approve. It requires a bit more work to set it up, but makes it way more secure!

On a side note, Sandboxes come with three predefined policies for networking: “open”, which allows everything (in case you don’t want to use the feature); “balanced”, which blocks everything by default, but has some typical and trusted dev sites enabled (e.g. the basics you need for GitHub Copilot, Claude, etc.); and “locked down”, which just blocks everything. I have started with balanced, so I only had to take care of the special demands of my workload.

The details: Why more secure - credentials

For the second feature I want to highlight, credential injection, here is my second kit, which enables access to the Azure DevOps MCP:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
schemaVersion: "1"
kind: mixin
name: az-devops
displayName: az-devops
description: Azure DevOps

network:
  allowedDomains:
    - "**.dev.azure.com"
    - "**.visualstudio.com"
  serviceDomains:
    4psnl.visualstudio.com: az-devops
    dev.azure.com: az-devops
    mcp.dev.azure.com: az-devops
  serviceAuth:
    az-devops:
      headerName: Authorization
      valueFormat: "Basic %s"

credentials:
  sources:
    az-devops:
      env:
        - AZ_DEVOPS_PAT

environment:
  proxyManaged:
    - AZ_DEVOPS_PAT
    
commands:
  install:
    - command: "mkdir /usr/local/share/npm-global/lib"
      user: "1000"
      description: Create missing folder

First, you see the by now familiar network part with allowedDomains (lines 7-10), in this case allowing access to the “new” dev.azure.com and old visualstudio.com domains used for Azure DevOps. Now for the part required for credential injection:

First, we define serviceDomains (lines 11-14). Those are domains where we want credentials to be injected. So whenever a call is made to 4psnl.visualstudio.com, dev.azure.com or mcp.dev.azure.com, the az-devops configuration is used.
Second, we define the serviceAuth (lines 15-18), referenced in the serviceDomains. Here you can see the definition of the name of the header and how the value is to be formatted. The %s is replaced by a secret we define later on the host.
Third, we need to configure where the credential is coming from in the credentials (lines 20-24), in this case pointing to an env variable
As last step, we define the environment (lines 26-28), letting it know that it should come from a proxyManaged variable called AZ_DEVOPS_PAT

Now where is the actual value coming from? I ran this little one-liner on the host²:

1
echo "$([System.Convert]::ToBase64String([System.Text.Encoding]::ASCII.GetBytes("tfenster@4psbau.de:ep75nho5o3p727ezkwy4jsyjr4g6qkepyaqalwivmgcgrdhm5o5q")))" | sbx secret set -g az-devops

This defines the authentication token I want to use for the service, which will be injected into all traffic going to the domains configured above. That enables me to do something like this in my MCP configuration inside of the Sandbox:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
{
  "mcpServers": {
    "az-devops": {
      "type": "stdio",
      "command": "npx",
      "args": [
        "-y",
        "@azure-devops/mcp",
        "4psnl",
        "--authentication",
        "pat"
      ],
      "env": {
        "PERSONAL_ACCESS_TOKEN": "don't think so"
      }
    }
  }
}

You can see in lines 10 and 11 that I am using a token (PAT = personal access token) for authentication, but I am not atually providing the token as you see in line 14. Instead, the Sandbox networking stack injects the token correctly, so I never need to share it with the MCP and it never is visible from within the Sandbox. Really nice, right?

The details: Another aspect of Sandbox Kits - installs

The last feature in Sandbox Kits I want to mention is the install section below commands, which covers things that run once at creation. There are also startup commands, which run on every startup, but I haven’t used those. The installs that I have used are for the MCPs and on the AL MCP, it’s a bit more complicated, as we first need dotnet and then install the ALTool via dotnet tool install:

1
2
3
4
5
commands:
  install:
    - command: "curl -fsSL https://dot.net/v1/dotnet-install.sh | bash -s -- --channel 8.0 && /home/agent/.dotnet/dotnet tool install --global Microsoft.Dynamics.BusinessCentral.Development.Tools"
      user: "1000"
      description: Install altool

As you can see, we can also set the user (ID) and description.

On the Azure DevOps MCP, the installation is actually done through the npx command in .mcp.json shown above, but that failed because of a missing folder. I could easily mitigate that with an install as well:

1
2
3
4
5
commands:
  install:
    - command: "mkdir /usr/local/share/npm-global/lib"
      user: "1000"
      description: Create missing folder

As you can see, this gives you all the flexibility you might need for setting up your toolchain and it also makes sure you get a very stable, reproducable environment.

The details: Claws…

An interesting aspect of the security model of Sandboxes, not connected to Kits, is that they run in micro-VMs, as explained in the beginning. One of the key reasons for that instead of running inside of a container is that some agents want to spin up containers, so Sandboxes need that ability to do that. But if they had access to the Docker daemon on the host, that would also give them access to other containers, again something that would create a security risk. Therefore, every Sandbox gets its own daemon inside of the micro-VM, not exposing any of the other containers potentially running.

That enables a very secure environment also for personal assistants like nanoclaw. Therefore, it was a great fit and as you can see here, that triggered a collaboration. I found it very interesting to see how a setup mostly aimed at developer security and productivity also is such a nice solution for a personal assistant, which is why I also wanted to mention that here.

you’ve seen that more than enough times by now, right? ↩
Don’t worry, this isn’t my real token ↩

Easier network access for AI Runway

Sat, 25 Apr 2026 08:06:54 +0000

I recently blogged about using AI Runway, but the networking setup was not ideal. The reason for that was that I couldn’t get the setup recommended by the AI Runway team up and running, but with their help I could figure it out. Therefore, this is just a small update on how that works.

The TL;DR

In the previous blog post, I created a dedicated Traefik ingress per model, which is of course not ideal. Instead, having a single gateway with the Gateway API Inference Extension which addresses the right model based on the request makes sense and that is also what the AI Runway docs suggest. With that in place and Llama-3.2:1B deployed, something like this works where 20.170.89.88 is the IP of the gateway

Request

1
2
3
4
POST http://20.170.89.88/v1/chat/completions
Content-Type: application/json

{"model": "llama-3.2-1b-instruct", "messages": [{"role": "user", "content": "who are you?"}]}

Response

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
HTTP/1.1 200 OK
x-envoy-upstream-service-time: 1391
x-went-into-resp-headers: true
content-type: application/json
x-correlation-id: d691d871-689c-48c3-a2af-a7a3eef237c0
date: Sun, 26 Apr 2026 09:14:16 GMT
server: istio-envoy
connection: close
transfer-encoding: chunked

{
  "choices": [
    {
      "finish_reason": "stop",
      "index": 0,
      "message": {
        "content": "I'm an artificial intelligence model known as Llama. Llama stands for \"Large Language Model Meta AI.\"",
        "role": "assistant"
      }
    }
  ],
  "created": 1777194855,
  "id": "d98279a5-6588-464a-8245-40e20b4a9220",
  "model": "llama-3.2-1b-instruct",
  "object": "chat.completion",
  "usage": {
    "completion_tokens": 23,
    "prompt_tokens": 15,
    "total_tokens": 38
  }
}

This might look similar to before, but I can now also deploy e.g. Gemma2:2B and do something like the following. Note that only the model in the request body changes

Request

1
2
3
4
POST http://20.170.89.88/v1/chat/completions
Content-Type: application/json

{"model": "gemma-2-2b-instruct", "messages": [{"role": "user", "content": "who are you?"}]}

Response

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
HTTP/1.1 200 OK
x-envoy-upstream-service-time: 16533
x-went-into-resp-headers: true
date: Sun, 26 Apr 2026 09:16:58 GMT
content-type: application/json
x-correlation-id: da4973c9-721d-46fb-b237-b420e805b6ca
server: istio-envoy
connection: close
transfer-encoding: chunked

{
  "choices": [
    {
      "finish_reason": "stop",
      "index": 0,
      "message": {
        "content": "I am Gemma, an open-weights AI assistant. I'm a large language model, created by the Gemma team. I can generate text, translate languages, write different kinds of creative content, and answer your questions in an informative way. \n\nThink of me as a friendly AI companion who loves to chat and explore ideas with you!  😊  \n",
        "role": "assistant"
      }
    }
  ],
  "created": 1777195003,
  "id": "ddefa22d-70df-4e14-8c94-8f2a3684446c",
  "model": "gemma-2-2b-instruct",
  "object": "chat.completion",
  "usage": {
    "completion_tokens": 74,
    "prompt_tokens": 13,
    "total_tokens": 87
  }
}

Nice, right? As the setup is actually straight forward and it was more a failure on my side to do it right (and a small issue in AI Runway) that prevented it from working last time, there are not a lot of details to share. But if you want a step by step instruction on how to set it up, check the next section.

The details: Istio and body-based router

First we need the Gateway API and the Inference Extension as explained above:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
PWSH C:\Users\tobia> kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/latest/download/standard-install.yaml
customresourcedefinition.apiextensions.k8s.io/backendtlspolicies.gateway.networking.k8s.io created
customresourcedefinition.apiextensions.k8s.io/gatewayclasses.gateway.networking.k8s.io created
customresourcedefinition.apiextensions.k8s.io/gateways.gateway.networking.k8s.io created
customresourcedefinition.apiextensions.k8s.io/grpcroutes.gateway.networking.k8s.io created
customresourcedefinition.apiextensions.k8s.io/httproutes.gateway.networking.k8s.io created
customresourcedefinition.apiextensions.k8s.io/listenersets.gateway.networking.k8s.io created
customresourcedefinition.apiextensions.k8s.io/referencegrants.gateway.networking.k8s.io created
customresourcedefinition.apiextensions.k8s.io/tlsroutes.gateway.networking.k8s.io created
validatingadmissionpolicy.admissionregistration.k8s.io/safe-upgrades.gateway.networking.k8s.io created
validatingadmissionpolicybinding.admissionregistration.k8s.io/safe-upgrades.gateway.networking.k8s.io created
PWSH C:\Users\tobia> kubectl apply -f https://github.com/kubernetes-sigs/gateway-api-inference-extension/releases/download/v1.3.1/manifests.yaml
customresourcedefinition.apiextensions.k8s.io/inferencemodelrewrites.inference.networking.x-k8s.io created
Warning: resource customresourcedefinitions/inferenceobjectives.inference.networking.x-k8s.io is missing the kubectl.kubernetes.io/last-applied-configuration annotation which is required by kubectl apply. kubectl apply should only be used on resources created declaratively by either kubectl create --save-config or kubectl apply. The missing annotation will be patched automatically.
customresourcedefinition.apiextensions.k8s.io/inferenceobjectives.inference.networking.x-k8s.io configured
customresourcedefinition.apiextensions.k8s.io/inferencepoolimports.inference.networking.x-k8s.io created
Warning: resource customresourcedefinitions/inferencepools.inference.networking.k8s.io is missing the kubectl.kubernetes.io/last-applied-configuration annotation which is required by kubectl apply. kubectl apply should only be used on resources created declaratively by either kubectl create --save-config or kubectl apply. The missing annotation will be patched automatically.
customresourcedefinition.apiextensions.k8s.io/inferencepools.inference.networking.k8s.io configured
customresourcedefinition.apiextensions.k8s.io/inferencepools.inference.networking.x-k8s.io created

Then we install Istio. Notable is the ENABLE_GATEWAY_API_INFERENCE_EXTENSION setting:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
PWSH C:\Users\tobia> istioctl install --set values.pilot.env.ENABLE_GATEWAY_API_INFERENCE_EXTENSION=true
        |\
        | \
        |  \
        |   \
      /||    \
     / ||     \
    /  ||      \
   /   ||       \
  /    ||        \
 /     ||         \
/______||__________\
____________________
  \__       _____/
     \_____/

This will install the Istio 1.29.1 profile "default" into the cluster. Proceed? (y/N) y
✔ Istio core installed ⛵️
✔ Istiod installed 🧠
✔ Ingress gateways installed 🛬
✔ Installation complete

With that, the base requirements are in place and we can create the inference gateway and deploy the body-based router:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
PWSH C:\Users\tobia> kubectl create namespace gateway
namespace/gateway created
PWSH C:\Users\tobia> @"
>> apiVersion: gateway.networking.k8s.io/v1
>> kind: Gateway
>> metadata:
>>   name: inference-gateway
>>   namespace: gateway
>> spec:
>>   gatewayClassName: istio  # Change to match your implementation
>>   infrastructure:
>>     annotations:
>>       # Required on AKS with Istio. Azure otherwise probes GET / on port 80,
>>       # but the gateway returns 404 there and the public IP can time out.
>>       service.beta.kubernetes.io/port_80_health-probe_protocol: tcp
>>   listeners:
>>     - name: http
>>       protocol: HTTP
>>       port: 80
>> "@ | kubectl apply -f -
gateway.gateway.networking.k8s.io/inference-gateway created
PWSH C:\Users\tobia> helm install body-based-router -n gateway --set provider.name=istio --version v1.3.1 oci://registry.k8s.io/gateway-api-inference-extension/charts/body-based-routing
Pulled: registry.k8s.io/gateway-api-inference-extension/charts/body-based-routing:v1.3.1
Digest: sha256:aedc6a36cdf1bf34d41886c525275b26711ce15996affc39d4eb94cd1f0f2dc8
I0426 10:47:03.065464   35936 warnings.go:110] "Warning: EnvoyFilter exposes internal implementation details that may change at any time. Prefer other APIs if possible, and exercise extreme caution, especially around upgrades."
NAME: body-based-router
LAST DEPLOYED: Sun Apr 26 10:47:02 2026
NAMESPACE: gateway
STATUS: deployed
REVISION: 1
DESCRIPTION: Install complete
TEST SUITE: None
NOTES:
Body-based routing extension deployed.

And that’s already it. We only need to figure out what the IP for our gateway is, e.g. like this

1
2
3
PWSH C:\Users\tobia> kubectl get gateway -n gateway inference-gateway
NAME                CLASS   ADDRESS        PROGRAMMED   AGE
inference-gateway   istio   20.170.89.88   True         15s

Or we can take a look into the AI Runway settings, which give us the same information

After deploying models as explained in the last blog post, we can now run inference against that IP as shown above. If you look into the deployments in the AI Runway dashboard, you even get a ready to run example

Just copy/pasting it works like a charm:

1
2
PWSH C:\Users\tobia> curl http://20.170.89.88/v1/chat/completions -H "Content-Type: application/json" -d '{"model": "gemma-2-2b-instruct", "messages": [{"role": "user", "content": "Hello"}]}'
{"choices":[{"finish_reason":"stop","index":0,"message":{"content":"Hello! 👋  \n\nHow can I help you today? 😊 \n","role":"assistant"}}],"created":1777196088,"id":"b116b6f2-7b36-4f71-9f40-49266b9830d3","model":"gemma-2-2b-instruct","object":"chat.completion","usage":{"completion_tokens":16,"prompt_tokens":10,"total_tokens":26}}

Thanks to the AI Runway team, this is an amazingly easy starting point into running LLMs on your own Kubernetes backend!

Deploy LLMs on Azure Kubernetes Service with AI Runway

Tue, 31 Mar 2026 19:24:45 +0000

At this year’s MVP Summit, I joined a session with the one and only Brendan Burns where I first heard about AI Runway. The idea immediately caught my attention: run an LLM in your own environment, under your full control, but still with a very user-friendly experience. No mystery backend, no black box SaaS dependency, just your own Kubernetes cluster and a clean workflow.

In this post, I’ll walk through how I set this up on an Azure Kubernetes Service (AKS) cluster with the Kubernetes AI Toolchain Operator (KAITO) and Traefik traefik.

The TL;DR

If you want the short version: you can deploy an LLM on your own Kubernetes cluster in a surprisingly easy way using KAITO and AI Runway, manage it through a friendly dashboard, and expose both dashboard and model endpoints safely through Traefik with TLS.

To give you an idea, this is what the dashboard looks like:

And this is a deployment of an LLM in KAITO:

The details: Create the AKS cluster and install KAITO

Let’s start with the cluster and the AI toolchain foundation. I used these PowerShell environment variables first:

1
2
3
4
5
6
$env:AZURE_SUBSCRIPTION_ID="<your-subscription-id>"
$env:AZURE_RESOURCE_GROUP="airunway"
$env:AZURE_LOCATION="germanywestcentral"
$env:CLUSTER_NAME="cluster"
$env:DNS_LABEL="tfe-airunway"
$env:LE_EMAIL="you@example.com"

You would of course need to adjust those according to your subscription data and your preferences. Then create the resource group, AKS cluster, and a dedicated node pool for model workloads:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
az group create --name $env:AZURE_RESOURCE_GROUP --location $env:AZURE_LOCATION

az aks create \
	--location $env:AZURE_LOCATION \
	--resource-group $env:AZURE_RESOURCE_GROUP \
	--name $env:CLUSTER_NAME \
	--enable-oidc-issuer \
	--generate-ssh-keys

az aks nodepool add \
	--resource-group $env:AZURE_RESOURCE_GROUP \
	--cluster-name $env:CLUSTER_NAME \
	--name models \
	--node-count 1 \
	--min-count 1 \
	--max-count 10 \
	--node-vm-size Standard_D8ds_v5 \
	--enable-cluster-autoscaler

az aks get-credentials --resource-group $env:AZURE_RESOURCE_GROUP --name $env:CLUSTER_NAME --overwrite-existing

Note that we are using the Standard_D8ds_v5 VM size which includes only CPUs and no GPUs because I couldn’t get any VMs with GPUs at the moment on Azure for my dev/test subscription. But KAITO can also run CPU-only models.

With the cluster in place, install KAITO:

1
2
3
4
5
helm repo add kaito https://kaito-project.github.io/kaito/charts/kaito
helm install kaito-workspace kaito/workspace \
	--namespace kaito-workspace \
	--create-namespace \
	--set featureGates.disableNodeAutoProvisioning=true

That gives you the Kubernetes-native model management layer we need for the next steps.

The details: Add AI Runway and expose the dashboard through Traefik

Next, install AI Runway itself:

1
2
3
kubectl apply -f https://raw.githubusercontent.com/kaito-project/airunway/main/deploy/controller.yaml
kubectl apply -f https://raw.githubusercontent.com/kaito-project/airunway/main/deploy/dashboard.yaml
kubectl apply -f https://raw.githubusercontent.com/kaito-project/airunway/refs/heads/main/providers/kaito/deploy/kaito.yaml

To make the dashboard available from the internet, I installed Traefik and configured ACME/Let’s Encrypt:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
helm repo add traefik https://traefik.github.io/charts
helm repo update

@"
ingressClass:
	enabled: true
	isDefaultClass: false
	name: traefik

providers:
	kubernetesIngress:
		enabled: true
	kubernetesGateway:
		enabled: false
	kubernetesCRD:
		enabled: true

logs:
	access:
		enabled: true
		format: common

service:
	annotations:
		service.beta.kubernetes.io/azure-dns-label-name: $env:DNS_LABEL

additionalArguments:
	- --certificatesresolvers.le.acme.email=$env:LE_EMAIL
	- --certificatesresolvers.le.acme.storage=/data/acme.json
	- --certificatesresolvers.le.acme.tlschallenge=true
	- --certificatesresolvers.le.acme.httpchallenge=true
	- --certificatesresolvers.le.acme.httpchallenge.entrypoint=web
"@ | helm upgrade --install traefik traefik/traefik `
	--namespace traefik `
	--create-namespace `
	--wait --timeout 10m `
	-f -

And this Ingress publishes the AI Runway dashboard:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
@"
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
	name: dashboard-ingress
	namespace: airunway-system
	annotations:
		traefik.ingress.kubernetes.io/router.entrypoints: websecure
		traefik.ingress.kubernetes.io/router.tls: "true"
		traefik.ingress.kubernetes.io/router.tls.certresolver: le
spec:
	ingressClassName: traefik
	tls:
	- hosts:
		- $env:DNS_LABEL.$env:AZURE_LOCATION.cloudapp.azure.com
	rules:
	- host: $env:DNS_LABEL.$env:AZURE_LOCATION.cloudapp.azure.com
		http:
			paths:
			- path: /
				pathType: Prefix
				backend:
					service:
						name: airunway
						port:
							number: 80
"@ | kubectl apply -f -

Now you can open the dashboard as is visible in the screenshot above and start deploying models from the UI.

The details: Deploy your first model, expose it, and test over HTTP

From the AI Runway dashboard, deploy llama3.2:1b first. Once it is running, expose the model service via Traefik as well. I used a middleware to strip an /openai prefix so the backend receives the expected path and because that is the way Microsoft Foundry exposes models.

Update: If you want a better, more flexible way to implement network access to the models, check this later blog post

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
@"
apiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
	name: strip-openai
	namespace: kaito-workspace
spec:
	stripPrefix:
		prefixes:
			- /openai
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
	name: llm-ingress
	namespace: kaito-workspace
	annotations:
		traefik.ingress.kubernetes.io/router.entrypoints: websecure
		traefik.ingress.kubernetes.io/router.tls: "true"
		traefik.ingress.kubernetes.io/router.tls.certresolver: le
		traefik.ingress.kubernetes.io/router.middlewares: kaito-workspace-strip-openai@kubernetescrd
spec:
	ingressClassName: traefik
	tls:
	- hosts:
		- $env:DNS_LABEL.$env:AZURE_LOCATION.cloudapp.azure.com
	rules:
	- host: $env:DNS_LABEL.$env:AZURE_LOCATION.cloudapp.azure.com
		http:
			paths:
			- path: /openai
				pathType: Prefix
				backend:
					service:
						name: llama3-2-1b-vqck
						port:
							number: 80
"@ | kubectl apply -f -

Finally, a first HTTP test against the OpenAI-compatible API endpoint:

1
2
3
4
5
6
7
8
9
10
11
12
POST https://tfe-airunway.germanywestcentral.cloudapp.azure.com/openai/v1/chat/completions
Content-Type: application/json

{
	"model": "llama-3.2-1b-instruct",
	"messages": [
		{
			"role": "user",
			"content": "generate a powershell script to recursively analyze the size of my home folder to a maximum depth of 5 levels"
		}
	]
}

The response will look something like this

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
HTTP/1.1 200 OK
Content-Type: application/json
Date: Tue, 31 Mar 2026 19:43:37 GMT
X-Correlation-Id: b3916e7e-b077-437a-bbbc-59c966d20c9e
Connection: close
Transfer-Encoding: chunked

{
  "created": 1774986196,
  "object": "chat.completion",
  "id": "14e7cc35-e81a-4616-bbce-70067f2a324e",
  "model": "llama-3.2-1b-instruct",
  "choices": [
    {
      "index": 0,
      "finish_reason": "stop",
      "message": {
        "role": "assistant",
        "content": "Here is a PowerShell script that recursively analyzes the size of your home folder to a maximum depth of 5 levels:\n```powershell\n# Get the current user's home directory\n$homeDir = Get-Location\n\n# Set the maximum depth\n$maxDepth = 5\n\n# Define the recursion function\nfunction Get-Size {\n    param ($path)\n\n    # Get the file count\n    Get-ChildItem -Path $path -Recurse | Measure-Object\n\n    # Get the size of each item\n    Get-ChildItem -Path $path | ForEach-Object {\n        Get-Size $_.FullName\n        Write-Host \"  \"\n        $itemSize = $_.Size\n        Write-Host $itemSize\n    }\n}\n\n# Call the function with the home directory\nGet-Size $homeDir\n```\nLet me explain what this script does:\n\n1. It gets the current user's home directory.\n2. It sets the maximum depth of the recursion to 5 levels.\n3. It defines a function `Get-Size` that takes a path as input and performs the following steps:\n\t* Gets the file count using `Get-ChildItem`.\n\t* Gets the size of each item using `Get-ChildItem` and `Measure-Object`.\n\t* Prints the size of each item, prefixed with a column of hyphens to indicate the depth of the item.\n4. Finally, the script calls the `Get-Size` function with the current user's home directory.\n\nTo use this script, simply copy and paste it into PowerShell, and it will recursively analyze the size of your home folder to a maximum depth of 5 levels. The output will be something like this:\n```\n    -Size:\n        100KB\n        4KB\n        800KB\n        4KB\n        800KB\n        4KB\n        800KB\n    -\n    -Size:\n        100KB\n        4KB\n        800KB\n        4KB\n        800KB\n        4KB\n        800KB\n    -\n    -Size:\n        100KB\n        4KB\n        800KB\n        4KB\n        800KB\n        4KB\n        800KB\n    -\n    -Size:\n        100KB\n        4KB\n        800KB\n        4KB\n        800KB\n        4KB\n        800KB\n    -\n    -Size:\n        100KB\n        4KB\n        800KB\n        4KB\n        800KB\n        4KB\n        800KB\n    -\n    -Size:\n        100KB\n        4KB\n        800KB\n        4KB\n        800KB\n        4KB\n        800KB\n    -\n    -Size:\n        100KB\n        4KB\n        800KB\n        4KB\n        800KB\n        4KB\n        800KB\n    -\n    -Size:\n        100KB\n        4KB\n        800KB\n        4KB\n        800KB\n        4KB\n        800KB\n```\nNote that this script will not be suitable for very large home directories, as it can take a significant amount of time to run. Also, be careful when running this script, as it will modify the file system of the current user."
      }
    }
  ],
  "usage": {
    "prompt_tokens": 33,
    "completion_tokens": 731,
    "total_tokens": 764
  }
}

This is what I really like about the setup: from zero to a working, externally reachable LLM endpoint with a proper dashboard and your own infrastructure control in a short amount of time.

The details: Using it with Business Central

I tried to set up the OpenAI integration in Microsoft Dynamics 365 Business Central as shown in the BC Tech sample for that topic, but that doesn’t work. I even don’t see a request coming in, so it looks to me like BC is somehow validating that it takes to Microsoft Foundry and not something that looks very similar. A pity…

But as I showed before, we can use the Business Central MCP Server e.g. in VS Code. You can configure your model there as “OpenAI compatible” like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
    {
        "name": "AI Runway",
        "vendor": "customoai",
        "models": [
            {
                "id": "llama-3.2-1b-instruct",
                "name": "LLaMA 3.2:1B",
                "url": "https://tfe-airunway.germanywestcentral.cloudapp.azure.com/openai",
                "toolCalling": true,
                "vision": false,
                "maxInputTokens": 128000,
                "maxOutputTokens": 16000
            }
        ]
    }

With this in place and an MCP configuration like explained in the previous blog post, you can experiment with the BC MCP and the capabilities of different models. While e.g. the model I used above is quite small, it gave surprisingly good results in this context, but depending on what you want to achieve, your response might of course be different.

Using MCPs with GitHub Copilot without installing anything locally

Tue, 17 Mar 2026 21:44:59 +0000

MCP servers have radically changed how LLMs interact with resources outside their training data, and developers are already relying on them to get dramatically better results. But what if you are not a developer and still want to make use of them, but don’t want to install “developer stuff” on your machine? Or if you can’t or don’t want to install those MCP servers locally (and there are very good reasons for not doing that, more on that in a later blog post)? I’ll show you a setup which solves that problem. My scenario is that of a product manager working with Microsoft Dynamics 365 Business Central (BC). The code and user stories live in Azure DevOps, but that could easily also be GitHub and Jira or whatever you use. We will use the Azure DevOps MCP server as well as the AL Symbols MCP server.

The TL;DR

To just give it a try, go to https://github.com/tfenster/codespace-mcp, fork the repo and create a codespace through the “Code” action in the top right

Then you need to run az login in a terminal to connect to your Azure account. If you also want to interact with the structures of Business Central, you need to run the AL: Download symbols action or put other extensions you might want to reference into the .alpackages folder. Now all that is left to do is to start the MCP servers by opening the .vscode/mcp.json file and clicking on the “start” action. The Azure DevOps MCP will ask for the name of your organization, while the AL symbols MCP just starts.

With that in place, you can use GitHub Copilot to ask a question like “check work item 33 in project mcp-demo. Can you find any functionality in the AL symbols found in my workspace that would help me fulfill the requirement?” Work item 33 in my example is actually quite bad, it only has “We want the customers to be categorizable. The available categories shall be A, B and C” as description. Also the prompt isn’t great, but that’s not the point I want to make here. Copilot now does things like this:

I’ll help you check work item 33 and find relevant AL symbols in your workspace. Let me start by fetching the work item details.

Fetched work item 33 from mcp-demo project
Ran wit_get_work_item - azdo (MCP Server)
Searched for Customer-related objects in workspace

Now let me search your workspace for AL objects related to customers and categorization:

Ran al_packages - al-symbols-mcp (MCP Server)
Ran al_search_objects - al-symbols-mcp (MCP Server)
Reviewed content from specified lines
Ran al_get_object_definition - al-symbols-mcp (MCP Server)
Ran al_search_objects - al-symbols-mcp (MCP Server)
Reviewed 3 files
Ran al_search_objects - al-symbols-mcp (MCP Server)
Reviewed content.json, lines 1 to 200
Ran al_search_objects - al-symbols-mcp (MCP Server)
Ran al_search_objects - al-symbols-mcp (MCP Server)
Reviewed content.json, lines 1 to 100

Summary: Work Item 33 Analysis

Requirement: “New customer categorization - We want the customers to be categorizable. The available categories shall be A, B and C”

Relevant AL Functionality Found in Your Workspace:

1. Customer Table (ID 18, Base Application)

Main table for customer data in your Dynamics 365 Business Central system

Currently has fields for classification, customer groups, and other metadata

This is the primary table you’ll need to extend to add categorization

2. Enum Pattern Examples Your workspace contains several enumeration patterns you can reference:

User Plan Experience (ID 9005) - Shows multi-value enum structure (Basic, Essentials, Premium, Other)

No. Series Implementation (ID 397) - Simpler two-value pattern

These demonstrate the standard syntax for creating choice fields

3. Table Extension Pattern

Serv. Customer Templ. (TableExtension ID 6451) shows how to extend the Customer Template table

Demonstrates field definitions with proper properties like Caption, DataClassification, and TableRelation

This pattern can be followed to add categorization functionality

Recommended Implementation Approach:

Create an Enum for customer categories with values A, B, and C

Extend the Customer Table using a TableExtension to add a new field for the category

Add UI controls (likely in a Customer page extension) to allow selection between the three categories

Use standard properties: Caption, OptionString/OptionMembers, and DataClassification

The enumeration and table extension patterns already exist in your system, so you can follow those established conventions for a consistent implementation.

Is this the most astonishing use of AI or the best solution for the requirement? Both definitely not. The point is something different: Copilot interacted with Azure DevOps (e.g. Ran wit_get_work_item - azdo (MCP Server)) and the AL extensions in the folder (e.g. Ran al_get_object_definition - al-symbols-mcp (MCP Server) or Ran al_search_objects - al-symbols-mcp (MCP Server)) to find answers to the question we ask. Without having to install anything potentially harmful locally. So if you struggle to provide GitHub Copilot with the right context and information to work on your requirements, this might be an easy way to make you faster, more efficient and provide higher quality to whoever has to pick up your requirements.

The details: Other interactions you might like

Other interactions with your content could be the following:

“what are acceptance criteria I might want to add to that work item”
After a bit of back and forth you will probably get a suitable list. Now you could try “please directly add them to the work item” and a call like Ran wit_update_work_item - azdo (MCP Server) would improve your work item like this

“what are other aspects i need to think about when validating this requirement”
This time, Copilot didn’t use any of the MCP tools, but came up with topics like business semantics, lifecycle rules, backward compatibility & migration, UI & usability, data quality controls, process impact, reporting & analytics, security & compliance, non-functional & operability and edge cases. Maybe not all of them are relevant, but certainly a good idea to think about those aspects briefly

“which standard features could I use to meet the requirement without coding”
Here Copilot again interacted with my local symbols

Ran al_search_objects - al-symbols-mcp (MCP Server) (did that 4 times)
Reviewed content.json, lines 1 to 80
Ran al_get_object_summary - al-symbols-mcp (MCP Server)
Ran al_search_objects - al-symbols-mcp (MCP Server)
Now let me get the full list of Customer table fields to identify what grouping/classification fields already exist.
Ran al_get_object_definition - al-symbols-mcp (MCP Server)
Ran terminal command: cat "/home/codespace/.vscode-remote/data/User/works...
Reviewed content from specified file

Good picture from the field list. Now I can give you a thorough, grounded answer based on what’s actually in your BC symbols.

Here are the standard BC features that could meet the requirement without any AL coding, ranked by fit:

Best fit — Dimensions

Global Dimension 1/2 Code (fields 16/17) or an additional dimension:

Create a new Dimension (e.g. CUST-CATEGORY) with Dimension Values A, B, C.

The Customer Card has a Dimensions action out of the box.

Filtering by dimension value works natively in Customer List, and in all standard reports.

Values are validated against the Dimension Values table, so only A/B/C are possible.

Limitation: the category doesn’t appear as a direct column on the Customer Card/List; it lives behind the Dimensions action, which may not match the business’s UX expectation.

Good fit — Customer Price Group (field 23, Customer Price Group table)

Create three Price Groups named A, B, C.

The field is already visible on the Customer Card (Invoicing FastTab).

Supports list filtering and look-up.

Limitation: semantically tied to pricing — if the business assigns it a non-price meaning it can cause confusion, and it may interfere with price calculation logic.

Reasonable fit — Territory Code (field 15, Territory table)

Create Territories A, B, C.

Already present on the Customer Card.

No strong semantic tie to other BC processes.

Limitation: Territory has its own reporting context (sales by territory) — reusing it for categorization pollutes that.

Possible fit — Customer Disc. Group (field 34, Customer Discount Group table)

Create discount groups A, B, C.

Visible on Customer Card.

Limitation: semantically tied to discount rules — same confusion risk as Price Group.

Limited fit — Statistics Group (field 26, Integer)

An integer field for segmenting customers in statistics.

Validated by being an integer — you could use 1=A, 2=B, 3=C.

Limitation: not user-friendly (shows numbers, not A/B/C labels), not directly filterable by label, and the field is often hidden in standard page layouts.

Summary recommendation

Option Label visible Direct card field Clean semantics Validated values

Dimension ✗ (behind action) ✗ ✓ ✓

Customer Price Group ✓ ✓ ✗ ✓

Territory Code ✓ ✓ ✓ (neutral) ✓

Customer Disc. Group ✓ ✓ ✗ ✓

Statistics Group ✗ (integer, hidden) ✓ (hidden) ✓ ✗

If the business can accept a slightly repurposed field: Territory Code is the cleanest no-code option — it’s neutral, already on the card, and supports A/B/C values with validation.

If UX purity matters (the field should be called “Customer Category”): none of these fully satisfy the requirement without at least a minor configuration step — you would need AL code to add and properly label a new field, or use Dimensions and accept the UX trade-off.

Option	Label visible	Direct card field	Clean semantics	Validated values
Dimension	✗ (behind action)	✗	✓	✓
Customer Price Group	✓	✓	✗	✓
Territory Code	✓	✓	✓ (neutral)	✓
Customer Disc. Group	✓	✓	✗	✓
Statistics Group	✗ (integer, hidden)	✓ (hidden)	✓	✗

Do I agree with all of this or does it even all make sense? I would say there are very good arguments to immediately dismiss some of them and basic BC knowledge would probably get you further. But imagine you are in a situation where you have an ISV solution that you don’t fully know or have limited documentation, but only the symbols. Or you just want to validate that you haven’t missed anything obvious. Then this could be a very helpful starting point.

“do i have any conflicting requirements in my backlog”

For this, Copilot looked at my backlog and identified a conflicting requirement

Let me pull the full backlog to check all work items against this requirement.

Ran wit_list_backlogs - azdo (MCP Server)
Ran wit_list_backlog_work_items - azdo (MCP Server)
Ran wit_get_work_items_batch_by_ids - azdo (MCP Server)

Yes — there is a direct conflict. Your backlog has two work items that describe the same feature with incompatible specifications:

Work Item 33 Work Item 34

Title New customer categorization New customer categories

Categories A, B, C Silver, Gold, Platinum

State New New

They are describing the same thing — a customer categorization field — but with different value sets. Implementing both would mean two overlapping classification fields on the customer, or one implementation that has to be changed right after the other is delivered.

This needs a decision before any code is written:

Are these the same requirement? If so, one should be closed as duplicate and the surviving one updated with the agreed value set (A/B/C labels, or Silver/Gold/Platinum, or perhaps both — e.g. A=Silver, B=Gold, C=Platinum).

Are these intentionally different fields? If the business wants both a tier label (Silver/Gold/Platinum) and a separate internal code (A/B/C), both IDs and field names need to be distinct and each work item should be clarified accordingly.

Would you like me to link them as duplicates, add a comment flagging the conflict, or update one of them?

	Work Item 33	Work Item 34
Title	New customer categorization	New customer categories
Categories	A, B, C	Silver, Gold, Platinum
State	New	New

This obviously was an easily identifiable one, but again, imagine yourself in a situation with a lot of requirements, potentially from a time when you weren’t working with a particular product where it might not be that easy to spot duplicates. Running it through Copilot could be highly valuable.

I hope this gave you some ideas about how to use the Azure DevOps and AL MCP servers to interact with and improve your requirements. And as mentioned in the beginning, even if you use a different toolset, by now chances are quite high that you can access it through an MCP server.

The details: Setup and configuration

If you are still following along and are techie enough to care about the technical setup, it is based on two files: devcontainer.json defines the container that makes up the Codespace:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
{
  "name": "MCP Codespace",
  "features": {
    "ghcr.io/devcontainers/features/node:1": {
      "version": "20"
    },
    "ghcr.io/devcontainers/features/azure-cli:1": {}
  },
  "postCreateCommand": "npm install -g @azure-devops/mcp",
  "customizations": {
    "vscode": {
      "extensions": [
        "ms-dynamics-smb.al"
      ]
    }
  }
}

You can see that Node.js is added as a feature (lines 4-6) because we need that for the MCP servers. You also see the Azure CLI (line 7) needed for the authentication against Azure DevOps. Next, the installation of the Azure DevOps MCP server happens after the container is created via line 9 and last but not least, the VS Code AL extension is added via lines 10-16.

The MCP servers are configured in mcp.json:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
{
  "inputs": [
    {
      "id": "azdo_org",
      "type": "promptString",
      "description": "Azure DevOps organization name (e.g. 'contoso')"
    }
  ],
  "servers": {
    "azdo": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@azure-devops/mcp", "${input:azdo_org}", "-d", "core", "work", "work-items", "test-plans"]
    },
    "al-symbols-mcp": {
      "type": "stdio",
      "command": "npx",
      "args": ["al-mcp-server"]
    }
  }
}

Lines 2-8 define one input, in this case the Azure DevOps organization, which is later used in line 13 as part of the configuration of the Azure DevOps MCP Server (lines 9-14). Very similarly, the AL symbols MCP server is configured in 15-20. Pretty simple and straightforward, with the only exception maybe the configuration of the modules of Azure DevOps that you want to make available in line 13 as well. In this case, only the core, work, work-items and test-plans modules are activated.

Lessons learned for AI assistant usage with Docker Model Runner on ARM Windows

Sun, 01 Feb 2026 19:25:33 +0000

This is just a quick one to share two lessons I learned in the last few days when working with AI assistants and Docker Model Runner

Lesson 1: If you can’t connect, there might be an easy fix

Working with an ARM-based Windows laptop is fantastic, but it comes with a few drawbacks. I encountered one of these when I tried to follow a Docker Blog post about OpenCode with DMR. OpenCode is an open source AI coding agent and the blog post explains how you can connect it to DMR. As I have a Qualcomm Adreno GPU, I wanted to use that for inference, but here things got a bit tricky:

Windows (ARM) supports the Qualcomm 6xx series or later through the llama.cpp engine
Windows with WSL2 supports NVIDIA CUDA GPUs

This means that while I can technically run Docker Model Runner in WSL2, that setup can’t use my GPU. Unfortunately, OpenCode doesn’t support Windows ARM at the moment. That means that I have to use DMR running on the Windows “host” while OpenCode is running in WSL. Not a problem at first glance, because OpenCode connects to DMR via TCP (typically http://localhost:12434) anyway. But if you keep the networking defaults, then localhost in WSL os something different to localhost on the Windows host. You can often reach the same stuff from WSL by using host.docker.internal, but that doesn’t work in this case because DMR only listens on 127.0.0.1.

But when I adressed this to the Docker team¹, I was made aware of mirrored mode networking for WSL. If that is in place, the issue is no longer there, because to quote from the docs: “Connect to Windows servers from within Linux using the localhost address 127.0.0.1”. So now I can talk to localhost from WSL and get the same TCP connection as from the Windows host. That means that doing a curl to localhost as you see in the following screenshot hits DMR on the Windows side, hence giving me accelerated GPU inference.

The setup is explained well in the link mentioned above, but here is the configuration that works for me:

1
2
[wsl2]
networkingMode=mirrored

Lesson 2: Don’t just assume it works, but check

When I first tried to work with the GPU-based inference, I just assumed it works as I had looked up the documentation. However, that wasn’t true. docker model status revealed that llama.cpp failed to install:

1
2
3
Status:
llama.cpp: failed to install llama.cpp: Get "https://hub.docker.com/v2/namespaces/docker/repositories/docker-model-backend-llamacpp/tags/latest-opencl": dialing hub.docker.com:443 host via direct connection because Docker Desktop has no HTTPS proxy: connecting to hub.docker.com:443: dial tcp: lookup hub.docker.com: no such host
vllm: not installed

After setting DNS to 1.1.1.1 and 8.8.8.8 in my Docker Engine config like you see in the following snippet, the lookup worked:

1
2
3
4
5
6
7
8
{
  ...
  "dns": [
    "8.8.8.8",
    "1.1.1.1"
  ],
  ...
}

Restarting Docker Desktop then lead to the following docker model status output

1
2
3
4
5
6
docker model status
Docker Model Runner is running

Status:
llama.cpp: running llama.cpp latest-opencl (sha256:e12549787dbbb3b2c2e5d7a452edf7d64cd5a4a492679cc366b02f05d0efcc11) version: 091a46c
vllm: not installed

I also found the following entries in the ~\AppData\Local\Docker\log\host\inference-llama.cpp-server.log log:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
[2026-01-28T13:36:52.100268000Z] ggml_opencl: selected platform: 'QUALCOMM Snapdragon(TM)'
[2026-01-28T13:36:52.109192500Z] 
[2026-01-28T13:36:52.109192500Z] ggml_opencl: device: 'Qualcomm(R) Adreno(TM) X1-85 GPU (OpenCL 3.0 Qualcomm(R) Adreno(TM) X1-85 GPU)'
[2026-01-28T13:36:52.109192500Z] ggml_opencl: OpenCL driver: OpenCL 3.0 QUALCOMM build: 827.0 Compiler DX.18.05.00
[2026-01-28T13:36:52.109192500Z] ggml_opencl: vector subgroup broadcast support: true
[2026-01-28T13:36:52.109192500Z] ggml_opencl: device FP16 support: true
[2026-01-28T13:36:52.109192500Z] ggml_opencl: mem base addr align: 128
[2026-01-28T13:36:52.109192500Z] ggml_opencl: max mem alloc size: 2048 MB
[2026-01-28T13:36:52.109192500Z] ggml_opencl: device max workgroup size: 1024
[2026-01-28T13:36:52.109192500Z] ggml_opencl: SVM coarse grain buffer support: false
[2026-01-28T13:36:52.109192500Z] ggml_opencl: SVM fine grain buffer support: false
[2026-01-28T13:36:52.109788100Z] ggml_opencl: SVM fine grain system support: false
[2026-01-28T13:36:52.109788100Z] ggml_opencl: SVM atomics support: false
[2026-01-28T13:36:52.110290100Z] ggml_opencl: flattening quantized weights representation as struct of arrays (GGML_OPENCL_SOA_Q)
[2026-01-28T13:36:52.110290100Z] ggml_opencl: using kernels optimized for Adreno (GGML_OPENCL_USE_ADRENO_KERNELS)
[2026-01-28T13:37:12.093103100Z] ggml_opencl: loading OpenCL kernels.............................................................................
[2026-01-28T13:37:12.142341200Z] ggml_opencl: default device: 'Qualcomm(R) Adreno(TM) X1-85 GPU (OpenCL 3.0 Qualcomm(R) Adreno(TM) X1-85 GPU)'
[2026-01-28T13:37:12.153408400Z] main: setting n_parallel = 4 and kv_unified = true (add -kvu to disable this)
[2026-01-28T13:37:12.153408400Z] build: 1 (34ce48d) with Clang 19.1.7 for Windows ARM64
[2026-01-28T13:37:12.153408400Z] system info: n_threads = 6, n_threads_batch = 6, total_threads = 12
[2026-01-28T13:37:12.153408400Z] 
[2026-01-28T13:37:12.157120900Z] system_info: n_threads = 6 (n_threads_batch = 6) / 12 | CPU : NEON = 1 | ARM_FMA = 1 | LLAMAFILE = 1 | REPACK = 1 | 
[2026-01-28T13:37:12.157120900Z] 
[2026-01-28T13:37:12.157120900Z] init: using 11 threads for HTTP server
[2026-01-28T13:37:12.158494800Z] start: setting address family to AF_UNIX
[2026-01-28T13:37:12.165082800Z] main: loading model
[2026-01-28T13:37:12.166654200Z] srv    load_model: loading model '<HOME>\.docker\models\bundles\sha256\cad0bdb32dd3c9d0f915949d3434912eba79d66662ca16

Bottom line: Connecting to the “host” localhost from WSL is actually quite easy and for GPU-backed inference, make sure that it actually works…²

One of the, if not the biggest benefit of being a Docker Captain is that you can reach out the team directly and very often get pretty quick reactions. ↩
On a side note, the responses from OpenCode are still very slow. But that is a different topic where you can follow the progress at https://github.com/docker/model-runner/issues/606 and I might update this blog post with a third lesson (if it turns out there is one here as well) ↩

Logging and service monitoring in Windows Containers and AKS

Thu, 01 Jan 2026 09:44:26 +0000

To continue on the topic of running Windows Server 2025 containers and doing so on the Azure Kubernetes Service (AKS), this blog post explains how you can use LogMonitor and ServiceMonitor to run and monitor your Windows applications safely in AKS.

The TL;DR

To just give it a try, clone https://github.com/tfenster/logged-iis, which has all the sources you need. Then do the following:

Create a cluster using CreateCluster.ps1
Deploy my demo IIS container with kubectl apply -f iis.yaml and get the external IP with kubectl get services
Open the IIS starting page on that IP with something like http://9.141.62.204 (your IP will of course be different)
Check the logs in Azure Monitor, which should show you something like this

This is now an IIS container deployed to AKS that monitors the IIS Windows Service (W3SVC) through ServiceMonitor and puts the relevant logs to STDOUT through LogMonitor, which can then be collected in Azure Monitor. Now let’s take a look at the details how we got there.

The details: The container image with ServiceMonitor, LogMonitor and LogMonitorConfig.json

To get this to work from the container perspective, I used the same approach as explained previously to get IIS running in a Nano Server. What is special for the LogMonitor and ServiceMonitor, is the installation in the Dockerfile, based on a blog post about LogMonitor.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
FROM mcr.microsoft.com/windows/servercore:ltsc2025 AS download
WORKDIR /download
RUN powershell -Command \
    Invoke-WebRequest -Uri "https://github.com/microsoft/IIS.ServiceMonitor/releases/download/v2.0.1.10/ServiceMonitor.exe" -OutFile ".\ServiceMonitor.exe"; \
    Invoke-WebRequest -Uri "https://github.com/microsoft/windows-container-tools/releases/download/v2.1.3/LogMonitor.exe" -OutFile ".\LogMonitor.exe"

FROM mcr.microsoft.com/windows/nanoserver:ltsc2025
WORKDIR /install
COPY install_iis.cmd ./
COPY --from=download /download/ ./
USER ContainerAdministrator
RUN install_iis.cmd
WORKDIR /LogMonitor
COPY LogMonitorConfig.json ./
ENTRYPOINT ["C:\\install\\LogMonitor.exe", "C:\\install\\ServiceMonitor.exe", "W3SVC"]

In the end, I want to run in a Nano Server, but that base image doesn’t have any capability to download a file¹, so I went multi-stage with a Server Core base for the downloads first as you can see in lines 1-5. The files are then moved into the final stage in line 10. As mentioned above, the installation of IIS is the same as in my previous blog post. You can also see how LogMonitor is used with a nested ServiceMonitor call to monitor the IIS service in line 15. This runs LogMonitor with a configuration explained below, but also ServiceMonitor, which exits when the service state changes from SERVICE_RUNNING to anything else.

Potentially also interesting is the configuration of the collected logs in LogMonitorConfig.json, based on a sample in the official docs.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
{
    "LogConfig": {
        "sources": [
            {
                "type": "EventLog",
                "startAtOldestRecord": true,
                "eventFormatMultiLine": false,
                "channels": [
                    {
                        "name": "application",
                        "level": "error"
                    },
                    {
                        "name": "system",
                        "level": "error"
                    }
                ]
            },
            {
                "type": "File",
                "directory": "c:\\inetpub\\logs",
                "filter": "*.log",
                "includeSubdirectories": true
            },
            {
                "type": "ETW",
                "eventFormatMultiLine": false,
                "providers": [
                    {
                        "providerName": "IIS: WWW Server",
                        "providerGuid": "3A2A4E84-4C21-4981-AE10-3FDA0D9B0F83",
                        "level": "Information"
                    },
                    {
                        "providerName": "Microsoft-Windows-IIS-Logging",
                        "providerGuid": "7E8AD27F-B271-4EA2-A783-A47BDE29143B",
                        "level": "Information"
                    }
                ]
            }
        ]
    }
}

This collects information from the standard Windows event log (lines 4-18), from the IIS file-based logs (lines 19-24) and from the Event Tracing for Windows (ETW, lines 25-40). With that, we can see in STDOUT what goes on in the system generally and especially with IIS.

The details: AKS deployment

The AKS deployment in CreateCluster.ps1 is again very similar to what I shared before:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
az extension add --name aks-preview
az extension update --name aks-preview

az feature register --namespace "Microsoft.ContainerService" --name "AksWindows2025Preview"
az feature show --namespace Microsoft.ContainerService --name AksWindows2025Preview
az provider register --namespace Microsoft.ContainerService

$name = "akswin2025"
$region = "germanywestcentral"
$vmSize = "Standard_B4ls_v2"
az group create --name $name --location $region
az aks create -g $name -n $name --node-count 1 -s $vmSize --tier free --network-plugin azure --enable-app-routing --no-ssh-key --vm-set-type VirtualMachineScaleSets --network-plugin azure --enable-azure-monitor-metrics
az aks nodepool add --resource-group $name --cluster-name $name --os-type Windows --os-sku Windows2025 --name npwin --node-count 1 --ssh-access disabled --enable-fips-image
az aks enable-addons --addon monitoring --name $name --resource-group $name
az aks get-credentials --resource-group $name --name $name --overwrite-existing

Notable differences are:

The --enable-azure-monitor-metrics parameter in line 12 when the cluster is created. This enables monitoring generally for the AKS cluster via a Azure Monitor workspace. To learn more, check the official docs.
The monitoring addon, enabled via az aks enable-addons --addon monitoring... in line 14. This enables the collection of container logs. Again, to learn more, check the official docs

As explained above, LogMonitor with the right LogMonitorConfig.json makes sure that the right log entries end up in STDOUT and with the AKS setup explained here, that ends up in the workspace. With a KQL query like the following, also visible in the screenshot above, we can get e.g. the relevant parts from the IIS log files as they are also in STDOUT now:

1
2
3
4
5
6
7
8
9
ContainerLog
| union (ContainerLogV2
    | project-rename ContainerID = ContainerId
    | where ContainerName == "iis")
| extend d = parse_json(LogMessage. LogEntry)
| where LogMessage.Source == "File"
| extend Logline = d.Logline
| order by TimeGenerated desc
| project Logline

The deployment itself is trivial as you can see in iis.yaml. The only maybe relevant part is the usage of the tobiasfenster/logged-iis:nanoserver-ltsc2025 image, which is created using the Dockerfile above.

I hope this gives you an idea how to easily set up monitoring and logging for Windows containers in AKS, making them fit in the structure typically also used by Linux conatiners.

Of course, I could have used ADD in the Dockerfile, but that somehow isn’t intuitive for me, so I typically don’t. ↩

Running Windows Server 2025 workloads on Azure Kubernetes Service

Sun, 07 Dec 2025 11:56:43 +0000

A while ago, support for Windows Server 2025 in the Azure Kubernetes Service (AKS) was announced. Of course, I had to play around with it and in this blog post, I want to show you two scenarios: Running a Nano Server container enhanced by two FODs (see my recent blog post on the topic) and running a Microsoft Dynamics 365 Business Central container.

The TL;DR

To see it for yourself, you can do the following:

Clone my AKS Windows Server 2025 samples repo
Run CreateCluster.ps1 to create an AKS cluster with a Windows Server 2025 node pool
Run kubectl apply -f fod.yaml to deploy the nanoserver container with enabled IIS FOD
Run kubectl apply -f bc.yaml to deploy the Windows Server 2025 based BC container
Run kubectl get services to get the public IP addresses we need to use. This should give you something like

1
2
3
4
5
kubectl get services
NAME         TYPE           CLUSTER-IP     EXTERNAL-IP     PORT(S)         AGE
bc           LoadBalancer   10.0.245.147   72.144.130.94   443:32055/TCP   15m
iis          LoadBalancer   10.0.36.200    9.141.62.204    80:30936/TCP    3h25m
kubernetes   ClusterIP      10.0.0.1       <none>          443/TCP         7d20h

Open http://<external IP of IIS>. In my example above, that would be http://9.141.62.204. This should give you the default IIS starting page

Open https://<external IP of BC>/BC?tenant=default. Again, in my example above, this would be https://72.144.130.94/BC?tenant=default. It uses a self-signed SSL certificate, so you will get a security warning. If you ignore that, you can log in with the user defined in the deployment, tfenster, and the defined password Super5ecret! to access the BC starting page

The details: Setting up the cluster

Let’s take a look at what CreateCluster.ps1 does:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
az extension add --name aks-preview
az extension update --name aks-preview

az feature register --namespace "Microsoft.ContainerService" --name "AksWindows2025Preview"
az feature show --namespace Microsoft.ContainerService --name AksWindows2025Preview
az provider register --namespace Microsoft.ContainerService

$name = "akswin2025"
$region = "germanywestcentral"
$vmSize = "Standard_B4ls_v2"
az group create --name $name --location $region
az aks create -g $name -n $name --node-count 1 -s $vmSize --tier free --network-plugin azure --enable-app-routing --no-ssh-key --vm-set-type VirtualMachineScaleSets --network-plugin azure
az aks nodepool add --resource-group $name --cluster-name $name --os-type Windows --os-sku Windows2025 --name npwin --node-count 1 --ssh-access disabled --enable-fips-image
az aks get-credentials --resource-group $name --name $name --overwrite-existing

First, since the feature we want is in preview, we add and potentially update the aks-preview extension to the Azure CLI (lines 1 and 2). Next, we register and show the AksWindows2025Preview feature and register the AKS provider (lines 4-6). Next, we set up the name, region and VM size for the cluster (lines 8-10). After that, we create the resource group and AKS cluster (lines 11 and 12), and then we add the Windows Server 2025 node pool (line 13). Finally, we get the credentials to interact with our cluster via kubectl (line 14). The entire script should produce an output similar to this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
PWSH C:\Users\tobia> az group create --name $name --location $region
{
  "id": "/subscriptions/94670b10-08d0-4d17-bcfe-e01f701be9ff/resourceGroups/akswin2025",
  "location": "germanywestcentral",
  "managedBy": null,
  "name": "akswin2025",
  "properties": {
    "provisioningState": "Succeeded"
  },
  "tags": null,
  "type": "Microsoft.Resources/resourceGroups"
}
PWSH C:\Users\tobia>
PWSH C:\Users\tobia> az aks create -g $name -n $name --node-count 1 -s $vmSize --tier free --network-plugin azure --enable-app-routing --no-ssh-key --vm-set-type VirtualMachineScaleSets --network-plugin azure
Default SSH key behavior will change. When no SSH key parameters are provided, the command will behave as if '--no-ssh-key' was passed instead of failing in next breaking change release(2.80.0) scheduled for Nov 2025.
Argument '--enable-app-routing' is in preview and under development. Reference and support levels: https://aka.ms/CLI_refstatus
The behavior of this command has been altered by the following extension: aks-preview
The new node pool will enable SSH access, recommended to use '--ssh-access disabled' option to disable SSH access for the node pool to make it more secure.
{
  "aadProfile": null,
  "addonProfiles": null,
  "agentPoolProfiles": [
    {
      "artifactStreamingProfile": null,
      "availabilityZones": null,
      "capacityReservationGroupId": null,
      "count": 1,
      "creationData": null,
      "currentOrchestratorVersion": "1.32.9",
      "eTag": "401ba2c0-78b0-4a5e-9679-3579eb7519f3",
      "enableAutoScaling": false,
      "enableEncryptionAtHost": false,
      "enableFips": false,
      "enableNodePublicIp": false,
      "enableUltraSsd": false,
      "gatewayProfile": null,
      "gpuInstanceProfile": null,
      "gpuProfile": null,
      "hostGroupId": null,
      "kubeletConfig": null,
      "kubeletDiskType": "OS",
      "linuxOsConfig": null,
      "localDnsProfile": null,
      "maxCount": null,
      "maxPods": 30,
      "messageOfTheDay": null,
      "minCount": null,
      "mode": "System",
      "name": "nodepool1",
      "networkProfile": {
        "allowedHostPorts": null,
        "applicationSecurityGroups": null,
        "nodePublicIpTags": null
      },
      "nodeCustomizationProfile": null,
      "nodeImageVersion": "AKSUbuntu-2204gen2containerd-202511.07.0",
      "nodeInitializationTaints": null,
      "nodeLabels": null,
      "nodePublicIpPrefixId": null,
      "nodeTaints": null,
      "orchestratorVersion": "1.32",
      "osDiskSizeGb": 128,
      "osDiskType": "Managed",
      "osSku": "Ubuntu",
      "osType": "Linux",
      "podIpAllocationMode": null,
      "podSubnetId": null,
      "powerState": {
        "code": "Running"
      },
      "provisioningState": "Succeeded",
      "proximityPlacementGroupId": null,
      "scaleDownMode": "Delete",
      "scaleSetEvictionPolicy": null,
      "scaleSetPriority": null,
      "securityProfile": {
        "enableSecureBoot": false,
        "enableVtpm": false,
        "sshAccess": "LocalUser"
      },
      "spotMaxPrice": null,
      "status": null,
      "tags": null,
      "type": "VirtualMachineScaleSets",
      "upgradeSettings": {
        "drainTimeoutInMinutes": null,
        "maxBlockedNodes": null,
        "maxSurge": "10%",
        "maxUnavailable": "0",
        "minSurge": null,
        "nodeSoakDurationInMinutes": null,
        "undrainableNodeBehavior": null
      },
      "upgradeSettingsBlueGreen": {
        "batchSoakDurationInMinutes": null,
        "drainBatchSize": null,
        "drainTimeoutInMinutes": null,
        "finalSoakDurationInMinutes": null
      },
      "upgradeStrategy": "Rolling",
      "virtualMachineNodesStatus": null,
      "virtualMachinesProfile": null,
      "vmSize": "Standard_B4ls_v2",
      "vnetSubnetId": null,
      "windowsProfile": null,
      "workloadRuntime": "OCIContainer"
    }
  ],
  "aiToolchainOperatorProfile": null,
  "apiServerAccessProfile": null,
  "autoScalerProfile": null,
  "autoUpgradeProfile": {
    "nodeOsUpgradeChannel": "NodeImage",
    "upgradeChannel": null
  },
  "azureMonitorProfile": null,
  "azurePortalFqdn": "akswin2025-akswin2025-94670b-vqa7xrf8.portal.hcp.germanywestcentral.azmk8s.io",
  "bootstrapProfile": {
    "artifactSource": "Direct",
    "containerRegistryId": null
  },
  "creationData": null,
  "currentKubernetesVersion": "1.32.9",
  "disableLocalAccounts": false,
  "diskEncryptionSetId": null,
  "dnsPrefix": "akswin2025-akswin2025-94670b",
  "eTag": "ced84e53-96a5-4e6c-b33c-d1b732d81f34",
  "enableNamespaceResources": null,
  "enableRbac": true,
  "extendedLocation": null,
  "fqdn": "akswin2025-akswin2025-94670b-vqa7xrf8.hcp.germanywestcentral.azmk8s.io",
  "fqdnSubdomain": null,
  "hostedSystemProfile": {
    "enabled": false
  },
  "httpProxyConfig": null,
  "id": "/subscriptions/94670b10-08d0-4d17-bcfe-e01f701be9ff/resourcegroups/akswin2025/providers/Microsoft.ContainerService/managedClusters/akswin2025",
  "identity": {
    "delegatedResources": null,
    "principalId": "4532f452-5dba-4965-9b9f-20d7d15ce9c5",
    "tenantId": "539f23a3-6819-457e-bd87-7835f4122217",
    "type": "SystemAssigned",
    "userAssignedIdentities": null
  },
  "identityProfile": {
    "kubeletidentity": {
      "clientId": "b37ac7a2-8cf1-4144-af8e-83d73649cb3f",
      "objectId": "44393190-32fe-406a-b7d9-801657bafc14",
      "resourceId": "/subscriptions/94670b10-08d0-4d17-bcfe-e01f701be9ff/resourcegroups/MC_akswin2025_akswin2025_germanywestcentral/providers/Microsoft.ManagedIdentity/userAssignedIdentities/akswin2025-agentpool"
    }
  },
  "ingressProfile": {
    "gatewayApi": null,
    "webAppRouting": {
      "defaultDomain": {
        "enabled": false
      },
      "dnsZoneResourceIds": null,
      "enabled": true,
      "identity": {
        "clientId": "633a3b19-828a-4281-8cd5-c4a29eb143e8",
        "objectId": "a31f7c1d-538c-46ff-a578-75c372f4c433",
        "resourceId": "/subscriptions/94670b10-08d0-4d17-bcfe-e01f701be9ff/resourcegroups/MC_akswin2025_akswin2025_germanywestcentral/providers/Microsoft.ManagedIdentity/userAssignedIdentities/webapprouting-akswin2025"
      },
      "nginx": {
        "defaultIngressControllerType": "AnnotationControlled"
      }
    }
  },
  "kind": "Base",
  "kubernetesVersion": "1.32",
  "linuxProfile": null,
  "location": "germanywestcentral",
  "maxAgentPools": 100,
  "metricsProfile": {
    "costAnalysis": {
      "enabled": false
    }
  },
  "name": "akswin2025",
  "networkProfile": {
    "advancedNetworking": null,
    "dnsServiceIp": "10.0.0.10",
    "ipFamilies": [
      "IPv4"
    ],
    "kubeProxyConfig": null,
    "loadBalancerProfile": {
      "allocatedOutboundPorts": null,
      "backendPoolType": "nodeIPConfiguration",
      "clusterServiceLoadBalancerHealthProbeMode": null,
      "effectiveOutboundIPs": [
        {
          "id": "/subscriptions/94670b10-08d0-4d17-bcfe-e01f701be9ff/resourceGroups/MC_akswin2025_akswin2025_germanywestcentral/providers/Microsoft.Network/publicIPAddresses/9d9a1620-981c-4cb0-aaef-4edcb9ad03ee",
          "resourceGroup": "MC_akswin2025_akswin2025_germanywestcentral"
        }
      ],
      "enableMultipleStandardLoadBalancers": null,
      "idleTimeoutInMinutes": null,
      "managedOutboundIPs": {
        "count": 1,
        "countIpv6": null
      },
      "outboundIPs": null,
      "outboundIpPrefixes": null
    },
    "loadBalancerSku": "standard",
    "natGatewayProfile": null,
    "networkDataplane": "azure",
    "networkMode": null,
    "networkPlugin": "azure",
    "networkPluginMode": null,
    "networkPolicy": "none",
    "outboundType": "loadBalancer",
    "podCidr": null,
    "podCidrs": null,
    "podLinkLocalAccess": "IMDS",
    "serviceCidr": "10.0.0.0/16",
    "serviceCidrs": [
      "10.0.0.0/16"
    ],
    "staticEgressGatewayProfile": null
  },
  "nodeProvisioningProfile": {
    "defaultNodePools": "Auto",
    "mode": "Manual"
  },
  "nodeResourceGroup": "MC_akswin2025_akswin2025_germanywestcentral",
  "nodeResourceGroupProfile": null,
  "oidcIssuerProfile": {
    "enabled": false,
    "issuerUrl": null
  },
  "podIdentityProfile": null,
  "powerState": {
    "code": "Running"
  },
  "privateFqdn": null,
  "privateLinkResources": null,
  "provisioningState": "Succeeded",
  "publicNetworkAccess": null,
  "resourceGroup": "akswin2025",
  "resourceUid": "692b12472e7971000183169c",
  "schedulerProfile": null,
  "securityProfile": {
    "azureKeyVaultKms": null,
    "customCaTrustCertificates": null,
    "defender": null,
    "imageCleaner": null,
    "imageIntegrity": null,
    "kubernetesResourceObjectEncryptionProfile": null,
    "nodeRestriction": null,
    "workloadIdentity": null
  },
  "serviceMeshProfile": null,
  "servicePrincipalProfile": {
    "clientId": "msi",
    "secret": null
  },
  "sku": {
    "name": "Base",
    "tier": "Free"
  },
  "status": null,
  "storageProfile": {
    "blobCsiDriver": null,
    "diskCsiDriver": {
      "enabled": true,
      "version": "v1"
    },
    "fileCsiDriver": {
      "enabled": true
    },
    "snapshotController": {
      "enabled": true
    }
  },
  "supportPlan": "KubernetesOfficial",
  "systemData": null,
  "tags": null,
  "type": "Microsoft.ContainerService/ManagedClusters",
  "upgradeSettings": null,
  "windowsProfile": {
    "adminPassword": null,
    "adminUsername": "azureuser",
    "enableCsiProxy": true,
    "gmsaProfile": null,
    "licenseType": null
  },
  "workloadAutoScalerProfile": {
    "keda": null,
    "verticalPodAutoscaler": null
  }
}
PWSH C:\Users\tobia> az aks nodepool add --resource-group $name --cluster-name $name --os-type Windows --os-sku Windows2025 --name npwin --node-count 1 --ssh-access disabled --enable-fips-image
Argument '--ssh-access' is in preview and under development. Reference and support levels: https://aka.ms/CLI_refstatus
The behavior of this command has been altered by the following extension: aks-preview
{
  "artifactStreamingProfile": null,
  "availabilityZones": null,
  "capacityReservationGroupId": null,
  "count": 1,
  "creationData": null,
  "currentOrchestratorVersion": "1.32.9",
  "eTag": "745d5d2e-c47c-479d-8fdc-98962788f5ca",
  "enableAutoScaling": false,
  "enableEncryptionAtHost": false,
  "enableFips": true,
  "enableNodePublicIp": false,
  "enableUltraSsd": false,
  "gatewayProfile": null,
  "gpuInstanceProfile": null,
  "gpuProfile": null,
  "hostGroupId": null,
  "id": "/subscriptions/94670b10-08d0-4d17-bcfe-e01f701be9ff/resourcegroups/akswin2025/providers/Microsoft.ContainerService/managedClusters/akswin2025/agentPools/npwin",
  "kubeletConfig": null,
  "kubeletDiskType": "OS",
  "linuxOsConfig": null,
  "localDnsProfile": null,
  "maxCount": null,
  "maxPods": 30,
  "messageOfTheDay": null,
  "minCount": null,
  "mode": "User",
  "name": "npwin",
  "networkProfile": {
    "allowedHostPorts": null,
    "applicationSecurityGroups": null,
    "nodePublicIpTags": null
  },
  "nodeCustomizationProfile": null,
  "nodeImageVersion": "AKSWindows-2025-gen2-26100.6905.251027",
  "nodeInitializationTaints": null,
  "nodeLabels": null,
  "nodePublicIpPrefixId": null,
  "nodeTaints": null,
  "orchestratorVersion": "1.32",
  "osDiskSizeGb": 300,
  "osDiskType": "Ephemeral",
  "osSku": "Windows2025",
  "osType": "Windows",
  "podIpAllocationMode": null,
  "podSubnetId": null,
  "powerState": {
    "code": "Running"
  },
  "provisioningState": "Succeeded",
  "proximityPlacementGroupId": null,
  "resourceGroup": "akswin2025",
  "scaleDownMode": "Delete",
  "scaleSetEvictionPolicy": null,
  "scaleSetPriority": null,
  "securityProfile": {
    "enableSecureBoot": false,
    "enableVtpm": false,
    "sshAccess": "Disabled"
  },
  "spotMaxPrice": null,
  "status": null,
  "tags": null,
  "type": "Microsoft.ContainerService/managedClusters/agentPools",
  "typePropertiesType": "VirtualMachineScaleSets",
  "upgradeSettings": {
    "drainTimeoutInMinutes": null,
    "maxBlockedNodes": null,
    "maxSurge": "10%",
    "maxUnavailable": "0",
    "minSurge": null,
    "nodeSoakDurationInMinutes": null,
    "undrainableNodeBehavior": null
  },
  "upgradeSettingsBlueGreen": {
    "batchSoakDurationInMinutes": null,
    "drainBatchSize": null,
    "drainTimeoutInMinutes": null,
    "finalSoakDurationInMinutes": null
  },
  "upgradeStrategy": "Rolling",
  "virtualMachineNodesStatus": null,
  "virtualMachinesProfile": null,
  "vmSize": "Standard_D8d_v5",
  "vnetSubnetId": null,
  "windowsProfile": {
    "disableOutboundNat": null
  },
  "workloadRuntime": "OCIContainer"
}
PWSH C:\Users\tobia> az aks get-credentials --resource-group $name --name $name --overwrite-existing
The behavior of this command has been altered by the following extension: aks-preview
Merged "akswin2025" as current context in C:\Users\tobia\.kube\config

If you then use a tool like AKS Desktop (highly recommended), you should see your cluster including the Windows Server 2025 node:

The details: Creating and deploying the IIS (and SSH client) container image

Creating the container image works very much along the lines of what I showed in my first blog post about FODs: We use a Dockerfile that calls a script to install the FOD. The difference this time is that I also wanted to demonstrate installing a second FOD: the OpenSSH client. The installation process is very similar; basically only the name in line 1 is different, as seen in install_ssh_client.cmd:

1
2
3
4
5
6
DISM /Online /Add-Capability /CapabilityName:Microsoft.NanoServer.OpenSSH.Client /NoRestart
if errorlevel 3010 (
    echo The specified optional feature requested a reboot which was suppressed.
    exit /b 0
)
@echo off

The Dockerfile consequently also needs a reference to that script, as you can see in line 6

1
2
3
4
5
6
7
8
FROM mcr.microsoft.com/windows/nanoserver:ltsc2025
WORKDIR /install
COPY install_*.cmd ./
USER ContainerAdministrator
RUN install_iis.cmd
RUN install_ssh_client.cmd
USER ContainerUser
CMD ["ping", "-t", "localhost"]

A simple docker build -t tobiasfenster/fod:v0.0.6 . followed by a docker push tobiasfenster/fod:v0.0.6 creates and pushes that image. Now, let’s run this in AKS! Before we can do that, however, we need to consider how we want to use the SSH client. In my case, I need a private key to connect. First, I need to make the key available in the AKS cluster using this command:

1
kubectl create secret generic ssh-key-secret --from-file=id_rsa=c:/users/tobia/.ssh/id_azure

Of course, your SSH key most likely won’t be in c:\users\tobia\.ssh\id_azure, so you’ll need to adjust that. With that in place, we can kubectl apply -f .\fod.yaml with the fod.yaml looking like this

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
apiVersion: apps/v1
kind: Deployment
metadata:
  name: iis
  labels:
    app: iis
spec:
  replicas: 1
  template:
    metadata:
      name: iis
      labels:
        app: iis
    spec:
      nodeSelector:
        "kubernetes.io/os": windows
      containers:
      - name: iis
        image: tobiasfenster/fod:v0.0.6
        resources:
          limits:
            cpu: 1
            memory: 800M
        ports:
          - containerPort: 80
        volumeMounts:
        - name: ssh-key-volume
          mountPath: c:/ssh-key
          readOnly: true
      volumes:
      - name: ssh-key-volume
        secret:
          secretName: ssh-key-secret
  selector:
    matchLabels:
      app: iis
---
apiVersion: v1
kind: Service
metadata:
  name: iis
spec:
  type: LoadBalancer
  ports:
  - protocol: TCP
    port: 80
    name: http
  selector:
    app: iis

The first part (lines 1-36) is the deployment which containes the container. The most interesting lines are 18 and 19, which define the container; 15 and 16 which make sure that it ends up on a Windows node; and 26-30 which mount the SSH key into the container. Due to lines 38-49, the container id available via the external IP as explained in the TL;DR. Therefore, this is all that is needed for the IIS part.

Now what if we want to make an outgoing SSH connection? We have the SSH client installed through the FOD, and the private key is available through the secret and volume. However, we must properly define the permissions, otherwise SSH will decline to use the key, displaying an error message such as this:

1
2
3
4
5
6
7
Bad permissions. Try removing permissions for user: NT AUTHORITY\\Authenticated Users (S-1-5-11) on file c:/ssh-key/id_rsa.
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions for 'c:\\ssh-key\\id_rsa' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.

To fix that, you can run something like

1
2
3
4
5
6
copy c:\ssh-key\id_rsa .

icacls "c:\install\id_rsa" /inheritance:r
icacls "c:\install\id_rsa" /remove "NT AUTHORITY\Authenticated Users"
icacls "c:\install\id_rsa" /remove "BUILTIN\Users"
icacls "c:\install\id_rsa" /grant:r "%USERNAME%:R"

This copies the key to a new folder and fixes the permissions by breaking the inheritance and removing everyone before adding the current user. After that, you should be able to use the key to SSH into a remote machine.

You have now seen how to create and use a Windows Server 2025 Nano Server image to run a container in AKS that serves a webpage through IIS and establishes SSH connections. You might now be wondering which other FODs are available. It’s surprisingly difficult to find out, but you can run a Windows Server 2025 container and query for it like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
docker run --user ContainerAdministrator -ti mcr.microsoft.com/windows/nanoserver:ltsc2025
Microsoft Windows [Version 10.0.26100.7171]
(c) Microsoft Corporation. All rights reserved.

C:\>DISM /Online /Get-Capabilities /Format:Table

Deployment Image Servicing and Management tool
Version: 10.0.26100.5074

Image Version: 10.0.26100.7171

Capability listing:


---------------------------------------------------- | -----------
Capability Identity                                  | State
---------------------------------------------------- | -----------
Microsoft.NanoServer.ADSI~~~~                        | Not Present
Microsoft.NanoServer.BITS.Admin~~~~                  | Not Present
Microsoft.NanoServer.CommandLine.Utilities~~~~       | Not Present
Microsoft.NanoServer.Datacenter.WOWSupport~~~~       | Not Present
Microsoft.NanoServer.Globalization~~~~               | Not Present
Microsoft.NanoServer.IIS~~~~                         | Not Present
Microsoft.NanoServer.OpenSSH.Client~~~~              | Not Present
Microsoft.NanoServer.OpenSSH.Server~~~~              | Not Present
Microsoft.NanoServer.Performance.Monitoring~~~~      | Not Present
Microsoft.NanoServer.PowerShell.Cmdlets~~~~          | Not Present
Microsoft.NanoServer.RemoteFS.Client~~~~             | Not Present
Microsoft.NanoServer.StateRepository~~~~             | Not Present
Microsoft.NanoServer.WinMgmt.RuntimeDependencies~~~~ | Not Present
Microsoft.NanoServer.WinMgmt~~~~                     | Not Present

The operation completed successfully.

I wouldn’t be able to tell you exactly what those FODs do.

The details: Creating and deploying the BC container image

The second scenario is a Business Central container based on a Windows Server 2025 base image. Since these images are not readily available, you first need the bccontainerhelper PowerShell module. Then, you can run something like this to create the image:

1
New-BcImage -artifactUrl (Get-BCArtifactUrl -type sandbox -country w1 -accept_insiderEula -select NextMajor) -imageName tobiasfenster/mybc -baseImage "mcr.microsoft.com/businesscentral:ltsc2025"

In my case, this gave me the image tobiasfenster/mybc:sandbox-28.0.43121.0-w1-mt. Because of that, we can run a simple deployment to AKS like you see in bc.yaml:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
apiVersion: apps/v1
kind: Deployment
metadata:
  name: bc
  labels:
    app: bc
spec:
  replicas: 1
  template:
    metadata:
      name: bc
      labels:
        app: bc
    spec:
      nodeSelector:
        "kubernetes.io/os": windows
      containers:
      - name: bc
        image: tobiasfenster/mybc:sandbox-28.0.43121.0-w1-mt
        ports:
        - containerPort: 443
        env:
        - name: username
          value: tfenster
        - name: password
          value: Super5ecret!
        - name: auth
          value: NavUserPassword
        - name: accept_eula
          value: "y"
        - name: accept_outdated
          value: "y"
  selector:
    matchLabels:
      app: bc
---
apiVersion: v1
kind: Service
metadata:
  name: bc
spec:
  type: LoadBalancer
  ports:
  - protocol: TCP
    port: 443
    name: https
  selector:
    app: bc

As in the previous example, the container is shown in lines 18 and 19, the Windows node selection is shown in lines 15 and 16, and the service that enables incoming traffic is shown in lines 37–48. The BC container has a special username and password setup (lines 23–28) and requires acceptance of the EULA and outdated image (lines 29–32) to run.

Of course, for real dev/test scenarios, you would need much more, but this gives you the basics to see that BC on Windows Server 2025 runs in AKS.

Using the Business Central MCP Server with Visual Studio Code or cagent

Wed, 05 Nov 2025 23:18:36 +0000

At the Directions EMEA 2025 conference, Microsoft announced the public preview of their Business Central MCP Server. In case you haven’t heard, MCP is an open-source standard to connect AI applications to external systems. In the case of the BC MCP Server, this means that AI applications can access Business Central. I don’t want to go into the details on the BC side, as I’m sure that Microsoft will do a good job in documenting that. But for very understandable reasons, Microsoft only supports the Microsoft Copilot Studio as client, even though you may still want to use it with other clients, such as Visual Studio Code with Github Copilot or cagent.

The TL;DR

Here’s what you need to do for that:

Get the code from the BcMCPProxy sample in the BCTech Github repo
Compile it into an executable file
Follow the instructions in the repository to create an app registration, which you will need to authenticate against Business Central
Configure the proxy as an MCP Server in your client
Start using it!

For example, this is what it looks like in VS Code:

The details: Getting the BcMCPProxy executable

The BC MCP Proxy is a .NET 8 application, which means that you need a .NET SDK to compile it. To make that easier, I have created a pull request that adds devcontainer support as well as build tasks for VS Code to make building self-contained executables easier. Until that PR is merged (if at all), you can clone my fork and open the samples/BcMCPProxy folder in a dev container. Once it has started, you can run the build tasks and select your operating system. In my case, this is Windows-ARM64, but of course your setup may differ. You will then have an executable file that you can copy to your host machine and use it in the MCP setup later.

Update: Thanks to a very fast review and merge by Microsoft, this is now part of Microsoft’s repo, so you can use that functionality directly without a need to go through my fork!

Configuring VS Code

One way to configure an MCP Server in VS Code is to use a .vscode/mcp.json file (see the official docs for all options). As explained in the repo mentioned above for Claude Desktop, you need to add some configuration options. It should look like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
{
    "servers": {
        "bc": {
            "type": "stdio",
            "command": "C:\\Users\\tobia\\deleteme\\BcMCPProxy.exe",
            "args": [
                "--TenantId",
                "<tenant-id>",
                "--ClientId",
                "<client-id>",
                "--Environment",
                "<environment>",
                "--Company",
                "<company>",
                "--ConfigurationName",
                "<configuration-name>"
            ]
        }
    }
}

As you can see, you need to fill in the following:

the ID of your Entra ID tenant in line 8;
the client ID of your app registration in line 10;
the name of your BC environment where you have the MCP feature enabled and configured in line 12;
the name of the BC company you want to use in line 14;
the name of the MCP configuration in line 16. You can then click on “Start” and use the tools in GitHub Copilot Chat within VS Code, as shown in the video above!

Configuring cagent

Another client that works well is Docker’s cagent. In this case, the configuration is very similar, we only need to also add the LLM that we want to use. An example could look like this, using an Azure AI Foundry model:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
version: "1"

agents:
  root:
    description: An agent that interacts with Microsoft Dynamics 365 Business Central
    instruction: |
      You are an agent helping the user to interact with the ERP system Microsoft Dynamics 365 Business Central.
    model: cloud-gpt-5
    toolsets:
      - type: mcp
        command: C:\Users\tobia\deleteme\BcMCPProxy.exe
        args: [
            "--TenantId",
            "<tenant-id>",
            "--ClientId",
            "<client-id>",
            "--Environment",
            "<environment>",
            "--Company",
            "<company>",
            "--ConfigurationName",
            "<configuration-name>"
        ]

models:
  cloud-gpt-5:
    provider: azure
    model: gpt-5
    base_url: <your-azure-ai-foundry-endpoint>
    provider_opts:
      azure_api_version: 2025-01-01-preview

You can see the same setup as for VS Code in lines 10–23, as well as the model setup in lines 25–31 and the reference to it in line 8. With this configuration, the BC MCP Server can be used in a similar way:

With that, you should also be able to adapt the configuration for other clients. Have fun building applications and solving problems with it!

Debugging container image creation with a Dockerfile

Sun, 19 Oct 2025 18:25:24 +0000

If you have ever worked on even mildly complex container images based on Dockerfiles, then I am pretty sure that you know the pain of debugging when things go wrong. Typically, that meant juggling comments or removing parts of the Dockerfile to get an image during the intended build. Then, you would create a container and look at the resulting file system or run commands. Fortunately that has now changed as Docker has released a new feature that is available with the latest Docker Desktop and the latest VS Code Docker extension: Real debugging of the build process in VS Code! I’ll walk you through the main elements, but I would certainly also recommend reading the official announcement.

The TL;DR

Let’s assume that you have a Dockerfile that describes your container image. Then you need a launch configuration like this

1
2
3
4
5
6
7
{
    "name": "Docker: Build",
    "type": "dockerfile",
    "request": "launch",
    "dockerfile": "Dockerfile",
    "contextPath": "${workspaceFolder}",
}

With that in place, you can run the launch configuration as you would any other debug configuration by starting a debug session. If you have breakpoints in the Dockerfile, the debugger will stop, allowing you to view arguments and the file system, as well as access additional features, as explained below.

Pretty cool, right?

The details: My example and basic setup

As an example, I have created a simple .NET application using dotnet new console -n App. For that, I also created a Dockerfile, but to make things a bit more interesting, it is a multi-stage one:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
FROM --platform=$BUILDPLATFORM mcr.microsoft.com/dotnet/sdk:10.0 AS build
ARG configuration=Release
WORKDIR /src
COPY ["App.csproj", "./"]
RUN dotnet restore "App.csproj"
COPY . .
WORKDIR "/src/."
RUN dotnet build "App.csproj" -c $configuration -o /app/build

FROM build AS publish
ARG configuration=Release
RUN dotnet publish "App.csproj" -c $configuration -o /app/publish /p:UseAppHost=false

FROM mcr.microsoft.com/dotnet/runtime:10.0 AS final
USER app
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "App.dll"]

You can see the three stages, build, publish and final. As the names say, build and publish are for building and publishing, both using the full .NET SDK base image and the last one is for running only and uses the runtime image.

As mentioned in the TL;DR above, you need a launch configuration for debugging, which I showed in the previous paragraph.

One thing I struggled with initially was that at least for me, it didn’t work directly on Windows. Instead, I had to open a WSL terminal and start VS Code from there.

The details: Debugging

Another lesson I learned immediately was that breakpoints don’t get hit on every command. By chance I first tried with line 2 with the ARG call. The debugger didn’t stop. Thinking it might be due to the multi-stage nature of the image, so I tried line 15 with the USER call in the final stage. once again, the debugger didn’t stop. Only when I set the breakpoints on lines 3 and 16 which have the WORKDIR command, did the debugger stop. Also if I set the breakpoint on the very first line and went step by step using F10, the ARG and USER lines were never hit.

But once you know that, it works very conveniently. E.g. take the very first line FROM --platform=$BUILDPLATFORM mcr.microsoft.com/dotnet/sdk:10.0 AS build. If you want to figure out the value of $BUILDPLATFORM, just stop on that line and you can check the value under VARIABLES > Arguments > platform on the right

A few steps later, after the /src folder has been created and the App.csproj file is copied in, you can see the folder structure and file appear under VARIABLES > File Explorer and you can even see the content of a (text) file under date and as a mouseover.

In my opinion, the most useful feature is the ability to access an interactive console in the container during the build process. You can access this feature by typing exec into the command bar of the debug console in VS Code. With this feature, you can interact with the container during the build process. For example, you can run commands like this:

You can see that a new file was generated and that I could make changes to the container’s file system. However, once I step to the next line, this happens:

As we now have an obj folder, you can see that the dotnet restore has happened. At the same time, the test.txt file that was created interactively has disappeared because those changes are revoked once we go to the next line in the debugger.

The details: Multi-stage images and debugging immediately

One thing that worked quite intuitively for me was using multi-stage images. Setting "stopOnEntry": true in your launch config causes the debugger to stop immediately upon entering the build process. Interestingly, though, it doesn’t stop on line 1, as you might imagine, but rather on the first line of the final stage.

If you use F10 to step over lines, you will never reach the other stages. However, if you use Step Into or hit F11 on line 17, which references another stage, the debugger will go to that stage. As a developer, I find this very intuitive because it’s the same way I would step into a function.

I hit a few early hiccups when trying out the new debugger, but once I understood how it worked and set it up correctly, it worked really well. I am quite sure that it will come in handy if I run into issues with my Dockerfiles!

Orchestrate multiple AI agents with cagent by Docker to create a BC/AL coding assistant

Sun, 07 Sep 2025 20:18:12 +0000

One of the easiest ways to lure me into trying something is labelling it as “experimental”. I absolutely love playing with early-stage tools, seeing the raw and basic ideas of the creators and maybe even help to shape them into something useful. So when I recently was made aware of a new tool created and shared by Docker called “cagent” in very early experimental stage, I of course couldn’t resist to give it a try.

The TL;DR

cagent is a multi-agent runtime that orchestrates AI agents with specialized capabilities and tools, and the interactions between agents. The example scenario I want to share with you is a Microsoft Dynamics 365 Business Central (programming language AL) coding assistant that orchestrates three agents: The first one develops the code based on a requirement, the second one reviews the code and the third one does the git handling (create a branch, checkout, commit). To allow it to work, the coding and review agents have access to the filesystem and shell to make sure they can see existing code which I want to extend. They also have access to the AL MCP Server by Stefan Maron to help them understand the existing code structure in Business Central. The git handling agent has access to the reference git MCP server.

With that I can give my multi-agent system in cagent the following task, based on an already existing application where one specific small feature is missing: “i want to add a flag on the item card to show whether an item is an alloy item or not. Note that I already have that on the item list, but I also want it on the item card. make the required changes to the already existing code in the app folder”. Here is how it does:

To be honest, it took me quite a few attempts to get there, but I really like the result. It isn’t perfect and it doesn’t generate perfect code. But it is a helpful starting point and I will test with more complex examples to see where the boundaries are (admittedly, this is basically the simplest possible example). Also note that I am using a coding assistant as an example, but this is not limited to coding. It could be agents for everything you can think of and the examples in the GitHub repo of cagent give you an idea of that.

Is this the only or even the best way to create and maintain multi-agent systems? I can’t claim to know enough about that landscape to really answer that. But as a developer, I love the simplicity, the configurability via YAML (which also makes it perfect for version control and storing it next to my source code) and the terminal interface. There are certainly fancier and more end-user friendly tools, but it absolutely hits a sweet spot for me.

The details: Defining the agents and their orchestration

To learn how cagent works, I would point you at the official docs, the readme and the usage file. The concept is really easy to understand and the YAML structure to define everything limited to the required elements. So I want make this a general introduction but point you at some key aspects:

First, we have a “root” agent, which gets the initial input and orchestrates the other agents. The root agent has access to subagents:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
agents:
  root:
    model: cloud-gpt-5-chat
    description: "Microsoft Dynamics 365 Business Central development assistant"
    instruction: |
      You are the leader of a team and sub-teams of AI Agents.
      Your task is to coordinate the team to complete the user's request.

      Here are the members in your team:
      <team_members>
      - developer_agent: Analyzes the code base and develops new code
      - reviewer_agent: Analyzes the changes done by the developer_agent and potentially suggests optimizations
      - git_agent: Can make git calls to create branches and commit changes
      </team_members>

      <WORKFLOW>
        1. Call the `developer_agent` to analyze the code base and propose new code
        2. Call the `reviewer_agent` to analyze the changes and make sure they meet the requirements
        3. Call the `git_agent` to create a branch and commit the changes
      </WORKFLOW>
      ...
    sub_agents:
      - developer_agent
      - reviewer_agent
      - git_agent

The agent needs to know which model to use (more on that later) and gets a basic description and instructions. Here we let it know that it has multiple agents at its disposal and how and in which order we want it to interact with them.

The other agents also have access to tools, as mentioned above. E.g., the developer_agent looks like this:

1
2
3
4
5
6
7
8
9
10
11
12
  developer_agent:
    model: cloud-gpt-5-chat
    description: "Expert code analysis and development assistant"
    instruction: |
      ...
    toolsets:
      - type: shell
      - type: filesystem
      - type: todo
      - type: mcp
        command: npx
        args: ["al-mcp-server"]

Here you can see that it has access to the shell to execute commands, to the filesystem to read and write files and to todos to create a multi-step action. Those are built-in tools, so the name is enough. The last tool is the al-mcp-server which allows the agent to understand the AL code in compiled dependencies already in the project (“AL packages”) and work with them. In this case, the MCP server is called via npx. But we can also use the Docker MCP Gateway, which you can see in the configuration of the git_agent:

1
2
3
4
5
6
7
8
9
10
  git_agent:
    model: cloud-gpt-5-chat
    description: "Git expert who uses git to fullfil tasks"
    instruction: |
      ...
    toolsets:
      - type: shell
      - type: filesystem
      - type: mcp
        ref: docker:git

Here we only need the ref: docker:git to point it in the right direction.

As already briefly mentioned above, every agent also needs a model that it uses. And you already saw lines like this model: cloud-gpt-5-chat. The models are configured or made available in a separate section:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
models:
  cloud-gpt-4o:
    provider: openai
    model: gpt-4o
    base_url: https://openai-testtf.openai.azure.com/
    provider_opts:
      azure_api_version: 2025-01-01-preview
  cloud-gpt-5-chat:
    provider: openai
    model: gpt-5-chat
    base_url: https://tobia-mf7gc4qs-eastus2.cognitiveservices.azure.com/
    token_key: GPT5_AZURE_OPENAI_API_KEY
    provider_opts:
      azure_api_version: 2024-12-01-preview
  cloud-gpt-5-mini:
    provider: openai
    model: gpt-5-mini
    base_url: https://tobia-mf7gc4qs-eastus2.cognitiveservices.azure.com/
    token_key: GPT5_AZURE_OPENAI_API_KEY
    provider_opts:
      azure_api_version: 2024-12-01-preview

Here you can see three model definitions: cloud-gpt-4o, cloud-gpt-5-chat and cloud-gpt-5-mini. You probably saw it above, I only used cloud-gpt-5-chat as it got me by far the best results. Each of them needs a provider (in my case openai, but could also be anthropic, google or dmr for the Docker Model Runner) and a model, which is the name of the model to be used as defined by the provider like gpt-4o or gpt-5-chat. That would be enough for “regular” openai, google or anthropic as it now has all information and reads the corresponding API keys from environment variables like OPENAI_API_KEY. I however wanted to use Azure OpenAI. That requires a bit more configuration: At least the base_url where my Azure Open AI / Azure AI Foundry deployment is available and the azure_api_version to identify the version to be used. In this case, the API key is read by default from AZURE_OPENAI_API_KEY, but as you can see, I have different deployments for GPT-4o and GPT-5, so I had to use different keys. That is also configurable via the token_key, which is the name of the environment variable to read the key from.

The details: Support for Azure OpenAI / Azure AI Foundry and devcontainers

What was most impressive for me was the collaboration with the development team. I asked about Azure OpenAI support and it wasn’t there initially, but only a couple hours after I raised the request, there already was a PR. We discussed the implementation a bit, and the team even picked up a suggestion. I am confident that this will make it into one of the next releases, but, like me, you can easily build it yourself thanks to a multi-arch Dockerfile and build task. And I contributed devcontainer support, so setting up your own development environment is also very easy.

The details: Things to note during the coding session

Now if we take a closer look at the coding session, I want to point out a few things related to the topics above:

Here, you can see the root agent reaching out to the developer agent and telling it what to do. I find it very valuable to see how the root agent interpreted my input above, and how it passed it on to the developer agent. This is especially useful for debugging and understanding what happens in cases where the agents don’t work as expected.

In the second screenshot, you can see how the developer agent searches for information about code in the Business Central base application. However, because that code is not available as source code in this specific workspace, but only as a compiled package, it can’t find it. Now, the AL MCP Server kicks in:

As it is an additional tool and the first tool call in this session, cagent asks for permission to use the AL MCP Server, specifically the tool to discover all the compiled packages. I answer this with All, so no further permission requests pop up. After discovery, the agent can then call the tool to search for the specific page, “Item Card”, mentioned in my requirements. I like how cagent shows exactly how it calls the tool, making it easy for me to understand what is happening and potentially improve my prompt if it isn’t what I want.

I also asked the developer agent to make sure everything compiles, to avoid coding issues. This also works through a tool, this time the built-in shell. Again I like how cagent shows the full command so that I know what exactly happens.

With that, the developer agent is finished and the root agent hands it off to the reviewer agent. This is once again pointed out clearly by cagent:

In the end, the last tool, the git MCP server is used to do the required steps for source control: Create a branch, check it out, add the changes and commit them.

Overall, I like how cagent makes it very clear what happens, who calls whom, which tools are used and how. AI-supported development can be really nice if it works, but to be honest, the first try rarely does for me. Maybe I am not good enough at using it, but that is just where I am at the moment. But with the transparency provided by cagent, it was often very clear what went wrong and why, giving me an idea how to improve my prompts.

The details: The full cagent definition

To close it off, here is the full definition that I used. A lot of it is based on the code.yaml and writer.yaml examples in the cagent repo.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
version: "2"

agents:
  root:
    model: cloud-gpt-5-chat
    description: "Microsoft Dynamics 365 Business Central development assistant"
    instruction: |
      You are the leader of a team and sub-teams of AI Agents.
      Your task is to coordinate the team to complete the user's request.

      Here are the members in your team:
      <team_members>
      - developer_agent: Analyzes the code base and develops new code
      - reviewer_agent: Analyzes the changes done by the developer_agent and potentially suggests optimizations
      - git_agent: Can make git calls to create branches and commit changes
      </team_members>

      <WORKFLOW>
        1. Call the `developer_agent` to analyze the code base and propose new code
        2. Call the `reviewer_agent` to analyze the changes and make sure they meet the requirements
        3. Call the `git_agent` to create a branch and commit the changes
      </WORKFLOW>

      - Use the transfer_to_agent tool to call the right agent at the right time to answer the users question.
      - DO NOT transfer to multiple members at once
      - ONLY CALL ONE AGENT AT A TIME
      - When using the `transfer_to_agent` tool,  make exactly one call and wait for the result before making another. Do not batch or parallelize tool calls.

      General Guidelines:
      - Always analyze the user query to identify relevant metadata.
      - Use the most specific filter(s) possible to narrow down results.
      - Use tables to display data
      - Always include sources
    sub_agents:
      - developer_agent
      - reviewer_agent
      - git_agent

  developer_agent:
    model: cloud-gpt-5-chat
    description: "Expert code analysis and development assistant"
    instruction: |
      You are an expert developer with deep knowledge of code analysis, modification, and validation.

      Your main goal is to help users with code-related tasks by examining, modifying, and validating code changes.
      Always use conversation context/state or tools to get information. Prefer tools over your own internal knowledge.

      <TASK>
          # **Workflow:**

          # 1. **Analyze the Task**: Understand the user's requirements and identify the relevant code areas to examine. Use the `al-mcp-server` MCP server to get a good understanding of the al packages available by using the `al_auto_discover` tool and others as needed.

          # 2. **Code Examination**: 
          #    - Search for relevant code files and functions
          #    - Analyze code structure and dependencies
          #    - Identify potential areas for modification

          # 3. **Code Modification**:
          #    - Make necessary code changes
          #    - Ensure changes follow best practices
          #    - Maintain code style consistency

          # 4. **Validation Loop**:
          #    - Verify changes meet requirements and the code compiles successfully by calling the AL compiler. 
          #    - If issues found, return to step 3
          #    - Continue until all requirements are met

          # 5. **Documentation**:
          #    - Document significant changes
          #    - Update relevant comments
          #    - Note any important considerations
      </TASK>

      **Tools:**
      You have access to the following tools to assist you:

      * Filesystem tools for reading and writing code files
      * Search tools for finding relevant code
      * Shell access for running linters and validators
      * DuckDuckGo for research when needed
      * if you need it, the AL compiler is called alc.exe. you can find it in ~\.vscode-insiders\extensions\ms-dynamics-smb.al-17.0.1750311\bin\win32. make sure to specifiy the package cache path .alpackages when calling it

      **Constraints:**

      * **Never mention "tool_code", "tool_outputs", or "print statements" to the user.** These are internal mechanisms for interacting with tools and should *not* be part of the conversation.
      * Be thorough in code examination before making changes
      * Always validate changes before considering the task complete
      * Follow best practices and maintain code quality
      * Be proactive in identifying potential issues
      * Only ask for clarification if necessary, try your best to use all the tools to get the info you need
      * Don't show the code that you generated

    toolsets:
      - type: shell
      - type: filesystem
      - type: todo
      - type: mcp
        command: npx
        args: ["al-mcp-server"]

  reviewer_agent:
    model: cloud-gpt-5-chat
    description: "Expert code analysis and development assistant who reviews the results of others"
    instruction: |
      You are an expert developer with deep knowledge of code analysis, modification, and validation.

      Your main goal is to review the code changes in a specific folder. Use git to understand what is locally changes. You take a thorough look at the changes and figure out whether they meet the requirements or not. You propose optimizations if necessary.

      <TASK>
          # **Workflow:**

          # 1. **Analyze the Task**: Understand the user's requirements and identify the changes that have been made based on the git status. Use the `al-mcp-server` MCP server to get a good understanding of the al packages available by using the `al_auto_discover` tool and others as needed.

          # 2. **Code Examination**: 
          #    - Search for relevant code files and functions
          #    - Analyze code structure and dependencies
          #    - Identify potential areas for modification

          # 3. **Code Review**:
          #    - Check whether the chances truely meet the requirements
          #    - If yes, confirm that to the user
          #    - If no, suggest optimizations

          # 4. **Validation Loop**:
          #    - Verify changes meet requirements and the code compiles successfully by calling the AL compiler. 
          #    - If issues found, return to step 3
          #    - Continue until all requirements are met

          # 5. **Documentation**:
          #    - Document significant changes
          #    - Update relevant comments
          #    - Note any important considerations
      </TASK>

      **Tools:**
      You have access to the following tools to assist you:

      * Filesystem tools for reading and writing code files
      * Search tools for finding relevant code
      * Shell access for running linters and validators
      * DuckDuckGo for research when needed
      * If needed, the AL compiler is called alc.exe. you can find it in ~\.vscode-insiders\extensions\ms-dynamics-smb.al-17.0.1750311\bin\win32. make sure to specifiy the package cache path .alpackages when calling it

      **Constraints:**

      * **Never mention "tool_code", "tool_outputs", or "print statements" to the user.** These are internal mechanisms for interacting with tools and should *not* be part of the conversation.
      * Be thorough in code examination before making changes
      * Always validate changes before considering the task complete
      * Follow best practices and maintain code quality
      * Be proactive in identifying potential issues
      * Only ask for clarification if necessary, try your best to use all the tools to get the info you need
      * Don't show the code that you generated

    toolsets:
      - type: shell
      - type: filesystem
      - type: todo
      - type: mcp
        ref: docker:git
      - type: mcp
        command: npx
        args: ["al-mcp-server"]

  git_agent:
    model: cloud-gpt-5-chat
    description: "Git expert who uses git to fullfil tasks"
    instruction: |
      You are an expert git user that can check changes, create branches and commit and push changes.

      Your goal is to create a branch, switch to that branch and commit the changes. Don't push the changes, the user has to do that.

      **Tools:**
      You have access to the following tools to assist you:

      * Filesystem tools for reading and writing code files
      * Shell access for running linters and validators
      * The git MCP server to execute git commands

      **Constraints:**

      * **Never mention "tool_code", "tool_outputs", or "print statements" to the user.** These are internal mechanisms for interacting with tools and should *not* be part of the conversation.

    toolsets:
      - type: shell
      - type: filesystem
      - type: mcp
        ref: docker:git

models:
  cloud-gpt-4o:
    provider: openai
    model: gpt-4o
    base_url: https://openai-testtf.openai.azure.com/
    provider_opts:
      azure_api_version: 2025-01-01-preview
  cloud-gpt-5-chat:
    provider: openai
    model: gpt-5-chat
    base_url: https://tobia-mf7gc4qs-eastus2.cognitiveservices.azure.com/
    token_key: GPT5_AZURE_OPENAI_API_KEY
    provider_opts:
      azure_api_version: 2024-12-01-preview
  cloud-gpt-5-mini:
    provider: openai
    model: gpt-5-mini
    base_url: https://tobia-mf7gc4qs-eastus2.cognitiveservices.azure.com/
    token_key: GPT5_AZURE_OPENAI_API_KEY
    provider_opts:
      azure_api_version: 2024-12-01-preview

Tech blog by Tobias Fenster

Using Docker Sandbox Kits

The TL;DR

The details: Why more secure - networking

The details: Why more secure - credentials

The details: Another aspect of Sandbox Kits - installs

The details: Claws…

Easier network access for AI Runway

The TL;DR

The details: Istio and body-based router

Deploy LLMs on Azure Kubernetes Service with AI Runway

The TL;DR

The details: Create the AKS cluster and install KAITO

The details: Add AI Runway and expose the dashboard through Traefik

The details: Deploy your first model, expose it, and test over HTTP

The details: Using it with Business Central

Using MCPs with GitHub Copilot without installing anything locally

The TL;DR

Summary: Work Item 33 Analysis

Recommended Implementation Approach:

The details: Other interactions you might like

Best fit — Dimensions

Good fit — Customer Price Group (field 23, Customer Price Group table)

Reasonable fit — Territory Code (field 15, Territory table)

Possible fit — Customer Disc. Group (field 34, Customer Discount Group table)

Limited fit — Statistics Group (field 26, Integer)

Summary recommendation

The details: Setup and configuration

Lessons learned for AI assistant usage with Docker Model Runner on ARM Windows

Lesson 1: If you can’t connect, there might be an easy fix

Lesson 2: Don’t just assume it works, but check

Logging and service monitoring in Windows Containers and AKS

The TL;DR

The details: The container image with ServiceMonitor, LogMonitor and LogMonitorConfig.json

The details: AKS deployment

Running Windows Server 2025 workloads on Azure Kubernetes Service

The TL;DR

The details: Setting up the cluster

The details: Creating and deploying the IIS (and SSH client) container image

The details: Creating and deploying the BC container image

Using the Business Central MCP Server with Visual Studio Code or cagent

The TL;DR

The details: Getting the BcMCPProxy executable

Configuring VS Code

Configuring cagent

Debugging container image creation with a Dockerfile

The TL;DR

The details: My example and basic setup

The details: Debugging

The details: Multi-stage images and debugging immediately

Orchestrate multiple AI agents with cagent by Docker to create a BC/AL coding assistant

The TL;DR

The details: Defining the agents and their orchestration

The details: Support for Azure OpenAI / Azure AI Foundry and devcontainers

The details: Things to note during the coding session

The details: The full cagent definition

Good fit — Customer Price Group (field 23, `Customer Price Group` table)

Reasonable fit — Territory Code (field 15, `Territory` table)

Possible fit — Customer Disc. Group (field 34, `Customer Discount Group` table)