Is containerd a practical production choice for Windows Server containers?

If the application can be compiled and run reliably as a native Windows executable, that is worth comparing with containers. It avoids the Windows-container compatibility and maintenance issues, although you would then need a service manager or another supervised process model. For domain authentication inside containers, managed service accounts such as gMSA are commonly considered, but the exact approach depends on the application and authentication libraries; test this separately from the basic container runtime.

The main concern is less the containerd binary itself and more the surrounding Windows-container ecosystem. Documentation and installation scripts can be outdated, and features such as networking, identity integration, GPU access, and host patching may require manual operational work. Plan for a tested upgrade process, image/host version alignment, monitoring, and a rollback strategy. It may be a good fit if you have the expertise to own that platform, but it is not necessarily a drop-in replacement for a Linux Docker Compose deployment.

containerd can work on Windows Server 2022 and newer without Docker Desktop, including for some GPU workloads. You’ll still be operating Windows containers, so the image and host build must be compatible—for example, an LTSC 2022 base image with a matching host kernel helps avoid process-isolation problems. You’ll need to handle service registration, CNI networking, image management, logging, and upgrades yourself. nerdctl or Kubernetes can provide a friendlier workflow, but Docker Compose support is not the main strength of this setup. Verify GPU support carefully for your exact Windows image, driver, and runtime combination before committing.