Docker

codewithmukesh/dotnet-claude-kit/skills/docker

by codewithmukesh23300897f4d1No license754 starsListed Oct 8, 2026Updated Oct 8, 2026Repository updated 2 months ago

Docker containerization for .NET 10 applications. Covers multi-stage builds, .NET container images, non-root user configuration, health checks, and .dockerignore. Load this skill when containerizing an application with a Dockerfile, optimizing image size, setting up Docker Compose for local development, or when the user mentions "Docker", "Dockerfile", "container", "docker-compose", "image", "multi-stage", "non-root", ".dockerignore", or "container health check". For Dockerfile-less SDK publishing (`dotnet publish /t:PublishContainer`), load the container-publish skill instead.

Instructions onlyDevOps & Cloud
AI-generated overview

Guidance for containerizing .NET 10 apps with Docker: multi-stage Dockerfiles, non-root users, health probes, and Compose.

What it does
This skill provides reference guidance for containerizing .NET 10 applications with Docker. It covers multi-stage Dockerfile patterns, .NET SDK and ASP.NET runtime images, non-root user configuration, layer caching for NuGet restore, .dockerignore contents, health probe approaches, and Docker Compose for local development. It also lists anti-patterns such as using the SDK image at runtime, copying source before restore, and running as root.
When to use it
Use it when writing or reviewing a Dockerfile for a .NET application, optimizing image size, setting up Docker Compose for local development, or configuring container health checks. It is also relevant when the user mentions Docker, Dockerfile, container, docker-compose, multi-stage, non-root, .dockerignore, or container health check.
Requirements
No scripts or assets ship with the skill; it is instructions only. Following its examples assumes Docker, the .NET 10 SDK and ASP.NET runtime images, and optionally Docker Compose or Kubernetes for orchestrator-level health probes.

Docker

Core Principles

  1. Multi-stage builds always — Separate build and runtime stages. Build in the SDK image, run in the ASP.NET runtime image.
  2. Non-root by default — .NET container images support USER app by default since .NET 8. Never run as root in production.
  3. Layer caching matters — Copy .csproj files and restore before copying source code. This caches NuGet dependencies across builds.
  4. Health probes at the orchestrator level — Expose a /health/live endpoint and let Kubernetes/Compose probe it. Chiseled and default aspnet images have no shell or curl, so in-image HEALTHCHECK commands have nothing to run with.

Patterns

Multi-Stage Dockerfile for Web API

dockerfile
# Stage 1: BuildFROM mcr.microsoft.com/dotnet/sdk:10.0 AS buildWORKDIR /src
# Copy project files and restore (cached layer)COPY ["src/MyApp.Api/MyApp.Api.csproj", "src/MyApp.Api/"]COPY ["src/MyApp.Domain/MyApp.Domain.csproj", "src/MyApp.Domain/"]COPY ["Directory.Build.props", "."]COPY ["Directory.Packages.props", "."]RUN dotnet restore "src/MyApp.Api/MyApp.Api.csproj"
# Copy everything and buildCOPY . .RUN dotnet publish "src/MyApp.Api/MyApp.Api.csproj" \    -c Release \    -o /app/publish \    --no-restore
# Stage 2: RuntimeFROM mcr.microsoft.com/dotnet/aspnet:10.0 AS runtimeWORKDIR /app
# Non-root user (default in .NET 8+ images)USER app
COPY --from=build /app/publish .
EXPOSE 8080
ENTRYPOINT ["dotnet", "MyApp.Api.dll"]

Container Health Probes

Prefer orchestrator-level probes (Kubernetes livenessProbe, Compose healthcheck) over a Dockerfile HEALTHCHECK — the standard aspnet and chiseled images ship no shell, no curl, and no wget, so there is nothing inside the container to run the probe with. Point the orchestrator at /health/live:

yaml
# docker-compose — probe from outside the app processservices:  api:    healthcheck:      test: ["CMD-SHELL", "wget -qO- http://localhost:8080/health/live || exit 1"]      interval: 30s      timeout: 3s      retries: 3# Note: CMD-SHELL requires a shell + wget in the image. Use a non-chiseled# variant for this, or better: let Kubernetes httpGet probes do it —# they run from the kubelet, needing nothing inside the image.

If you must have an in-image HEALTHCHECK, base the runtime stage on a non-chiseled image that includes wget — never re-run the app binary as the probe command; that starts a second instance instead of checking the first.

.dockerignore

**/.git**/.vs**/bin**/obj**/node_modules**/Dockerfile***/docker-compose***/tests

Docker Compose for Local Development

Key .NET-specific concerns — pass connection strings via environment, use depends_on with health checks:

yaml
services:  api:    build:      context: .      dockerfile: src/MyApp.Api/Dockerfile    ports:      - "5000:8080"    environment:      - ASPNETCORE_ENVIRONMENT=Development      - ConnectionStrings__Default=Host=postgres;Database=myapp;Username=postgres;Password=postgres      - ConnectionStrings__Redis=redis:6379    depends_on:      postgres:        condition: service_healthy  # Add postgres/redis services with healthcheck — standard boilerplate

Optimized Build with .slnx

For solutions with multiple projects, restore only the necessary projects.

dockerfile
FROM mcr.microsoft.com/dotnet/sdk:10.0 AS buildWORKDIR /src
# Copy solution and all project filesCOPY *.slnx .COPY Directory.Build.props .COPY Directory.Packages.props .COPY src/**/*.csproj ./src/
# Restore project structureRUN for file in src/**/*.csproj; do \    mkdir -p $(dirname $file) && mv $file $(dirname $file)/; \    doneRUN dotnet restore
COPY . .RUN dotnet publish src/MyApp.Api -c Release -o /app/publish --no-restore

Health Check Endpoint

csharp
// In Program.cs — lightweight health endpoint for Dockerapp.MapGet("/health/live", () => Results.Ok("healthy"))    .ExcludeFromDescription();

Anti-patterns

Don't Use SDK Image for Runtime

dockerfile
# BAD — SDK image is 900MB+, includes compilersFROM mcr.microsoft.com/dotnet/sdk:10.0COPY . .RUN dotnet run
# GOOD — separate build and runtime, runtime image is ~200MBFROM mcr.microsoft.com/dotnet/aspnet:10.0

Don't Copy Everything Before Restore

dockerfile
# BAD — any source change invalidates the NuGet cacheCOPY . .RUN dotnet restore
# GOOD — copy only project files first, then restoreCOPY ["src/MyApp.Api/MyApp.Api.csproj", "src/MyApp.Api/"]RUN dotnet restore "src/MyApp.Api/MyApp.Api.csproj"COPY . .

Don't Run as Root

dockerfile
# BAD — running as root (security risk)FROM mcr.microsoft.com/dotnet/aspnet:10.0COPY --from=build /app .ENTRYPOINT ["dotnet", "MyApp.Api.dll"]
# GOOD — use the built-in non-root userFROM mcr.microsoft.com/dotnet/aspnet:10.0USER appCOPY --from=build /app .ENTRYPOINT ["dotnet", "MyApp.Api.dll"]

Decision Guide

ScenarioRecommendation
Web API containerMulti-stage build with aspnet runtime image
Worker serviceMulti-stage build with dotnet/runtime image
Local developmentDocker Compose with service dependencies
CI buildsMulti-stage build (self-contained)
Image size optimizationUse Alpine variant + trimming for small images
Health monitoring/health endpoint + orchestrator probe (K8s httpGet / Compose healthcheck)
SecretsEnvironment variables or mounted secrets, never in image

Source and attribution

Source:codewithmukesh/dotnet-claude-kitinskills/dockerat commit2330089

License: No license

Content belongs to its original authors. SourceWeft indexes it from a public repository.

Report or request removal

More from codewithmukesh/dotnet-claude-kit

Wrap Up

codewithmukesh

Captures end-of-session work, pending tasks and learnings into a handoff file, and reloads it at session start.

Productivity & Workflow754updated 2 months ago

Workflow Mastery

codewithmukesh

Claude Code workflow mastery for .NET developers. Covers parallel execution with git worktrees, plan mode strategy, verification loops, auto-formatting hooks, permission setup for dotnet CLI, prompting techniques, subagent patterns, and context discipline — token budget management, MCP-first navigation, lazy loading, and subagent isolation — all adapted for the .NET ecosystem. Load this skill when setting up Claude Code for a .NET project, optimizing workflows, running parallel sessions, when context is running low or sessions feel sluggish, when exploring a large codebase efficiently, or when the user mentions "productivity", "workflow", "parallel", "worktree", "plan mode", "permissions", "hooks", "10x", "setup Claude Code", "speed up development", "context", "tokens", "budget", "running out of context", "too many files", or "large codebase". Inspired by tips from Boris Cherny (creator of Claude Code) and the Anthropic team.

Awaiting classification754updated 2 months ago

Vertical Slice

codewithmukesh

Guides .NET developers in structuring applications with Vertical Slice Architecture, covering feature folders, endpoint grouping and handler patterns.

Software Development754updated 2 months ago

Testing

codewithmukesh

Testing strategy for .NET 10 applications. Covers xUnit v3, WebApplicationFactory for integration tests, Testcontainers for real database testing, Verify for snapshot testing, and the AAA pattern. Load this skill when writing tests, setting up test infrastructure, reviewing test coverage, or when the user mentions "test", "xUnit", "WebApplicationFactory", "Testcontainers", "integration test", "unit test", "bUnit", "snapshot test", "Verify", "test coverage", "AAA pattern", "WireMock", or "FakeTimeProvider".

Awaiting classification754updated 2 months ago

Tdd

codewithmukesh

Guided test-driven development workflow for .NET 10 using xUnit v3, WebApplicationFactory, Testcontainers, and Verify snapshots. Follows the strict red-green-refactor cycle. Use when: "TDD", "test-driven", "let's TDD this", "red green refactor", "write the test first", or when building a feature with clear acceptance criteria.

Awaiting classification754updated 2 months ago

Spec

codewithmukesh

Turns a vague feature idea into an agreed, persisted specification file through structured questioning rounds.

Productivity & Workflow754updated 2 months ago
Docker · skills/docker Agent Skill | SourceWeft