.NET 8 Docker Images After End of Support: mcr.microsoft.com Tags and What Changes

The short answer

On 10 November 2026, when .NET 8 reaches end of support, Microsoft stops supporting every .NET 8 tag on mcr.microsoft.com: the sdk, aspnet, runtime and runtime-deps 8.0 images in all their variants. The images stay pullable, so nothing breaks on the day, but Microsoft's policy is that unsupported tags "will no longer receive updates for any reason". No more .NET servicing releases, no rebuilds when Debian or Ubuntu ship OS fixes, and no critical CVE rebuilds. Your scanners will report a growing list of findings on any image built from them. The supported destination is the 10.0 tags, which follow .NET 10 to 14 November 2028.

The date comes from the runtime itself. Our .NET 8 end of support date page covers what ends across .NET as a whole.

What Microsoft does for supported .NET images, and what stops

The dotnet-docker repository publishes an image update policy. While a tag is supported:

Microsoft's platform policy says it stops publishing updates when the .NET version reaches end of support or when the OS base image stops receiving updates, whichever happens first. Its vulnerability guidance spells out the consequence: an unsupported tag is not updated "even when there is a new base OS image available", so vulnerabilities will be reported against it over time. The image you pull in December is frozen at whatever Microsoft last published.

Microsoft also treats only the tags shown in its full tag listings as supported, so those listings are the quickest check of whether a tag you rely on still gets updates.

Which .NET 8 tags exist, and what they resolve to

At the time of writing, the latest .NET 8 release is 8.0.31, from 8 September 2026.

A floating tag such as 8.0 has protected you so far because each rebuild moved it to the newest patch and the newest OS packages. After end of support it stops moving, so it gives you no more protection than a fixed tag pinned to the final release.

How to find .NET 8 images in your estate

Dockerfiles in source control

grep -rnE "mcr\.microsoft\.com/dotnet/(sdk|aspnet|runtime|runtime-deps):8\.0" \
  --include="Dockerfile*" --include="*.dockerfile" .

Check both stages of multi-stage builds. A build stage on sdk:8.0 with a runtime stage on aspnet:10.0 will not build a net10.0 app; the two have to move together. Also check projects that publish images with dotnet publish -t:PublishContainer. The SDK chooses a Microsoft base image for them, so they never appear in a Dockerfile search.

Images on build hosts

docker images --format '{{.Repository}}:{{.Tag}}' | grep -E 'dotnet/(sdk|aspnet|runtime|runtime-deps):8\.0'

Your own application images

Application images are tagged with your app name, not the base image, so the tag tells you nothing. Microsoft's runtime and aspnet images set environment variables that survive into images built from them, DOTNET_VERSION and ASPNET_VERSION, and you can read them without starting a container, which matters for chiseled images with no shell:

docker image inspect --format '{{range .Config.Env}}{{println .}}{{end}}' myregistry/orders-api:2026.10 \
  | grep -E '^(DOTNET|ASPNET)_VERSION='

A result of DOTNET_VERSION=8.0.31 means a .NET 8 runtime. runtime-deps images do not set it, because they are used for self-contained apps that bring their own runtime; check the build for those. Run the same inspection across the images your Kubernetes clusters are running to see what is actually deployed rather than what the repository says.

Moving from 8.0 to 10.0 tags: what changes

The default Linux distribution changes

This is the change most likely to break a build. For .NET versions before 10, the multi-platform tags such as 8.0 resolve to Debian. For .NET 10, they resolve to Ubuntu: aspnet:10.0 and latest point to Ubuntu 24.04 (noble). Microsoft's tag listing for 10.0 has no Debian images, and its platform policy says new .NET images will not be added for future Debian versions. A Dockerfile that runs apt-get install with Debian package names may fail, or install different library versions, on the Ubuntu base. Test any image that installs packages.

10.0 tags are published for Ubuntu 24.04 and 26.04, Alpine 3.23 and 3.24, and Azure Linux 3.0, including an Azure Linux distroless variant. If you need to stay close to your current base, pick an OS-specific tag deliberately instead of relying on the default.

A typical Dockerfile change

# Before
FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
WORKDIR /src
COPY . .
RUN dotnet publish -c Release -o /app

FROM mcr.microsoft.com/dotnet/aspnet:8.0
WORKDIR /app
COPY --from=build /app .
ENTRYPOINT ["dotnet", "MyApp.dll"]

# After
FROM mcr.microsoft.com/dotnet/sdk:10.0-noble AS build
WORKDIR /src
COPY . .
RUN dotnet publish -c Release -o /app

FROM mcr.microsoft.com/dotnet/aspnet:10.0-noble-chiseled
WORKDIR /app
COPY --from=build /app .
ENTRYPOINT ["dotnet", "MyApp.dll"]

Change TargetFramework to net10.0 at the same time. For reproducible builds, pin the final image by digest; Microsoft notes that digest pinning is the only way to request a specific OS patch.

Chiseled and distroless images

Ubuntu Chiseled images contain only the packages .NET needs. They run as a non-root user by default and have no package manager and no shell. Microsoft publishes them for both versions, as 8.0-noble-chiseled and 10.0-noble-chiseled. If your Dockerfile does not depend on shell scripts at startup, Microsoft says a chiseled image can be a drop-in replacement for the full Ubuntu or Debian image. The upgrade to 10.0 is a good time to make that switch.

Chiseled images exclude ICU and time zone data, so they suit apps in globalisation-invariant mode. Apps that need culture data use the extra variant, such as 10.0-noble-chiseled-extra. To add packages to a chiseled image you need the Chisel manifest, which Microsoft includes only in .NET 10 and later images, another reason to move rather than chisel on 8.0. .NET 10 also adds an aot variant of the SDK image with the extra libraries native AOT compilation needs.

The latest tag

The latest tag refers to the latest stable .NET release, which today is .NET 10. Images built FROM aspnet:latest are already on .NET 10. Pin a major version instead, so the next major release does not arrive by surprise.

A checklist for the move

1. Search Dockerfiles, SDK container publish settings and running images for .NET 8 using the commands above.
2. Retarget each project to net10.0 and fix the breaking changes; our .NET 8 to .NET 10 upgrade guide lists them.
3. Move the build and runtime stages together to 10.0 tags, choosing the OS on purpose.
4. Rebuild, scan and test any image that installs OS packages on the new base.
5. Pin by digest and set up automated rebuilds so the 10.0 images keep picking up Microsoft's monthly refreshes.

If some images cannot move by 10 November

For most services, moving to 10.0 tags alongside the .NET 10 upgrade is the right answer. The images that cannot move are usually the ones whose application cannot yet be retargeted.

For those, OSSeva for .NET keeps .NET 8 patched past 10 November 2026 and ships patched Docker base images for both the .NET SDK, for the build stage, and the ASP.NET Core runtime, for the runtime stage, in Alpine and Debian variants. They are drop-in replacements: change the FROM line, rebuild and redeploy. Artifacts are signed with GPG and Sigstore, so the images can be verified in your pipeline. OSSeva's patched builds cover .NET (Core and 5 and later); .NET Framework images are outside them. See .NET 8 extended support and our comparison of .NET 8 extended support providers. OSSeva for .NET is priced per application runtime environment; book a discovery call for a quote.

Frequently asked questions

Will mcr.microsoft.com/dotnet/aspnet:8.0 still pull after 10 November 2026?

Yes. Microsoft's tag policy says unsupported tags and images can still be pulled. They just stop receiving updates for any reason.

Will Microsoft rebuild .NET 8 images for OS security fixes after end of support?

No. Microsoft stops publishing updates to images when the .NET version in them reaches end of support, and its vulnerability guidance says an unsupported tag is not updated even when a new base OS image is available.

Does the .NET 10 Docker image use Debian?

No. For .NET 10, the multi-platform tags such as 10.0 resolve to Ubuntu 24.04. Microsoft publishes 10.0 images for Ubuntu, Alpine and Azure Linux, and its tag listing shows no Debian 10.0 images.

How do I tell which .NET version a container image uses?

Inspect the image's environment variables with docker image inspect and look for DOTNET_VERSION and ASPNET_VERSION, which Microsoft's runtime and aspnet images set. Self-contained apps on runtime-deps images do not have them; check how those were built.

What are chiseled .NET images?

Distroless Ubuntu images that contain only the packages .NET needs, run as non-root by default, and have no shell or package manager. They are available for .NET 8 and .NET 10, and only the .NET 10 and later images support adding packages through the Chisel manifest.

Will my vulnerability scanner flag .NET 8 images after end of support?

Expect it to. The runtime itself is out of support, and because the images are no longer rebuilt, OS-level vulnerabilities found after the final rebuild stay in them and accumulate.

Does the latest tag still point to .NET 8?

No. latest refers to the latest stable .NET release, which is .NET 10.