GitHub Pages’ legacy pagesworker architecture was shut down on June 30, 2024. In August 2022, GitHub Actions became the default method to build and deploy Pages sites. Branch deployment remains available, but now requires GitHub Actions unless a .nojekyll file is used.

To build a Pages site from a branch with Jekyll, you must enable GitHub Actions in the repository settings. Alternatively, if GitHub Actions is unavailable or disabled, adding a .nojekyll file to the root of your source branch will bypass the Jekyll build process and deploy the content directly. In this case, you would need to build the site yourself and push the static assets to your source branch.

Learn more about GitHub Pages

Custom GitHub Actions Workflows for GitHub Pages is now generally available! Experience enhanced flexibility and control over your deployment process today. Learn more

Resources:

• Learn about Pages
• Learn how to configure a custom workflow
• Browse our starter workflows

To ensure the security of our infrastructure, on Tuesday, February 28th, 2023 GitHub Pages sites that contain symbolic links will no longer build outside of GitHub Actions.

The majority of Pages sites will not be affected by this change since building with GitHub Actions is the default. If any of your Pages sites is affected, you will receive a build failure email with instructions how to fix the error on your next build.

Today we are deprecating the theme picker we introduced in 2012 for GitHub Pages.

While this experience allowed users to preview a theme in the user interface, we are doing this to increase the security of github.com.

You can of course continue to use any Jekyll theme you want with Pages, and publish beautiful sites with a small configuration change.

You can now deploy to a GitHub Pages site directly from a repository using GitHub Actions, without needing to set up a publishing source. Using Actions to orchestrate Pages publishing provides many more options for choosing your authoring framework (Next.js, Hugo, Gatsby, Jekyll, NuxtJS or other technologies, and the associated versions thereof) as well as giving you finer control over the publishing process, such as leveraging deployment gates.

We have written several starter workflows for the most common frameworks but also have a “Static“ option if you want to deploy the contents of your repository with no build step.

Resources:

• Learn about Pages
• Learn how to configure a custom workflow
• Browse our starter workflows

Today you will begin to see a new workflow running called pages build and deployment in your public GitHub Pages repositories. This workflow is automatically triggered when you push to the branch configured for GitHub Pages in your repository. As the name suggests, it builds and deploys your pages site. The initial benefit of this change is enabling you to see your build logs and any errors that may occur which has been a long standing issue for Pages users. However, in the future this will enable us to give you the ability to fully customize your pages build and deployment workflow to use any static site generator you want without having to push the build output to a special branch of the repository.

You may notice this workflow uses some new actions actions/pages-deploy, and actions/jekyll-build-pages. For now these actions are designed to be used in the generated workflow, however, starting early next year we will introduce some additional changes that will enable you to take advantage of them.

Learn more about GitHub Pages

Users and organizations can now verify GitHub Pages domains to protect against takeover attacks.

Learn more about verifying your custom domain for GitHub Pages

For questions, visit the GitHub Pages community

All GitHub Pages sites served from the github.io domain will now have a Permissions-Policy: interest-cohort=() header set.

Pages sites using a custom domain will not be impacted.

Learn more about GitHub Pages

For questions, visit the GitHub Pages community

When configuring a custom domain for your GitHub Pages site, we will now automatically request a certificate for both the Apex and www subdomain of that custom domain if DNS is configured appropriately. As part of this, we've also moved the GitHub Pages settings to their own dedicated tab and refreshed the setup flow to help you get everything set up with ease.

If you don't want to use both domains with GitHub Pages, we'll continue requesting a certificate for only the specific domain you configure. Custom domains that use a subdomain other than www are not affected by this change.

Learn more about custom domains in GitHub Pages.

Beginning April 15, 2021, we will stop redirecting GitHub Pages sites from *.github.com to the *.github.io domain.

Today, we serve all GitHub Pages sites from the *.github.io domain, but before 2013 we used the *.github.com domain. On April 5, 2013, we deprecated the *.github.com domain for the Pages sites and started redirecting all traffic to the new location. After April 15, 2021, we will stop doing this redirection. We are taking this action to further protect github.com overall.

How does this affect me?

If you’ve configured a custom domain for your Pages site or you directly access your site on *.github.io, you will not be affected by this change. If, however, your site still receives traffic through a redirect from *.github.com, after April 15, 2021 that URL will stop working.

To ensure all affected customers are aware of this change, during two scheduled brownouts, we will temporarily suspend redirection of Pages sites from *.github.com. The brownouts are scheduled for the following dates and times:

• April 1st, 2021 5:00pm UTC – 8:00pm UTC

• April 8th, 2021 5:00pm UTC – 8:00pm UTC

What actions should I take?

We strongly recommend that you remove any external references to *.github.com to avoid any traffic loss to your Pages sites. Additionally, we recommend that you should review your site's dependencies to check for resources that may have been hosted on Pages sites that expected a *.github.com URL. In most cases, simply updating those dependencies to use *.github.io will ensure they continue to work after April 15th.

Please contact support if you experience any issues due to these changes.

GitHub Pages now gives you the option to limit access, making the site visible only to users with access to the repository that published the Page. With access control, you can use GitHub Pages to publish and share internal documentation and knowledge across your enterprise.

As part of this release, we are introducing the following capabilities:

• Repo admins can select whether GitHub Pages sites are publicly visible or limited to users who have access to the repository.
• Both private and internal repositories support private visibility. With an internal repository, everyone in your enterprise will be able to view the Page with the same credentials they use to login to github.com
• Org admins can configure the visibility options that members will be able to select for their Page. For example, you can enforce that your members can only publish content privately.

This feature is generally available today on GitHub Enterprise Cloud. To enable access control on Pages, navigate to your repository settings, and click the dropdown menu to toggle between public and private visibility for your site.

For questions, visit the GitHub pages community

Organization owners can now disable publication of GitHub Pages sites from repositories in the organization. Disabling GitHub Pages for the organization will prevent members from creating new Pages sites but will not unpublish existing sites.

You can learn more about this new setting in our documentation.

Repositories that use GitHub Pages can now build and deploy from any branch. Publishing to the special gh-pages branch will still work the same as it always has, but you can now choose a different branch in your repository as the publishing source. This functionality also removes the hardcoded dependency on user and organization pages having a master branch.