GitHub Actions Windows Server 2025 Transition and Runner Image Ecosystem

The architectural landscape of GitHub Actions is undergoing a significant shift as the platform migrates its default Windows environment. For developers and DevOps engineers, the windows-latest label serves as a convenient pointer to the most stable, current version of the Windows operating system provided by GitHub. However, this convenience introduces a layer of volatility during migration periods. Beginning September 2, 2025, and concluding by September 30, 2025, GitHub is transitioning the windows-latest label from Windows Server 2022 to Windows Server 2025. This transition is not instantaneous but gradual, meaning workflows will oscillate between the old and new images until the migration is finalized. Once a workflow has been migrated to Windows Server 2025, it will not revert to Windows Server 2022 for any future executions.

This migration is the culmination of a process that began on April 8, 2025, when the Windows Server 2025 image first became generally available (GA) for all customers. GitHub spent the intervening months monitoring customer feedback to refine image stability before committing to the windows-latest designation. This transition is critical because the Windows Server 2025 image contains different tooling and a modified package set compared to its predecessor. To maintain Service Level Agreements (SLA) regarding free disk space, GitHub has intentionally removed specific packages from the Windows Server 2025 image. Consequently, teams that rely on the windows-latest label must proactively audit their toolchains to prevent pipeline failures during the September transition window.

REST API Enhancements for Actions Policy Management

Parallel to the infrastructure updates, GitHub has introduced new REST APIs designed to programmatically manage settings that were previously handled through manual UI configurations. This shift allows enterprises and organization administrators to treat their CI/CD policies as code, enabling automated auditing and rapid deployment of security configurations.

The new API endpoints provide control over the following specific settings:

Approval for running fork pull request workflows from contributors
Allowing workflows on fork pull requests in private repositories
Setting which repositories are permitted to create repository-level self-hosted runners
Setting artifact and log retention periods

The implementation of these APIs at the enterprise, organization, and repository levels removes the bottleneck of manual reviews. By utilizing these endpoints, a DevOps team can ensure that retention policies for logs and artifacts are consistent across hundreds of repositories without manual intervention. This is particularly impactful for compliance-heavy industries where auditing the "who, what, and when" of policy changes is a legal requirement.

The Mechanics of the -latest Label Migration

The -latest naming convention (including ubuntu-latest, windows-latest, and macos-latest) is designed to keep users on the newest stable OS version without requiring them to manually update their YAML files. However, the nature of this pointer means that the underlying environment is mutable.

GitHub follows a strict deprecation guideline where only the two most recent versions of an operating system are supported. When a new OS version reaches a stability threshold, it is promoted to the -latest label through a gradual rollout process typically spanning one to two months. This gradual approach is intended to mitigate the risk of widespread failure, allowing users to detect issues in a subset of their runs before the entire workload is migrated.

To avoid the unpredictability of the windows-latest label, GitHub recommends the use of version-specific labels. For those who require absolute stability and wish to bypass the migration to Windows Server 2025, the specific label windows-2022 should be used in the YAML configuration.

Windows Server 2025 and Visual Studio 2026 Integration

As of February 5, 2026, GitHub introduced a specialized beta image: Windows Server 2025 with Visual Studio 2026. This image is accessible via the specific label windows-2025-vs2026. This release is intended to provide a cutting-edge environment for developers who need the latest IDE capabilities before they are fully stabilized for the general windows-latest population.

Because this image is currently in "beta," it comes with specific caveats. Software stability may be inconsistent, and users may experience increased queuing times as GitHub balances the capacity for this specific image across its infrastructure. The primary goal of this beta phase is to collect telemetry and user feedback to identify and resolve bugs before the image reaches General Availability.

The software differences between the standard Windows Server 2025 image and the Visual Studio 2026 variant are detailed in the following table:

Tool Name	Windows Server 2025	Windows Server 2025 with VS 2026	Notes
Visual Studio	Visual Studio 2022 (version 17.14.*)	Visual Studio 2026 (version 18.2.*)	Updated to the recent version
Visual Studio components	Present	Removed	Unavailable in VS 2026

Network Infrastructure and Firewall Configuration

For organizations running GitHub-hosted runners within restricted network environments, maintaining a comprehensive list of allowed domains is essential. Because GitHub uses various CNAME records and dynamic endpoints, firewalls must be configured to allow traffic to specific domains to ensure the runner can communicate with the GitHub orchestrator.

The following domains are categorized by their operational necessity:

Essential Operations
- github.com
- api.github.com
- *.actions.githubusercontent.com

Downloading Actions
- codeload.github.com

Job Summaries, Logs, Artifacts, and Caches
- results-receiver.actions.githubusercontent.com
- *.blob.core.windows.net

Runner Version Updates
- objects.githubusercontent.com
- objects-origin.githubusercontent.com
- github-releases.githubusercontent.com
- github-registry-files.githubusercontent.com

OIDC Token Retrieval
- *.actions.githubusercontent.com

GitHub Packages and Containers
- *.pkg.github.com
- pkg-containers.githubusercontent.com
- ghcr.io

Git Large File Storage (LFS)
- github-cloud.githubusercontent.com
- github-cloud.s3.amazonaws.com

Dependabot Updates
- dependabot-actions.githubapp.com

Release Assets
- release-assets.githubusercontent.com

Virtual Network (VNet) Support
- api.snapcraft.io

It is critical to note that the file paths on these virtual machines are not static. GitHub executes shell commands and actions in specific directories, but these paths can change between image versions, necessitating the use of environment variables rather than hardcoded paths in scripts.

Runner Specifications and Performance

GitHub-hosted runners are predominantly virtual machines (VMs), though there is a distinction regarding resource allocation. Most runners are isolated VMs, but single-CPU runners are hosted as containers on a shared VM. This distinction is important for performance tuning and security isolation.

For Linux-based runners, GitHub provides specialized hardware acceleration for Android SDK tools. This optimization significantly reduces the time required to run Android tests and lowers the overall consumption of GitHub Actions minutes.

Regarding image stability and support, GitHub provides a clear hierarchy of image types:

GA Images: Fully supported and covered by the standard Service Level Agreement (SLA).
Beta Images: Provided "as-is" with all faults. These are excluded from the SLA and may not be covered by standard customer support.
Deprecated Images: Older versions that are maintained for a short window before being completely removed from the platform.

Strategic Implementation for Workflow Stability

To maintain a resilient CI/CD pipeline during the transition to Windows Server 2025, developers should adopt a multi-stage verification strategy.

First, identify the current environment by logging the OS version in the workflow. This can be done using a simple shell command to verify if the runner is currently operating on Windows Server 2022 or 2025.

Second, if the workflow relies on specific legacy tools that were removed to save disk space in the 2025 image, the YAML should be updated from runs-on: windows-latest to runs-on: windows-2022. This freezes the environment and prevents the automatic migration.

Third, for those moving to the new image, the implementation of the following syntax allows for the testing of the newest beta environments:

yaml jobs: jobName: runs-on: windows-2025-vs2026

Finally, users are encouraged to monitor the runner-images repository. GitHub creates a "pre-release" when the deployment of a new image begins and converts it to a full "release" once the deployment is finished. Subscribing to these releases provides the most accurate timeline for when specific images will become the default.

GitHub Desktop Integration

While GitHub Actions handles the automation side, the development workflow is complemented by GitHub Desktop. This tool is designed to abstract the complexities of Git, making it accessible for both novice and experienced users. The software is distributed for various architectures to ensure optimal performance on the host machine.

Available versions include:
- Download for Apple silicon (ARM)
- Download for Intel chip (x86)
- Download for Windows (64bit)

The desktop application also offers a beta channel, allowing users to experience new features and bug fixes before they are integrated into the stable release.

Final Technical Analysis

The transition of windows-latest to Windows Server 2025 represents more than just an OS update; it is a synchronization of the GitHub ecosystem with the latest enterprise server capabilities. The move from Server 2022 to 2025, combined with the introduction of Visual Studio 2026 in beta, ensures that the CI/CD pipeline remains compatible with the latest software development kits (SDKs).

The primary risk associated with this migration is the "silent failure" where a workflow continues to run but behaves differently due to the removal of specific packages or the update of the Visual Studio toolchain. The removal of certain components in the windows-2025-vs2026 image compared to the standard 2025 image highlights a shift toward a more streamlined, focused toolset to maximize disk efficiency.

From an operational standpoint, the introduction of REST APIs for settings management is a significant leap forward. By moving the control of fork pull request approvals and artifact retention from the GUI to the API, GitHub is enabling a "Policy as Code" model. This reduces the risk of human error and allows for the rapid scaling of organization-wide security policies.

Ultimately, the strategy for any technical team should be to move away from the -latest labels for critical production pipelines. By explicitly defining the runner version (e.g., windows-2022), teams gain total control over their environment, ensuring that a platform update in September 2025 does not result in unplanned downtime or build regressions.