All GitHub Pages builds now run on Actions

GitHub announced that every GitHub Pages site — more than 16 million of them — is now built and deployed with GitHub Actions, ahead of the platform’s 15th anniversary. The move retires the long-standing single-purpose pagesworker build system and brings Pages in line with the rest of GitHub’s CI/CD tooling.

The earlier system had a key limitation: because the worker did not support versioning, GitHub was locked to an older Jekyll release and could not add plugins without risking breakage for existing sites. That constraint also made it impractical to support the growing ecosystem of static site generators that users wanted to publish through Pages. With builds now running as Actions workflows, Pages can accommodate any framework present today or released in the future.

Public repository Pages sites have been built this way since December 2021. After observing more than seven million builds per month for over six months, GitHub is extending the same infrastructure to private and internal repositories.

What the Actions pipeline changes

Moving builds to Actions turns Pages deployments into standard GitHub deployments, and brings workflow features that were previously unavailable to Pages users:

  • Environment protection rules now gate deployments. A deployment must occur within an environment — github-pages by default — and rules can require approvals before a site is published.
  • Build-time secrets can be injected into the workflow, so site generation can use credentials or API keys without committing them.
  • Build checks can be added so that bad commits are blocked before they reach the live site.

The security model has shifted accordingly. Pages was previously scoped to a branch (and optionally a /docs folder), with branch protection rules as the only guardrail. Deployments are now decoupled from source branches — the workflow’s triggers decide when a deployment happens — so environment protection rules replace branch protection as the primary mechanism for controlling what gets published.

GitHub also noted that private repositories on Team and Pro plans now have access to Actions environments, deployment branches, and environment secrets. Previously those capabilities were limited to Enterprise plans for private repositories.

Migration and configuration notes

For existing sites, the switch is transparent — no manual action is required, just as with the earlier rollout to public repositories. Builds and deployments of private and internal Pages sites consume Actions minutes the same as any workflow; public repositories continue to get unlimited Actions minutes. All accounts include an allowance of Actions minutes for private repositories.

Users who want to move beyond the default setup can opt in to a custom workflow by changing the Pages source from “branch” to “GitHub Actions.” This is required to run Jekyll 4+ or to take advantage of the full Actions feature set. GitHub published a Jekyll starter workflow that expects a Gemfile and optionally a config file, plus starter workflows for other popular static site generators.