Jenkins Sunsets Windows Server 2019 Agent Containers, Accelerating CI Fleet Modernization

The Jenkins project officially terminated the release and maintenance of official container images based on Windows Server 2019 for both inbound and SSH agent workloads, effective August 21, 2026 [2.1.2]. This step follows the prior removal of Windows Server 2019 container image support in Jenkins core versions 2.569 (weekly) and 2.568.1 (LTS). Moving forward, the Jenkins project will exclusively deliver and maintain official Windows container images built on Windows Server 2022 and Windows Server 2025. This deprecation directly affects enterprise platform teams and CI administrators operating mixed-workload pipelines. Enterprise build fleets frequently rely on Windows agents to compile legacy .NET Framework applications, C++ binaries, and specialized Windows desktop software. Maintaining containerized Windows build infrastructure requires strict compatibility between the host OS kernel and container base images. As upstream cloud platforms—notably Azure Kubernetes Service (AKS), which retired Windows Server 2019 support on March 1, 2026—halt security patches and node image updates, unmanaged legacy agent containers expose build systems to unpatched vulnerabilities and host compatibility failures. This move reflects a broader industry push across DevOps and cloud-native CI tooling to shed legacy OS debt and optimize containerized build fleets. Running ephemeral, dynamic agent pods on Kubernetes has become standard practice for high-throughput development teams. However, Windows containers have historically introduced operational hurdles due to large image footprints and tight host-container kernel matching requirements. By deprecating Server 2019 images, the Jenkins maintainers reduce maintenance overhead while incentivizing teams to align with modern container standards and security baselines on Windows Server 2022 and 2025. In practice, DevOps engineers and Jenkins administrators must immediately audit their agent pod templates, Dockerfiles, and Helm charts. Teams currently pulling official Windows Server 2019 images have two alternatives: migrate build configurations to official Windows Server 2022 or 2025 base images, or assume the maintenance overhead of building and hosting proprietary Windows Server 2019 container images internally. Migrating to newer base images is strongly recommended to ensure ongoing security updates and compatibility with modern Kubernetes node pools. Practitioners should test toolchain dependencies, SDK compatibility, and build performance on Windows Server 2022/2025 environments before cutting over production pipelines.