Mastering Deployment: An Easy Guide About Modern Docker Workflow for Depoying .NET 10 application

After responding to the prompts, Docker Init generates three critical files as shown in the below figure.

Dockerfile

The Dockerfile is the recipe for building your container image. For .NET 10, Docker Init typically generates a multi-stage build file as shown below.

# syntax=docker/dockerfile:1

# Comments are provided throughout this file to help you get started.
# If you need more help, visit the Dockerfile reference guide at
# https://docs.docker.com/go/dockerfile-reference/

# Want to help us make this template better? Share your feedback here: https://forms.gle/ybq9Krt8jtBL3iCk7

################################################################################

# Learn about building .NET container images:
# https://github.com/dotnet/dotnet-docker/blob/main/samples/README.md

# Create a stage for building the application.
FROM --platform=$BUILDPLATFORM mcr.microsoft.com/dotnet/sdk:10.0-alpine AS build

COPY . /source

WORKDIR /source

# This is the architecture you're building for, which is passed in by the builder.
# Placing it here allows the previous steps to be cached across architectures.
ARG TARGETARCH

# Build the application.
# Leverage a cache mount to /root/.nuget/packages so that subsequent builds don't have to re-download packages.
# If TARGETARCH is "amd64", replace it with "x64" - "x64" is .NET's canonical name for this and "amd64" doesn't
#   work in .NET 6.0.
RUN --mount=type=cache,id=nuget,target=/root/.nuget/packages \
    dotnet publish -a ${TARGETARCH/amd64/x64} --use-current-runtime --self-contained false -o /app

# If you need to enable globalization and time zones:
# https://github.com/dotnet/dotnet-docker/blob/main/samples/enable-globalization.md
################################################################################
# Create a new stage for running the application that contains the minimal
# runtime dependencies for the application. This often uses a different base
# image from the build stage where the necessary files are copied from the build
# stage.
#
# The example below uses an aspnet alpine image as the foundation for running the app.
# It will also use whatever happens to be the most recent version of that tag when you
# build your Dockerfile. If reproducibility is important, consider using a more specific
# version (e.g., aspnet:7.0.10-alpine-3.18),
# or SHA (e.g., mcr.microsoft.com/dotnet/aspnet@sha256:f3d99f54d504a21d38e4cc2f13ff47d67235efeeb85c109d3d1ff1808b38d034).
FROM mcr.microsoft.com/dotnet/aspnet:10.0-alpine AS final
WORKDIR /app

# Copy everything needed to run the app from the "build" stage.
COPY --from=build /app .

# Switch to a non-privileged user (defined in the base image) that the app will run under.
# See https://docs.docker.com/go/dockerfile-user-best-practices/
# and https://github.com/dotnet/dotnet-docker/discussions/4764
USER $APP_UID

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

Multi-stage builds are the cornerstone of this Dockerfile. They solve a critical problem: if you built your image using only the SDK stage, the final image would be over 2 GB, containing the entire .NET SDK, build tools, source code, and intermediate artifacts. None of these are needed at runtime; they're build-time concerns only.

The multi-stage approach separates concerns:

• Stage 1 (build): Starts from the full .NET SDK (mcr.microsoft.com/dotnet/sdk:10.0), which includes compilers, build tools, and everything needed to compile C#.

• Stage 2 (publish): Runs dotnet publish, which compiles the application in Release mode and packages only the runtime-necessary binaries into an /app/publish folder. Source code is not included.

• Stage 3 (runtime): Starts from a lean ASP.NET Core runtime image (mcr.microsoft.com/dotnet/aspnet:10.0), which contains only the .NET runtime, without the SDK or build tools. The COPY --from=publish instruction brings only the published binaries from Stage 2.

The result: a final image of roughly 150–300 MB (depending on your application), down from over 2 GB—an 80%+ reduction. This has cascading benefits: faster builds, quicker deployments, lower storage and bandwidth costs, and a smaller attack surface for security.

Layer caching is another critical optimization baked into this structure. Docker caches each layer (each line in the Dockerfile). When you change your C# code, Docker rebuilds only the layers after the change, reusing earlier cached layers. By copying *.csproj and running dotnet restore early, you maximize cache hits. If only your code changes (not your dependencies), the restore layer is skipped, and the build is much faster.

.dockerignore

This file tells docker which files to exclude when building the image context. Excluding bin and obj folders are important as these folders contain compiled binaries from your host machine and they are not needed within Docker context. The build would happen inside the container to generate new binaries. Similarly all the irrelevant files/folders are not needed and these are added as part of .dockerignore file.

**/.git
**/.gitignore
**/.vs
**/.vscode
**/bin
**/obj
**/node_modules
......

Compose.yaml

This file orchestrates the local containerized development and is shown below

services:
  server:
    build:
      context: .
      target: final
    ports:
      - 8080:8080

Visual studio code and visual studio is smart enough to provide easy way to run these services by automatically creating "Run all Services" button.

Lets look at each section

• services: Defines services in your stack.

• build: Specifies how to build the image. context: . means "use the current directory as the build context."

• ports: Maps container ports to host ports. "8080:8080" means "forward host port 8080 to container port 8080." When you access localhost:8080 on your development machine, traffic is routed to port 8080 inside the container.

Compose.yaml is your main starting point to run your application inside docker as container. Depending on your application, you can do adjustments to the compose.yaml file and there are clear comments provided in the auto generated file to give you more knowledge about how to add other services like adding PostgreSQL or any other dependencies that your application can use.

Readme.Docker.md

This files provided detailed instructions on how to build and run your application as shown below.

Let's use these instructions to build and run your application. It also provides instructions on how to deploy your application to the cloud.

Building and running your application as a container inside Docker

Once you have adjusted the configuration as per your project needs, you can build and run your application by running below docker command from the terminal

docker compose up --build

"docker compose up" command starts all services defined in your compose.yaml. Instead of executing command, you can also click on "run all services" button within your Visual studio editor.

depending on the size of your base images within your docker file, it takes few minutes to build and run your application as shown in below image.

Once its completed, you can navigate to your application by opening the url https://localhost:8080 within your browser and you can also verify the docker image created by navigating to Images tab within Docker Desktop as shown below.

You can also view application logs directly within your Docker Desktop

Before pushing this to docker hub repository or running in production, scan for any vulnerabilities by using Docker Scout command which is built into the Docker CLI.

Conclusion

Containerizing .NET 10 applications with Docker transforms development workflow and deployment reliability. The docker init tool streamlines the process, generating multi-stage Dockerfiles that produce lean, efficient images. Combined with Docker Compose for local development or managed container services for production, this workflow delivers reproducibility, portability, and operational excellence.

From local development to global deployment, your .NET 10 application now runs consistently, scales elastically, and integrates seamlessly with modern cloud-native infrastructure. The investment in containerization pays dividends in deployment velocity, infrastructure cost, and team productivity.