Docker Image for .NET 10 — From 800MB Down to Under 50MB with Chiseled Containers

Posted on: 4/20/2026 6:11:32 PM

Have you ever checked the Docker image size of your .NET app and been shocked by the 800MB - 1.2GB figure? That's the reality when you deploy using the default SDK image. With .NET 10, Microsoft brings significant improvements to the container story — from Ubuntu Chiseled images to Native AOT compilation, reducing the image to under 50MB while preserving performance and security.

This article dives deep into each optimization technique, with production-ready Dockerfiles and real benchmarks you can apply to your project right away.

Why Image Size Matters

Docker image size isn't just a number on disk. It directly impacts the entire lifecycle of a containerized application:

• Deploy speed: An 800MB image takes 45-60 seconds to pull from a registry, while a 50MB image takes just 3-5 seconds. When auto-scaling needs to spin up 10 new instances, the difference is 1 minute vs 5 seconds.
• Storage cost: Container registries charge per GB. With CI/CD running multiple times a day — each build creating one image — the cost accumulates quickly.
• Attack surface: Larger image = more packages = more potential CVEs. Images containing bash, apt, curl are an invitation for attackers once they have RCE.
• Cold start: On Kubernetes, pod scheduling depends on image pull time. Smaller images make horizontal scaling more responsive when traffic spikes.

Docker Image Tiers in .NET 10

.NET 10 provides multiple base image variants, each serving a specific purpose. The biggest change: Debian images are no longer shipped for .NET 10 — Ubuntu becomes the default base OS.

graph TD
    A["dotnet/sdk:10.0
~900MB"] --> B["dotnet/aspnet:10.0
~210MB"]
    A --> C["dotnet/runtime:10.0
~190MB"]
    B --> D["dotnet/aspnet:10.0-noble-chiseled
~105MB"]
    C --> E["dotnet/runtime:10.0-noble-chiseled
~95MB"]
    D --> F["dotnet/aspnet:10.0-noble-chiseled-aot
~12MB"]
    E --> G["dotnet/runtime-deps:10.0-noble-chiseled
~13MB"]

    style A fill:#e94560,stroke:#fff,color:#fff
    style B fill:#2c3e50,stroke:#fff,color:#fff
    style C fill:#2c3e50,stroke:#fff,color:#fff
    style D fill:#4CAF50,stroke:#fff,color:#fff
    style E fill:#4CAF50,stroke:#fff,color:#fff
    style F fill:#16213e,stroke:#e94560,color:#fff
    style G fill:#16213e,stroke:#e94560,color:#fff
    

Multi-Stage Build — The Foundation of Optimization

Multi-stage build is the first and most important technique. The idea is simple: use the SDK image to build, but only copy the final artifact into a runtime image for production. Source code, NuGet cache, build tools — all stripped from the final image.

Basic Multi-Stage Dockerfile

# Stage 1: Build
FROM mcr.microsoft.com/dotnet/sdk:10.0 AS build
WORKDIR /src

# Copy csproj first to leverage Docker layer cache
COPY ["MyApi/MyApi.csproj", "MyApi/"]
RUN dotnet restore "MyApi/MyApi.csproj"

# Copy the rest of the source and publish
COPY . .
RUN dotnet publish "MyApi/MyApi.csproj" \
    -c Release \
    -o /app/publish \
    --no-restore

# Stage 2: Runtime
FROM mcr.microsoft.com/dotnet/aspnet:10.0 AS final
WORKDIR /app
COPY --from=build /app/publish .

USER $APP_UID
ENTRYPOINT ["dotnet", "MyApi.dll"]

With this simple multi-stage build alone, the image drops from 900MB down to ~220MB — a 75% reduction.

Optimizing Docker Layer Cache

The COPY order in your Dockerfile directly impacts build speed. Docker cache works on this rule: if a layer changes, every subsequent layer is invalidated.

graph LR
    A["COPY *.csproj"] --> B["dotnet restore"]
    B --> C["COPY source code"]
    C --> D["dotnet publish"]

    style A fill:#4CAF50,stroke:#fff,color:#fff
    style B fill:#4CAF50,stroke:#fff,color:#fff
    style C fill:#e94560,stroke:#fff,color:#fff
    style D fill:#e94560,stroke:#fff,color:#fff
    

# Optimized: copy the solution and all csproj files first
COPY ["Directory.Build.props", "./"]
COPY ["Directory.Packages.props", "./"]
COPY ["MyApi.sln", "./"]
COPY ["src/MyApi/MyApi.csproj", "src/MyApi/"]
COPY ["src/MyApi.Core/MyApi.Core.csproj", "src/MyApi.Core/"]
COPY ["src/MyApi.Infrastructure/MyApi.Infrastructure.csproj", "src/MyApi.Infrastructure/"]

RUN dotnet restore "MyApi.sln"

# Source code changes often → separate layer
COPY . .
RUN dotnet publish "src/MyApi/MyApi.csproj" \
    -c Release \
    -o /app/publish \
    --no-restore

Ubuntu Chiseled — Distroless for .NET

Ubuntu Chiseled is Canonical and Microsoft's answer to Google Distroless. It's an image "chiseled" down from Ubuntu, keeping only the packages that the .NET runtime actually needs.

What Does Chiseled Remove?

Dockerfile with Chiseled Image

# Build stage stays the same
FROM mcr.microsoft.com/dotnet/sdk:10.0 AS build
WORKDIR /src
COPY ["MyApi/MyApi.csproj", "MyApi/"]
RUN dotnet restore "MyApi/MyApi.csproj"
COPY . .
RUN dotnet publish "MyApi/MyApi.csproj" \
    -c Release \
    -o /app/publish \
    --no-restore

# ONLY change: switch to a chiseled image
FROM mcr.microsoft.com/dotnet/aspnet:10.0-noble-chiseled AS final
WORKDIR /app
COPY --from=build /app/publish .

# No need for USER — Chiseled is non-root by default
ENTRYPOINT ["dotnet", "MyApi.dll"]

By changing just one FROM line, the image shrinks from ~220MB down to ~115MB. More importantly, the container runs as a non-root user by default, with no shell for attackers to exploit.

Chiseled Extra and Globalization

If your app needs timezone handling, globalization (ICU), or additional native libraries, .NET 10 provides an -extra variant:

# For apps needing full ICU + timezone
FROM mcr.microsoft.com/dotnet/aspnet:10.0-noble-chiseled-extra AS final

# For apps that only need invariant globalization (simple APIs)
FROM mcr.microsoft.com/dotnet/aspnet:10.0-noble-chiseled AS final

Starting with .NET 10, Chiseled images also ship with a Chisel manifest — letting you install specific packages without falling back to the full Ubuntu image. For example, if you need libgdiplus for image processing:

FROM mcr.microsoft.com/dotnet/aspnet:10.0-noble-chiseled AS final

# Install additional packages via chisel slice
RUN --mount=type=cache,target=/var/cache/chisel \
    chisel cut --root / libgdiplus_lib

Native AOT — The Ultimate Weapon

Native AOT (Ahead-of-Time compilation) compiles your .NET app to native machine code, completely eliminating the .NET runtime and the JIT compiler from the image. The result: your app runs like a C/C++ binary and starts in milliseconds.

graph LR
    subgraph "Traditional (JIT)"
    A1["Source Code"] --> B1["IL Code (.dll)"]
    B1 --> C1[".NET Runtime
JIT Compile"]
    C1 --> D1["Machine Code"]
    end

    subgraph "Native AOT"
    A2["Source Code"] --> B2["IL Code"]
    B2 --> C2["AOT Compiler
(build time)"]
    C2 --> D2["Native Binary"]
    end

    style C1 fill:#e94560,stroke:#fff,color:#fff
    style D1 fill:#f8f9fa,stroke:#e0e0e0,color:#2c3e50
    style C2 fill:#4CAF50,stroke:#fff,color:#fff
    style D2 fill:#4CAF50,stroke:#fff,color:#fff
    style A1 fill:#f8f9fa,stroke:#e0e0e0,color:#2c3e50
    style B1 fill:#f8f9fa,stroke:#e0e0e0,color:#2c3e50
    style A2 fill:#f8f9fa,stroke:#e0e0e0,color:#2c3e50
    style B2 fill:#f8f9fa,stroke:#e0e0e0,color:#2c3e50
    

Configuring Native AOT in .csproj

<Project Sdk="Microsoft.NET.Sdk.Web">
  <PropertyGroup>
    <TargetFramework>net10.0</TargetFramework>
    <PublishAot>true</PublishAot>
    <StripSymbols>true</StripSymbols>
    <InvariantGlobalization>true</InvariantGlobalization>
    <IlcOptimizationPreference>Size</IlcOptimizationPreference>
  </PropertyGroup>
</Project>

Dockerfile: Native AOT + Chiseled

# Build with AOT — needs extra native build tools
FROM mcr.microsoft.com/dotnet/sdk:10.0 AS build
RUN apt-get update && apt-get install -y clang zlib1g-dev
WORKDIR /src

COPY ["MyApi/MyApi.csproj", "MyApi/"]
RUN dotnet restore "MyApi/MyApi.csproj"
COPY . .
RUN dotnet publish "MyApi/MyApi.csproj" \
    -c Release \
    -o /app/publish

# Runtime: only runtime-deps, no .NET runtime required
FROM mcr.microsoft.com/dotnet/runtime-deps:10.0-noble-chiseled AS final
WORKDIR /app
COPY --from=build /app/publish .

ENTRYPOINT ["./MyApi"]

dotnet publish container — No Dockerfile Needed

.NET 10 supports building a container image directly from dotnet publish without writing a Dockerfile:

# Publish directly as a container image
dotnet publish /t:PublishContainer \
    -c Release \
    --os linux \
    --arch x64 \
    -p:ContainerImageName=myapi \
    -p:ContainerImageTag=1.0.0

# With a chiseled base image
dotnet publish /t:PublishContainer \
    -c Release \
    --os linux \
    -p:ContainerBaseImage=mcr.microsoft.com/dotnet/aspnet:10.0-noble-chiseled \
    -p:ContainerImageName=myapi

# Push directly to a registry
dotnet publish /t:PublishContainer \
    -c Release \
    -p:ContainerRegistry=myregistry.azurecr.io \
    -p:ContainerImageName=myapi \
    -p:ContainerImageTag=latest

Container configuration in .csproj:

<PropertyGroup>
  <ContainerBaseImage>mcr.microsoft.com/dotnet/aspnet:10.0-noble-chiseled</ContainerBaseImage>
  <ContainerImageName>myapi</ContainerImageName>
  <ContainerPort Include="8080" Type="tcp" />
  <ContainerUser>1654</ContainerUser>
</PropertyGroup>

Container Security Hardening

Reducing image size and strengthening security are two sides of the same coin. Below are the key practices for deploying .NET containers to production:

1. Run as Non-Root

# With the full Ubuntu image — set USER manually
FROM mcr.microsoft.com/dotnet/aspnet:10.0 AS final
WORKDIR /app
COPY --from=build /app/publish .

# Create a dedicated user (UID 1654 is the .NET image convention)
USER 1654
ENTRYPOINT ["dotnet", "MyApi.dll"]

# With Chiseled — already non-root by default, nothing needed

2. Read-Only Filesystem

# docker-compose.yml
services:
  myapi:
    image: myapi:latest
    read_only: true
    tmpfs:
      - /tmp
    security_opt:
      - no-new-privileges:true

# Kubernetes pod spec
spec:
  containers:
    - name: myapi
      image: myapi:latest
      securityContext:
        readOnlyRootFilesystem: true
        runAsNonRoot: true
        runAsUser: 1654
        allowPrivilegeEscalation: false
        capabilities:
          drop: ["ALL"]
      volumeMounts:
        - name: tmp
          mountPath: /tmp
  volumes:
    - name: tmp
      emptyDir: {}

3. Vulnerability Scanning

# Scan image with Trivy
trivy image myapi:latest

# Scan in CI pipeline (fail on HIGH/CRITICAL)
trivy image --exit-code 1 --severity HIGH,CRITICAL myapi:latest

# Docker Scout (built into Docker Desktop)
docker scout cves myapi:latest
docker scout recommendations myapi:latest

Comprehensive Production Dockerfile

Here's a production-grade Dockerfile that combines all the techniques we've covered:

# ============================================
# Stage 1: Restore dependencies (cached layer)
# ============================================
FROM mcr.microsoft.com/dotnet/sdk:10.0 AS restore
WORKDIR /src

COPY ["Directory.Build.props", "./"]
COPY ["Directory.Packages.props", "./"]
COPY ["MyApi.sln", "./"]
COPY ["src/MyApi/MyApi.csproj", "src/MyApi/"]
COPY ["src/MyApi.Core/MyApi.Core.csproj", "src/MyApi.Core/"]
COPY ["src/MyApi.Infrastructure/MyApi.Infrastructure.csproj", "src/MyApi.Infrastructure/"]

RUN dotnet restore "MyApi.sln"

# ============================================
# Stage 2: Build and publish
# ============================================
FROM restore AS publish
COPY . .
RUN dotnet publish "src/MyApi/MyApi.csproj" \
    -c Release \
    -o /app/publish \
    --no-restore \
    /p:DebugType=None \
    /p:DebugSymbols=false

# ============================================
# Stage 3: Production runtime
# ============================================
FROM mcr.microsoft.com/dotnet/aspnet:10.0-noble-chiseled AS final

LABEL maintainer="team@example.com"
LABEL org.opencontainers.image.source="https://github.com/org/myapi"

WORKDIR /app
COPY --from=publish /app/publish .

ENV DOTNET_EnableDiagnostics=0
ENV ASPNETCORE_URLS=http://+:8080

EXPOSE 8080

HEALTHCHECK --interval=30s --timeout=3s --start-period=5s --retries=3 \
    CMD ["dotnet", "MyApi.dll", "--urls", "http://localhost:8080/health"]

ENTRYPOINT ["dotnet", "MyApi.dll"]

Real-World Image Size Benchmark

Below are measured results for a typical ASP.NET Core Web API (3 controllers, Entity Framework Core, Serilog, Swagger):

xychart-beta
    title "Docker image size by configuration (MB)"
    x-axis ["SDK", "Runtime", "Chiseled", "Chiseled+Trim", "AOT+Chiseled", "AOT+Size"]
    y-axis "MB" 0 --> 950
    bar [912, 225, 118, 82, 42, 14]
    

CI/CD Pipeline Integration

An optimized Dockerfile only delivers its full benefit alongside a matching CI/CD pipeline. Here's an example with GitHub Actions:

name: Build and Push
on:
  push:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v3

      - name: Login to ACR
        uses: docker/login-action@v3
        with:
          registry: myregistry.azurecr.io
          username: ${{ secrets.ACR_USERNAME }}
          password: ${{ secrets.ACR_PASSWORD }}

      - name: Build and push
        uses: docker/build-push-action@v6
        with:
          context: .
          push: true
          tags: myregistry.azurecr.io/myapi:${{ github.sha }}
          cache-from: type=gha
          cache-to: type=gha,mode=max

      - name: Scan for vulnerabilities
        uses: aquasecurity/trivy-action@master
        with:
          image-ref: myregistry.azurecr.io/myapi:${{ github.sha }}
          severity: HIGH,CRITICAL
          exit-code: 1

Common Mistakes

Mistake 1: COPY everything before restore

# WRONG — every source change invalidates the restore cache
COPY . .
RUN dotnet restore
RUN dotnet publish

# RIGHT — separate csproj and source
COPY ["*.csproj", "./"]
RUN dotnet restore
COPY . .
RUN dotnet publish

Mistake 2: Leaving PDB files in the image

# Add to the publish command
RUN dotnet publish -c Release -o /app \
    /p:DebugType=None \
    /p:DebugSymbols=false

Mistake 3: Running containers as root

# Always set USER at the end of the Dockerfile (if not using Chiseled)
RUN adduser --disabled-password --gecos "" appuser
USER appuser

Mistake 4: Building for the wrong platform

# Build multi-platform image
docker buildx build \
    --platform linux/amd64,linux/arm64 \
    -t myregistry.azurecr.io/myapi:latest \
    --push .

Pre-Deploy Optimization Checklist

Run through this checklist before pushing an image to your production registry:

Conclusion

Optimizing Docker images for .NET 10 isn't a complex technique, but few teams actually apply it fully. With just 3 simple steps — multi-stage build, switching to Chiseled images, and enabling trimming — you can reduce image size by 90% without changing a single line of application code.

With Native AOT, that number can reach 98%. A 14MB image that starts in 15ms — ideal for serverless, edge computing, and auto-scaling workloads.

Start with the simplest step: replace aspnet:10.0 with aspnet:10.0-noble-chiseled in your current Dockerfile. You'll see the result immediately.

References

• .NET Docker — Ubuntu Chiseled Documentation
• Containerize .NET 10 Apps Without a Dockerfile — CodeWithMukesh
• 12 Tips to Optimize .NET Containers for Kubernetes — Google Cloud
• .NET Chiseled Containers: A Revolution in Deployment Efficiency
• Microsoft Learn — Publish as Container