The ecosystem surrounding GitHub Actions is currently undergoing a significant transition regarding its hosted runner infrastructure. At the center of this evolution is the windows-latest label, a dynamic pointer used in workflow YAML files to ensure that build processes utilize the most current stable version of the Windows operating system provided by GitHub. The migration of this label from Windows Server 2022 to Windows Server 2025 represents more than a simple version bump; it is a systemic update that affects tooling, environment stability, and the programmatic management of runner policies.
For developers and DevOps engineers, the windows-latest label is designed to provide a seamless upgrade path, allowing pipelines to benefit from the latest OS security patches and feature sets without requiring manual updates to every single workflow file. However, this abstraction introduces a period of volatility during the transition phase. When GitHub initiates a migration, workflows utilizing the windows-latest tag experience a gradual shift. This means that for a window of time, different runs of the same workflow may execute on different OS versions, which can lead to intermittent build failures if the new image contains breaking changes or missing dependencies.
The transition to Windows Server 2025 is strategically timed to align with the general availability of the image, which occurred on 2025-04-08. Following a period of monitoring customer feedback to ensure image stability, GitHub has integrated this version into the primary pipeline. This transition is critical for organizations that rely on the latest .NET frameworks, Visual Studio toolsets, and Windows-specific APIs, as the shift to Server 2025 ensures compliance with modern software requirements and maintains the long-term support lifecycle of the hosted environment.
The Windows Server 2025 Migration Timeline
The migration of the windows-latest label is not instantaneous but follows a phased rollout to minimize catastrophic pipeline failures across millions of repositories.
The migration process began on 2025-09-02 and is scheduled to conclude by 2025-09-30. During this specific window, GitHub employs a gradual rollout strategy. This implies that a percentage of workflow runs are routed to the Windows Server 2025 image, while others remain on Windows Server 2022.
The impact of this gradual transition is that a workflow may pass on one run (on Server 2022) and fail on the next (on Server 2025), or vice versa. Once a specific workflow has been migrated to the Windows Server 2025 image, it will not revert to Windows Server 2022 for any future executions. This creates a permanent shift in the execution environment for that specific pipeline.
| Phase | Start Date | End Date | Target OS | Status |
|---|---|---|---|---|
| Pre-Migration | Before 2025-09-02 | 2025-09-01 | Windows Server 2022 | Completed |
| Migration Window | 2025-09-02 | 2025-09-30 | Transition 2022 -> 2025 | Active |
| Post-Migration | 2025-09-30 | Ongoing | Windows Server 2025 | Final State |
Managing Breaking Changes and Tooling Differentials
The transition to Windows Server 2025 is accompanied by specific breaking changes that can disrupt build stability. GitHub has explicitly stated that the Windows Server 2025 image may feature a different set of pre-installed tools compared to its predecessor.
A critical aspect of this migration is the reduction of the package list. To maintain the Service Level Agreement (SLA) regarding free disk space on hosted runners, GitHub has removed certain packages from the Windows Server 2025 image. If a workflow relies on a tool that was present in Server 2022 but removed in 2025, the job will fail during the execution phase.
To mitigate these risks, users are encouraged to take the following actions:
- Review the specific list of removed packages in the
runner-imagesrepository to identify dependencies. - Proactively update workflow YAML files to install missing tools manually using a package manager.
- Test workflows against the new image before the
windows-latestlabel fully migrates.
Visual Studio 2026 Integration and Preview Paths
Parallel to the OS migration, GitHub is introducing updates to the development toolchain, specifically regarding Visual Studio. A new Windows runner image featuring Visual Studio 2026 has been released in public preview.
This preview image is designed to run alongside the standard windows-2025 image, creating a "safe validation path." This allows engineers to validate their code against the next generation of Visual Studio without risking the stability of their primary production pipelines.
The integration timeline for Visual Studio 2026 is as follows:
- Public Preview: Available now via a specific label.
- General Availability: Scheduled for 2026-05-04.
Upon reaching general availability on May 4, 2026, Visual Studio 2026 will be integrated directly into the windows-2025 image. Until that date, users who wish to utilize Visual Studio 2026 must explicitly modify their workflow configuration.
To implement this, the runs-on target in the YAML workflow file must be updated to:
yaml
runs-on: windows-2025-vs2026
This granular control allows teams to maintain fallback options, such as windows-2022, while simultaneously planning the migration to the latest tooling.
Strategic Use of OS Version Labels
To avoid the inherent unpredictability of the -latest labels, GitHub provides specific versioned labels. The -latest labels (e.g., ubuntu-latest, windows-latest, macos-latest) always point to the newest stable OS version. However, because the migration process takes 1-2 months, relying on -latest can introduce non-deterministic behavior into a CI/CD pipeline.
To ensure absolute consistency and avoid unwanted migrations, users should specify the exact version of the OS.
- Use
windows-2022to lock the environment to Windows Server 2022. - Use
windows-2025(or the specific preview labels) to target the new environment.
GitHub follows a strict deprecation policy where only the latest two versions of an OS are supported. Once a version is deprecated, it is removed from the hosted runner pool, necessitating a migration to a newer version.
Programmatic Policy Management via New REST APIs
As of July 31, 2025, GitHub has expanded the capabilities of Actions by launching new REST APIs for managing settings. This allows organizations to move away from manual UI-based configuration and toward "Infrastructure as Code" (IaC) for their CI/CD governance.
These APIs are available at the enterprise, organization, and repository levels, enabling the programmatic creation, modification, and auditing of policies. The specific settings now accessible via these endpoints include:
- Approval for running fork pull request workflows from contributors.
- Allowing workflows on fork pull requests specifically within private repositories.
- Defining which repositories possess the authorization to create repository-level self-hosted runners.
- Configuring the retention periods for artifacts and logs.
The impact of this update is a significant reduction in manual review overhead. Security teams can now write scripts to audit and enforce policies across thousands of repositories simultaneously, ensuring that security controls are consistent across the entire organization.
Advanced Runner Orchestration: The Scale Set Client
In February 2026, GitHub introduced the GitHub Actions runner scale set client in public preview. This is a transformative shift in how runners are managed, especially for those who require high-performance or specialized hardware without the overhead of Kubernetes.
The client is a standalone Go-based module. It allows users to build custom autoscaling solutions by integrating directly with GitHub's scale set APIs. While GitHub handles the orchestration logic, the actual provisioning of the runner—whether it is a container, a virtual machine, or a bare metal server—is managed by the user.
The key capabilities of the scale set client include:
- Platform agnostic design: The client functions across Windows, Linux, and macOS environments.
- Full provisioning control: Users define the exact logic for when runners are created, scaled up, or destroyed.
- Native multi-label support: Users can assign multiple labels to a single scale set, allowing the same pool of runners to handle different build types efficiently.
- Agentic scenario support: The infrastructure is optimized for agentic workflows, including those utilizing the GitHub Copilot coding agent.
- Real-time telemetry: Built-in metrics allow for the monitoring of job execution and performance.
This architecture allows for the deployment of runners on any infrastructure, providing the flexibility of self-hosted runners with the orchestration benefits of GitHub-hosted runners.
Security Enhancements and Action Allowlisting
Security controls have been expanded to all GitHub plans. Action allowlisting is now available for Free, Team, and Enterprise customers. This feature is critical for maintaining the "principle of least privilege" within a software supply chain.
Allowlisting allows administrators to define a strict set of actions and reusable workflows that are permitted to run within their repositories. This protects the environment against:
- Potentially compromised third-party actions.
- Unverified workflows that may attempt to exfiltrate secrets.
- Inconsistent policy application across different teams.
By implementing allowlists, organizations can ensure that only audited and approved code is executed within their CI/CD pipelines.
Network Configuration for Hosted Runners
For organizations using virtual networks (VNet) or strict firewalls, specific network rules must be configured to allow GitHub Actions to function. The following domains are required for essential operations:
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
VNet Specifics:
- api.snapcraft.io
It is important to note that CNAME records may change over time; therefore, firewall rules should be applied recursively to the listed domains to ensure uninterrupted service.
General Capabilities of GitHub Actions
GitHub Actions provides a robust framework for automating the entire software lifecycle, from the initial idea to production deployment.
The system supports a wide array of operating systems and architectures, including:
- Linux
- macOS
- Windows
- ARM
- GPU-enabled runners
- Custom containers
The platform is language-agnostic, providing native support for:
- Node.js
- Python
- Java
- Ruby
- PHP
- Go
- Rust
- .NET
To optimize development time, GitHub Actions utilizes matrix builds. This allows developers to simultaneously test their code across multiple operating systems and runtime versions, ensuring compatibility across a diverse set of environments. Additionally, the integration of GitHub Packages simplifies the management of dependencies, utilizing the GITHUB_TOKEN for fast distribution via a global CDN.
Conclusion: Analysis of the Windows Server 2025 Transition
The migration of windows-latest to Windows Server 2025 is a calculated move by GitHub to modernize the build environment while balancing the need for stability and storage efficiency. The transition window (September 2025 to September 2025) highlights the tension between the convenience of "latest" labels and the necessity of deterministic builds. The gradual rollout is a risk-mitigation strategy, but it places the burden of validation on the user.
The introduction of the windows-2025-vs2026 preview label is an essential bridge, acknowledging that OS updates often coincide with toolchain updates (like Visual Studio 2026). By decoupling the OS migration from the toolchain migration, GitHub allows developers to isolate failures: if a build fails on windows-2025 but passes on windows-2022, the issue is OS-related; if it fails on windows-2025-vs2026, it is likely a toolchain compatibility issue.
Furthermore, the launch of the Go-based runner scale set client signals a move toward more flexible, decentralized infrastructure. By removing the strict dependency on Kubernetes for autoscaling, GitHub is enabling a broader range of enterprise environments to implement high-performance, scalable CI/CD pipelines. When combined with the new REST APIs for policy management and the universal availability of action allowlisting, the overall trajectory of GitHub Actions is toward greater programmatic control, enhanced security, and more predictable infrastructure management.