Continuously Deploying Next.js Website to DigitalOcean Using GitHub Actions

Updated on June 4, 2023 · 7 min read|

If you've deployed a Next.js website to Vercel before, you'll understand the allure of its simplicity. Just push your changes to the deployment branch, and within minutes, your updates are live. As developers, we're well aware that deployment can often be a drawn-out and tedious process, making the appeal of continuous deployment, with its significant enhancement to developer experience, undeniable.

While deploying a Next.js website to Vercel is straightforward, it might not suit everyone. Factors such as personal preferences, cost considerations, or a need for flexibility can make alternative hosting platforms more attractive. However, regardless of your chosen platform, maintaining the same level of developer experience by automating website deployment remains essential.

In this guide, we'll explore how to establish a continuous deployment pipeline for a Next.js website on DigitalOcean, utilizing GitHub Actions to create a workflow. This workflow will automatically deploy code changes to a remote DigitalOcean server every time we push to the main branch. While the steps outlined are universally applicable to any remote server, our focus will be on DigitalOcean, as this site is hosted there.

To streamline the process, we won't employ Docker. Instead, we'll leverage the Rsync package to transfer files to the server. By the end of this guide, you'll gain a comprehensive understanding of how to automate your deployment workflow and set up continuous deployment of a Next.js website to DigitalOcean using GitHub Actions.

Here are a few of the options for hosting your website (affiliate links):

DigitalOcean - simple and scalable droplets which provide a lot of flexibility.
Cloudways - Cloudways is a managed alternative to DigitalOcean.
Namecheap - not only a domain marketplace, but also a hosting service for various needs.

Setting up an SSH key

Our first task involves generating an SSH key on the server, which GitHub Actions will utilize to establish a connection and transfer files during deployment. To create the SSH key, we'll SSH into the server and navigate to the ~/.ssh directory - the conventional storage location for SSH keys.

If this directory is not present, you'll need to create it. However, remember to avoid logging in as a root user, as this presents a significant security risk.

bash
ssh username@host

bash
ssh username@host

bash
cd ~/.ssh

bash
cd ~/.ssh

Now that we are in the correct directory, let's generate the SSH key using the built-in ssh-keygen command.

bash
ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

bash
ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

This should start the generation of a new key and will ask for its location.

bash
Generating public/private rsa key pair.
Enter file in which to save the key (/Users/YOUR_USER/.ssh/id_rsa):

bash
Generating public/private rsa key pair.
Enter file in which to save the key (/Users/YOUR_USER/.ssh/id_rsa):

For ease of recognition, we'll rename the key to gh_actions. During the process, the prompt might ask for a key passphrase, which can be left blank. For more details about SSH key passphrases, refer to the GitHub Actions documentation.

If the process is successful, you'll see confirmation messages in the terminal.

bash
Your identification has been saved in gh_actions
Your public key has been saved in gh_actions.pub

bash
Your identification has been saved in gh_actions
Your public key has been saved in gh_actions.pub

After this, we will copy the generated public key to the authorized_keys file in the .ssh folder.

bash
cat gh_actions.pub >> ~/.ssh/authorized_keys

bash
cat gh_actions.pub >> ~/.ssh/authorized_keys

With the newly generated key in place, it's now possible to log into the server.

The final step involves copying the generated private key to the clipboard. This will be essential when establishing the secrets for GitHub Actions.

bash
cat ~/.ssh/gh_actions

bash
cat ~/.ssh/gh_actions

The above command prints the private key to the terminal, enabling you to copy it to your clipboard.

Setting up secrets to enable GitHub Actions deployment

In order to allow GitHub Actions to establish a connection with our server without revealing sensitive information, we'll house this data in GitHub Actions secrets. Follow these steps to set them up:

Navigate to your GitHub repository and select the Settings tab.
Locate the Secrets and actions dropdown and click to expand it.
Click on the Actions tab, which takes you to the Actions secrets and variables page.
Towards the top left, find and click on the New repository secret button to initiate the creation of new secrets.

You'll need to create the following secrets:

SSH_KEY: The private SSH key we copied earlier.
HOST: The domain name or IP address of the deployment server.
USERNAME: The user for whom the SSH key was created.
TARGET_DIRECTORY: The destination for the deployed code. For DigitalOcean, this typically is /var/www/yoursitename.

After creating these secrets, we'll have gathered all the necessary information to establish the deployment workflow.

Establishing the GitHub Actions workflow

The centerpiece of the deployment process is the GitHub Actions Workflows. These automated procedures execute one or more jobs based on the configurations in a YAML file. This file resides in the .github/workflows directory of the respective repository.

To create a workflow for our website, we'll generate a deploy.yml file within the .github/workflows directory of our website's repository. The file will follow a standard YAML structure, starting with the addition of the workflow name and detailing when it should run.

yaml
name: Build and Deploy
 
on:
  push:
    branches:
      - main

yaml
name: Build and Deploy
 
on:
  push:
    branches:
      - main

This will define our workflow, named Build and Deploy, and will trigger it every time we push to the main branch of the repository.

Next, we need to add the actual job. The first step of the job will be to check out our main branch and fetch its history. There are predefined actions that make such tasks easier. In this case, we'll use the actions/checkout@v3 action.

yaml
name: Build and Deploy
 
on:
  push:
    branches:
      - main
jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Main Branch
        uses: actions/checkout@v3
        with:
          fetch-depth: 0
          ref: main

yaml
name: Build and Deploy
 
on:
  push:
    branches:
      - main
jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Main Branch
        uses: actions/checkout@v3
        with:
          fetch-depth: 0
          ref: main

The above configuration will define our workflow, named Build and Deploy, which triggers every time we push to the main branch of the repository.

Following this, we must incorporate the actual job. The initial step involves checking out our main branch and retrieving its history. Thankfully, predefined actions exist to simplify tasks like these. For this purpose, we'll employ the actions/checkout@v3 action.

yaml
name: Build and Deploy
 
on:
  push:
    branches:
      - main
jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Main Branch
        uses: actions/checkout@v3
        with:
          fetch-depth: 0
          ref: main
 
      - name: Use Node.js
        uses: actions/setup-node@v3
        with:
          node-version: "18.x"

yaml
name: Build and Deploy
 
on:
  push:
    branches:
      - main
jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Main Branch
        uses: actions/checkout@v3
        with:
          fetch-depth: 0
          ref: main
 
      - name: Use Node.js
        uses: actions/setup-node@v3
        with:
          node-version: "18.x"

For this tutorial, we'll use Node.js version 18, the latest LTS version available at the time of writing.

With Node set up, we can proceed to install the dependencies and build the Next.js website.

yaml
name: Build and Deploy
 
on:
  push:
    branches:
      - main
jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Main Branch
        uses: actions/checkout@v3
        with:
          fetch-depth: 0
          ref: main
 
      - name: Use Node.js
        uses: actions/setup-node@v3
        with:
          node-version: "18.x"
 
      - name: Install Dependencies
        run: npm install
 
      - name: Build Website
        run: npm run build

yaml
name: Build and Deploy
 
on:
  push:
    branches:
      - main
jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Main Branch
        uses: actions/checkout@v3
        with:
          fetch-depth: 0
          ref: main
 
      - name: Use Node.js
        uses: actions/setup-node@v3
        with:
          node-version: "18.x"
 
      - name: Install Dependencies
        run: npm install
 
      - name: Build Website
        run: npm run build

The workflow stores the output, which is required for pushing to our DigitalOcean server. However, before executing this step, we need to configure the SSH key, enabling the workflow to connect with the server. To aid with this setup, we'll use shimataro/ssh-key-action@v2. Furthermore, we'll also include the remote host in our list of known hosts.

yaml
name: Build and Deploy
 
on:
  push:
    branches:
      - main
jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Main Branch
        uses: actions/checkout@v3
        with:
          fetch-depth: 0
          ref: main
 
      - name: Use Node.js
        uses: actions/setup-node@v3
        with:
          node-version: "18.x"
 
      - name: Install Dependencies
        run: npm install
 
      - name: Build Website
        run: npm run build
 
      - name: Install SSH Key
        uses: shimataro/ssh-key-action@v2
        with:
          key: ${{ secrets.SSH_KEY }}
          known_hosts: "unnecessary"
 
      - name: Adding Known Hosts
        run: ssh-keyscan -H ${{ secrets.HOST }} >> ~/.ssh/known_hosts

yaml
name: Build and Deploy
 
on:
  push:
    branches:
      - main
jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Main Branch
        uses: actions/checkout@v3
        with:
          fetch-depth: 0
          ref: main
 
      - name: Use Node.js
        uses: actions/setup-node@v3
        with:
          node-version: "18.x"
 
      - name: Install Dependencies
        run: npm install
 
      - name: Build Website
        run: npm run build
 
      - name: Install SSH Key
        uses: shimataro/ssh-key-action@v2
        with:
          key: ${{ secrets.SSH_KEY }}
          known_hosts: "unnecessary"
 
      - name: Adding Known Hosts
        run: ssh-keyscan -H ${{ secrets.HOST }} >> ~/.ssh/known_hosts

All the secrets that we have added earlier are stored on the secrets namespace, which we can reference inside the workflow.

Using Rsync for Deployment

Finally, we can push the built files to DigitalOcean using the rsync command.

yaml
name: Build and Deploy
 
on:
  push:
    branches:
      - main
jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Main Branch
        uses: actions/checkout@v3
        with:
          fetch-depth: 0
          ref: main
 
      - name: Use Node.js
        uses: actions/setup-node@v3
        with:
          node-version: "18.x"
 
      - name: Install Dependencies
        run: npm install
 
      - name: Build Website
        run: npm run build
 
      - name: Install SSH Key
        uses: shimataro/ssh-key-action@v2
        with:
          key: ${{ secrets.SSH_KEY }}
          known_hosts: "unnecessary"
 
      - name: Adding Known Hosts
        run: ssh-keyscan -H ${{ secrets.HOST }} >> ~/.ssh/known_hosts
 
      - name: Deploy with rsync
        run: rsync -avz --delete . ${{ secrets.USERNAME }}@${{ secrets.HOST }}:${{ secrets.TARGET_DIRECTORY }}

yaml
name: Build and Deploy
 
on:
  push:
    branches:
      - main
jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Main Branch
        uses: actions/checkout@v3
        with:
          fetch-depth: 0
          ref: main
 
      - name: Use Node.js
        uses: actions/setup-node@v3
        with:
          node-version: "18.x"
 
      - name: Install Dependencies
        run: npm install
 
      - name: Build Website
        run: npm run build
 
      - name: Install SSH Key
        uses: shimataro/ssh-key-action@v2
        with:
          key: ${{ secrets.SSH_KEY }}
          known_hosts: "unnecessary"
 
      - name: Adding Known Hosts
        run: ssh-keyscan -H ${{ secrets.HOST }} >> ~/.ssh/known_hosts
 
      - name: Deploy with rsync
        run: rsync -avz --delete . ${{ secrets.USERNAME }}@${{ secrets.HOST }}:${{ secrets.TARGET_DIRECTORY }}

Rsync is a powerful yet straightforward tool with many options. It operates with efficiency, updating files by transmitting only the differences between the origin and destination files, thereby conserving bandwidth. For deploying our files, we'll use the following options:

a - Activates archive mode, which is shorthand for the -rlptgoD option. A detailed explanation of these options is available.
v - Engages verbose mode, displaying the process progress among other details.
z - Compresses file data during the transfer.
--delete - Removes all files in the destination that aren't found in the source. Without this option, rsync retains the old version of renamed files, resulting in duplicates. This can lead to problems, especially when renaming configuration files. However, this option also deletes server-specific files, such as .env, rendering it unsuitable for certain use cases.

From this point onwards, each push of code to the main branch will trigger the deployment action, building the code and transferring it to our DigitalOcean server. The progress of this action can be tracked within the Actions tab of your repository.

If you want to improve the discoverability of your Next.js website, I have written an article about adding a sitemap to it: Add a Dynamic Sitemap to Next.js Website Using Pages or App Directory

Summary

In conclusion, continuous deployment significantly enhances the deployment workflow for software developers. While deploying a Next.js website to Vercel is relatively straightforward, some developers may opt for alternative hosting platforms. This article delivers a comprehensive, step-by-step guide to automating the deployment workflow for a Next.js website hosted on DigitalOcean using GitHub Actions. By following the guidelines outlined in this article, developers can streamline their deployment process, making it faster, more efficient, and less susceptible to errors.

In this article we covered the generation of an SSH key on the server, the addition of secrets to activate GitHub Actions deployment, and the establishment of a GitHub Actions workflow. This workflow facilitates the deployment of code modifications to a remote server each time changes are committed to the main branch. By following this tutorial, you now have a functioning continuous deployment pipeline, customizable to your specific needs.