How to Dockerize and Deploy .NET

This Dockerfile publishes your ASP.NET Core app with the .NET SDK image, then runs the output on the smaller ASP.NET runtime image, using a multi-stage build to keep the final image lean.

If you're just here to copy and paste, here's the final Dockerfile that will produce an image for your .NET app:

FROM mcr.microsoft.com/dotnet/sdk:9.0 AS build
WORKDIR /src

# Restore dependencies first so this layer is cached when only source changes
COPY *.csproj ./
RUN dotnet restore

# Publish a Release build
COPY . .
RUN dotnet publish -c Release -o /app

FROM mcr.microsoft.com/dotnet/aspnet:9.0 AS runtime
WORKDIR /app
COPY --from=build /app ./

# Replace YourApp.dll with the name of your project's dll
ENV ASPNETCORE_URLS=http://+:8080
EXPOSE 8080
ENTRYPOINT ["dotnet", "YourApp.dll"]

And here's the .dockerignore file:

bin
obj
.git
.vs

To build and run the image, use these commands:

docker build -t dotnet-app .
docker run -p 8080:8080 dotnet-app

Not just here to copy and paste? Let's go over what's happening in the Dockerfile!

The Setup

For this tutorial, I assume you have an ASP.NET Core web app or API. Locally you run dotnet run, which compiles and starts the app in one step. For production we want a compiled, optimized build and the smallest possible runtime, so we use two images: the SDK to build and the runtime to serve.

The Dockerfile

The build stage uses the full SDK:

1. Base image:

• Uses mcr.microsoft.com/dotnet/sdk:9.0, which contains the compiler and all the build tooling.

2. Dependency restore:

• Copies the .csproj file first and runs dotnet restore. Because this happens before the rest of the code, Docker caches your NuGet packages and only restores again when the project file changes.

3. Publish step:

• Runs dotnet publish -c Release -o /app, which compiles a Release build and writes the ready-to-run output to /app.

The runtime stage is much smaller:

4. Runtime image:

• Uses mcr.microsoft.com/dotnet/aspnet:9.0, which has only the ASP.NET runtime, not the SDK.
• Copies the published output from the build stage.
• Sets ASPNETCORE_URLS=http://+:8080 so the app listens on port 8080 on all interfaces. Recent .NET container images default to 8080, and setting it explicitly removes any doubt.
• Starts the app with dotnet YourApp.dll. Replace YourApp.dll with your actual assembly name, which matches your project name.

Keep configuration such as connection strings in environment variables. ASP.NET Core reads them out of the box, and double underscores map to nested keys, so ConnectionStrings__Default sets the Default connection string.

Deployment

You can deploy this Docker container to any cloud provider that supports Docker. For example, you could use platforms like Heroku, DigitalOcean, or AWS ECS. Because I am the co-founder of Sliplane, I will show you how to deploy it there.

After signing up, you can create a new service by selecting your GitHub repository. Then keep the default settings, add any environment variables your app needs, and click deploy.

After deployment your .NET app will be available under a subdomain of sliplane.app, usually it's just your service name.

You can also see the logs of your app, view metrics such as CPU and memory usage, add persistent storage, and much more. Whenever you push to your repository, Sliplane will automatically deploy your app.

If you want to try out Sliplane, the first 2 days are free! Try it out and let me know what you think :)

Next Steps

If you have several projects in one solution, adjust the restore and publish steps to point at the specific .csproj you want to ship. Want help with that, or with running EF Core migrations on deploy? Feel free to reach out!

Cheers,

Lukas