GitHub Actions has grown massively since its release in 2018; in 2025 alone, developers used 11.5 billion GitHub Actions minutes in public and open source projects, up 35% year over year from 2024. At the same time, this has not been without its growing pains, and you’ve made clear to us what improvements matter most: faster builds, improved security, better caching, more workflow flexibility, and rock-solid reliability.
Meeting that level of demand first required a deliberate investment in re-architecting the core backend services powering every GitHub Actions job and runner. This was a substantial effort that laid the foundation for the long-term performance, scalability, and feature delivery you’ve been asking for. That new architecture is rolled out, powering 71 million jobs per day and giving us deeper visibility into developer experience across the platform.
With that work behind us, we shift our attention back to your top requests for much needed, long-standing quality-of-life improvements. Below, we’ll walk through what we’ve shipped this year, how you can get started with these upgrades today, and what’s coming in 2026.
Let’s jump in.
Rebuilding the core of GitHub Actions
In early 2024, the GitHub Actions team faced a problem. The platform was running about 23 million jobs per day, but month-over-month growth made one thing clear: our existing architecture couldn’t reliably support our growth curve. In order to increase feature velocity, we first needed to improve reliability and modernize the legacy frameworks that supported GitHub Actions.
The solution? Re-architect the core backend services powering GitHub Actions jobs and runners. Our goals were to improve uptime and resilience against infrastructure issues, improve performance and reduce internal throttles, and leverage GitHub’s broader platform investments and developer experience improvements. We aimed to scale 10x over existing usage. This effort was a big bet and consumed a significant part of our team’s focus. And the work is paying off by helping us handle our current scale, even as we work through the last pieces of stabilizing our new platform.
Since August, all GitHub Actions jobs have run on our new architecture, which handles 71 million jobs per day (over 3x from where we started). Individual enterprises are able to start 7x more jobs per minute than our previous architecture could support.
This was not without its share of pain; it slowed the pace of feature work and delayed progress on long-standing community requests. We knew this would be a tough call, but it was a critical decision to enable our future roadmap and sustainability as a product.
We acknowledge we still have a ways to go, and this is just the beginning of this new chapter of the GitHub Actions story. As we shift our focus back to much-needed improvements, we want to call out some of the most recent ships on this front:
YAML anchors reduce duplication in complex workflows
First up, we shipped support for YAML anchors, one of the most requested features across both the runners and community repositories. YAML anchors reduce repetitive configuration in GitHub Actions workflows by letting you define settings once with an anchor (&) and reference them elsewhere with an alias (*). This allows you to maintain consistent environment variables, step configurations, or entire job setups across your workflows—all defined centrally rather than repeated across multiple jobs.
💡 Read our Docs to learn more about YAML anchors and aliases
Non-public workflow templates for consistent CI across teams
We released non-public workflow templates, a longstanding request from organizations that want consistent, private workflow scaffolding.
Non-public workflow templates let organizations set up common templates for their teams directly in their .github repository, giving developers a reliable starting point when spinning up new workflows. Instead of manually copying CI patterns across repositories, teams can now work from a shared set of patterns.
💡 Read our Docs to learn more about workflow templates
Deeper reusable workflows for modular, large-scale pipelines
We shipped increases to reusable workflow depth (another key request from the community). Reusable workflows let you break your automation into modular, shareable pieces. With the updated limits now supporting 10 levels of nesting and 50 workflow calls per run, teams now have more flexibility to structure their CI/CD pipelines in a way that’s maintainable and scales with their architectural requirements.
💡 Read our Docs to learn more about reusable workflows
Larger caches for bigger projects and dependency-heavy builds
Repositories can now exceed the previous 10GB cache limit, removing a long-standing pain point for teams with large dependencies or multi-language monorepos.
For teams with larger codebases or complex build pipelines, the old 10GB GitHub Actions cache limit often meant build dependencies were evicted before they could speed up your next workflow run, leading to repeated downloads and slower builds. This release was only possible due to our architecture rework and fulfills a request from the community, particularly among some of our largest users.
💡 Read our Docs to learn more about managing cache storage
In early December, we shipped an increase to the number of workflow dispatch inputs from 10 to 25, which also came up in our community discussions. Now developers have more flexibility to build sophisticated self-service workflows, whether teams are parameterizing deployments, configuring test runs, or building reusable automation with richer input options.
💡 Read our docs to learn more about manually running a workflow with workflow_dispatch
We also made progress on the strong foundation laid earlier this year, including arm64-hosted runners for public repositories, macOS 15 and Windows 2025 images (now generally available), Actions Performance Metrics (also generally available), and Custom Image support in public preview.
These releases are designed to improve day-to-day workflow quality and remove long-standing friction.
What’s coming in early 2026
This is just the beginning as there is much we need to do to deliver an even better experience with GitHub Actions. Here’s what we’re planning for the first quarter of 2026, influenced by some of the top requests from our community:
- Support for timezones in scheduled jobs and updates to schedule reliability.
- Return the run ID from workflow dispatch.
- Adding a case function for expressions so they have a conditional operator or function.
- UX improvements, including faster page load times, better rendering for workflows with over 300 jobs, and a filter for the jobs list.
Moreover, we’ll start work on parallel steps, one of the most requested features across GitHub Actions. Our goal is to ship it before mid-2026. Lastly, we are going to raise the bar and start to address some of the asks to lift quality in our open source repositories—we appreciate we need to drive up the quality of our experience here as well.
Help us shape the 2026 roadmap for GitHub Actions
GitHub Actions is one of the most important primitives on GitHub. It powers the builds, tests, deployments, automations, and release processes that define how software ships today.
Our promise to you: 2026 will bring more consistent releases, more transparency, and continued focus on the fundamentals that matter most. We are also increasing funding towards this area to enable us to meet your expectations faster than before.
And this is where we need your help to make sure we’re focusing on the quality-of-life improvements that matter the most. We need your feedback. To support our work:
- Keep voting for your most important items in the community discussions.
- Join us in our new community discussion post, where the GitHub Actions product and engineering leads will be actively discussing with you what comes next.
- Help us drive a plan for next year to make actions the best it can be.
We know GitHub Actions powers how developers build software, and the best version is the one we’ll build together. And as always, you can keep up to date with the GitHub Actions releases through the GitHub Changelog.
Written by
Ben De St Paer-Gotch is currently the director of product at GitHub, where he leads the team behind GitHub Actions, Packages, Codespaces, and npm. Prior to GitHub, he have worked at Docker, Amazon, and Microsoft. Based out of the UK, he's as happy to discuss board games with you as he is to discuss eBPF or whatever technology is currently distracting him.