Containerizing .NET in 2026 Without a Dockerfile
Benjamin Abt explains how the .NET SDK's PublishContainer target can build an OCI image for ASP.NET Core services without a Dockerfile and deliver it to a registry, an archive or a local runtime. The article offers a practical rule for when SDK publishing fits and when a Dockerfile still makes sense.
Key points
- With /t:PublishContainer, the SDK picks the base image from the target framework, RID and AOT settings.
- Setting both ContainerImageTag and ContainerImageTags makes the SDK fail with CONTAINER2008.
- Deploy by the resolved sha256 digest rather than a tag, since tags are mutable pointers.
- Archive output needs no Docker daemon; multi-architecture builds need SDK 8.0.405 or 9.0.102 and later.
- ContainerEnvironmentVariable values are visible in image metadata, so keep secrets out of them.
- The non-root default comes from APP_UID; switching to root with ContainerUser hides write bugs instead of fixing them.
The .NET SDK can build an OCI image for an ASP.NET Core API or worker and push it to a registry, write it to an archive or load it into a local runtime, so many services no longer need a hand-written Dockerfile. The author argues that conventional services should use SDK publishing, shared OS requirements belong in a central base image, and Dockerfiles should remain for builds with shell steps, native compilation or several toolchains.
Useful details include image settings kept in MSBuild, the SDK picking a Microsoft base image from the project shape and runtime, and a non-root user set by default. Tags should be treated as mutable, so deployments should use resolved digests; multi-architecture builds produce an OCI index in one command. The SDK cannot run arbitrary commands, so OS package changes need a custom base image, and the .NET 11 details reflect Preview 7 and need verification.
Real-world use
- An ASP.NET Core team whose services each repeat a 15-20 line Dockerfile can move build settings into the project and a shared props file.
- A release pipeline that writes an OCI archive, then scans, signs and pushes it to a registry as separate stages.
- A platform team that adds corporate certificates or approved packages to every service can manage them in one shared base image.
Why it matters
Standard ASP.NET Core services can drop most Dockerfile maintenance, but image identity should rest on digests and security checks should run against the final image.