Automatically deploy your project to GitHub Pages with GitHub Actions. This action can be configured to push your production-ready code into any branch you'd like, including gh-pages and docs. It can also handle cross repository deployments and works with GitHub Enterprise too.

Maintenance of this project is made possible by all the contributors and sponsors. If you'd like to sponsor this project and have your avatar or company logo appear below click here. 💖

You can include the action in your workflow to trigger on any event that GitHub actions supports. If the remote branch that you wish to deploy to doesn't already exist the action will create it for you. Your workflow will also need to include the actions/checkout step before this workflow runs in order for the deployment to work. If you intend to make multiple deployments in quick succession you may need to leverage the concurrency parameter in your workflow to prevent overlaps.

You can view an example of this below.

name: Build and Deploy
on: [push]
permissions:
  contents: write
jobs:
  build-and-deploy:
    concurrency: ci-${{ github.ref }} # Recommended if you intend to make multiple deployments in quick succession.
    runs-on: ubuntu-latest
    steps:
      - name: Checkout 🛎️
        uses: actions/checkout@v3

      - name: Install and Build 🔧 # This example project is built using npm and outputs the result to the 'build' folder. Replace with the commands required to build your project, or remove this step entirely if your site is pre-built.
        run: |
          npm ci
          npm run build

      - name: Deploy 🚀
        uses: JamesIves/github-pages-deploy-action@v4
        with:
          folder: build # The folder the action should deploy.

If you'd like to make it so the workflow only triggers on push events to specific branches then you can modify the on section.

on:
  push:
    branches:
      - main

It's recommended that you use Dependabot to keep your workflow up-to-date and secure. You can find the latest tagged version on the GitHub Marketplace or on the releases page.

If you do not supply the action with an access token or an SSH key, you must access your repositories settings and provide Read and Write Permissions to the provided GITHUB_TOKEN, otherwise you'll potentailly run into permission issues. Alternatively you can set the following in your workflow file to grant the action the permissions it needs.

permissions:
  contents: write

If you'd like to use the functionality provided by this action in your own action you can either create a composite action, or you can install it using yarn or npm by running the following commands. It's available on both the npm and GitHub registry.

yarn add @jamesives/github-pages-deploy-action

npm install @jamesives/github-pages-deploy-action

It can then be imported into your project like so.

import run from '@jamesives/github-pages-deploy-action'

Calling the functions directly will require you to pass in an object containing the variables found in the configuration section, you'll also need to provide a workspace with a path to your project.

import run from '@jamesives/github-pages-deploy-action'

run({
  token: process.env['ACCESS_TOKEN'],
  folder: 'build',
  repositoryName: 'JamesIves/github-pages-deploy-action',
  silent: true,
  workspace: 'src/project/location',
  tag: 'v0.1'
})

For more information regarding the action interface please click here.

The with portion of the workflow must be configured before the action will work. You can add these in the with section found in the examples above. Any secrets must be referenced using the bracket syntax and stored in the GitHub repository's Settings/Secrets menu. You can learn more about setting environment variables with GitHub actions here.

The following options must be configured in order to make a deployment.

By default, the action does not need any token configuration and uses the provided repository scoped GitHub token to make the deployment. If you require more customization you can modify the deployment type using the following options.

With the action correctly configured you should see the workflow trigger the deployment under the configured conditions.

The action will export an environment variable called deployment_status that you can use in your workflow to determine if the deployment was successful or not. You can find an explanation of each status type below.

This value is also set as a step output as deployment-status.

If you'd prefer to use an SSH deploy key as opposed to a token you must first generate a new SSH key by running the following terminal command, replacing the email with one connected to your GitHub account.

ssh-keygen -t rsa -m pem -b 4096 -C "youremailhere@example.com" -N ""

Once you've generated the key pair you must add the contents of the public key within your repository's deploy keys menu. You can find this option by going to Settings > Deploy Keys, you can name the public key whatever you want, but you do need to give it write access. Afterwards, add the contents of the private key to the Settings > Secrets menu as DEPLOY_KEY.

With this configured, you can then set the ssh-key part of the action to your private key stored as a secret.

- name: Deploy 🚀
  uses: JamesIves/github-pages-deploy-action@v4
  with:
    folder: site
    ssh-key: ${{ secrets.DEPLOY_KEY }}

name: Build and Deploy
on:
  push:
    branches:
      - main
jobs:
  deploy:
    concurrency: ci-${{ github.ref }}
    runs-on: ubuntu-latest
    steps:
      - name: Checkout 🛎️
        uses: actions/checkout@v3

      - name: Install and Build 🔧 # This example project is built using npm and outputs the result to the 'build' folder. Replace with the commands required to build your project, or remove this step entirely if your site is pre-built.
        run: |
          npm ci
          npm run build

      - name: Deploy 🚀
        uses: JamesIves/github-pages-deploy-action@v4
        with:
          folder: build
          clean: true
          clean-exclude: |
            special-file.txt
            some/*.txt
          ssh-key: ${{ secrets.DEPLOY_KEY }}

Alternatively, if you've already configured the SSH client within a previous step you can set the ssh-key option to true to allow it to deploy using an existing SSH client. Instead of adjusting the client configuration, it will simply switch to using GitHub's SSH endpoints.

This action is primarily developed using Ubuntu. In your workflow job configuration it's recommended to set the runs-on property to ubuntu-latest.

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest

If you're using an operating system such as Windows you can workaround this using artifacts. In your workflow configuration you can utilize the actions/upload-artifact and actions/download-artifact actions to move your project built on a Windows job to a secondary job that will handle the deployment.

name: Build and Deploy
on: [push]
permissions:
  contents: write
jobs:
  build:
    runs-on: windows-latest # The first job utilizes windows-latest
    steps:
      - name: Checkout 🛎️
        uses: actions/checkout@v3

      - name: Install and Build 🔧 # This example project is built using npm and outputs the result to the 'build' folder. Replace with the commands required to build your project, or remove this step entirely if your site is pre-built.
        run: |
          npm ci
          npm run build

      - name: Upload Artifacts 🔺 # The project is then uploaded as an artifact named 'site'.
        uses: actions/upload-artifact@v1
        with:
          name: site
          path: build

  deploy:
    concurrency: ci-${{ github.ref }}
    needs: [build] # The second job must depend on the first one to complete before running and uses ubuntu-latest instead of windows.
    runs-on: ubuntu-latest
    steps:
      - name: Checkout 🛎️
        uses: actions/checkout@v3

      - name: Download Artifacts 🔻 # The built project is downloaded into the 'site' folder.
        uses: actions/download-artifact@v1
        with:
          name: site

      - name: Deploy 🚀
        uses: JamesIves/github-pages-deploy-action@v4
        with:
          folder: 'site' # The deployment folder should match the name of the artifact. Even though our project builds into the 'build' folder the artifact name of 'site' must be placed here.

If you use a container in your workflow you may need to run an additional step to install rsync as this action depends on it. You can view an example of this below.

- name: Install rsync 📚
  run: |
    apt-get update && apt-get install -y rsync

- name: Deploy 🚀
  uses: JamesIves/github-pages-deploy-action@v4

If you're using a custom domain and require a CNAME file, or if you require the use of a .nojekyll file, you can safely commit these files directly into the deployment branch without them being overridden after each deployment, additionally, you can include these files in your deployment folder to update them. If you need to add additional files to the deployment that should be ignored by the build clean-up steps you can utilize the clean-exclude option.

name: Build and Deploy
permissions:
  contents: write
on:
  push:
    branches:
      - main
jobs:
  deploy:
    concurrency: ci-${{ github.ref }}
    runs-on: ubuntu-latest
    steps:
      - name: Checkout 🛎️
        uses: actions/checkout@v3

      - name: Install and Build 🔧 # This example project is built using npm and outputs the result to the 'build' folder. Replace with the commands required to build your project, or remove this step entirely if your site is pre-built.
        run: |
          npm ci
          npm run build

      - name: Deploy 🚀
        uses: JamesIves/github-pages-deploy-action@v4
        with:
          folder: build
          clean: true
          clean-exclude: |
            special-file.txt
            some/*.txt

If you wish to remove these files you must go into the deployment branch directly to remove them. This is to prevent accidental changes in your deployment script from creating breaking changes.