Deploying Your Static Websites to AWS in Style Using Github Actions
Tags: aws, devops, git, webdev
Published: 2019-12-10 00:33:49

---
title: Deploying Your Static Websites to AWS in Style Using Github Actions
published: true
description: 
tags: #aws #devops #git #webdev
canonical_url: https://blog.kylegalbraith.com/2019/12/09/deploying-your-static-websites-to-aws-in-style-using-github-actions/
cover_image: https://blog.kylegalbraith.com/static/df163ab7a4df3bc0379ec37ffb98b4bd/e7401/deploying-your-static-website-to-aws-in-style-using-github-actions.webp
---
GitHub Actions is gaining popularity for its simplicity and for the fact that a ton of repositories live in GitHub already. With the general availability of Actions, it's now easy to incorporate your CI/CD practices into your repository. Before we use to have to use third-party tools like Travis CI, CircleCI, or other CI/CD providers. But with GitHub Actions, we can keep all our CI/CD processes next to our repository with one simple `yaml` file.

In this post, we are going to quickly explore how we can continuously deploy our static websites to AWS S3 using GitHub Actions. This post assumes that you are hosting a static website out of AWS S3 and that you have a Git repository for that site living at GitHub. If you don't currently have a static website hosted on AWS S3, consider checking out this [post to get you started](https://medium.com/@kyle.galbraith/how-to-host-a-website-on-s3-without-getting-lost-in-the-sea-e2b82aa6cd38) or check out my [Learn AWS By Using It course](https://www.kylegalbraith.com/learn-aws) for a deeper dive.

If you have those two pre-requisites taken care of, let's dive into setting up a CI/CD workflow for our GitHub repository.

### AWS Setup Steps
Before we can create our workflow we need to set up a user in our AWS account that will be allowed to deploy our static website to our S3 bucket. To do that, we first need to login to our AWS account and navigate to the IAM console. 

![IAM Console](https://thepracticaldev.s3.amazonaws.com/i/5wgnmg6aff5mst94tgas.png)

Once there we need to create a new user that will have programmatic access to our AWS account. We want to restrict this user to only have S3 access to our account, so we will select the `AmazonS3FullAccess` permission policy. See the GIF below for the step by step guide.

![Create user](https://thepracticaldev.s3.amazonaws.com/i/pyyrilrl8eaep8qzchqw.gif)

On the last page after creating our new user we see the programmatic access keys for them, the `access_key` and `secret_access_key`. Copy those to a file somewhere as we are going to add them to GitHub next.

### Setting up our GitHub Action Secrets
To deploy to our AWS S3 bucket from our GitHub Action we first need to configure two new secrets in our repository. These secrets are for our `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY`.

Navigate to the `Settings` section of your GitHub repository and locate the `Secrets` section on the left-hand side. Once there we are going to add a new secret for `AWS_ACCESS_KEY_ID` and paste in the `access_key` we got in our IAM step. Then we are going to add another secret for `AWS_SECRET_ACCESS_KEY` and paste in our `secret_access_key`. In the end, we should have two new secrets in our GitHub repository.

![GitHub Secrets](https://thepracticaldev.s3.amazonaws.com/i/pzntyellko7h27ukdc5b.png)

We have our GitHub Secrets configured and our IAM user has access to upload content to our S3 bucket. Now we can configure our Actions to continuously deploy to our bucket on Git pushes.

### Setting up Continous Deployment via GitHub Actions
GitHub Actions uses a concept of a `workflow` to determine what jobs and steps within those jobs to run. To set this up we are first going to create a new directory in our repository that GitHub Actions will watch to know which steps to execute.

From the root of your repository run the following commands:

```bash
$ mkdir .github/workflows/
$ touch .github/workflows/main.yml
```

Inside of our `main.yml` file we are going to add the following:

```yaml
name: CI
on: [push]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v1
    - name: Configure AWS Credentials
      uses: aws-actions/configure-aws-credentials@v1
      with:
        aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
        aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        aws-region: us-west-2
    - name: Build static site
    - run: yarn install && npm run-script build
    - name: Deploy static site to S3 bucket
      run: aws s3 sync ./dist/ s3://<your-website-bucket> --delete
```

Here we see three steps defined in our `build` job. The first one is an AWS provided action that takes our secrets that we configured and sets up our AWS CLI credentials using them. Then depending on how your static website gets built and configured, you want to build the site before uploading it to S3. Our final step is then running `aws s3 sync` via the AWS CLI to sync our `dist` folder to our S3 bucket. We use the `--delete` flag in the CLI call to delete any files that are in the S3 bucket but not in our `dist` folder.

Now if we commit this new workflow file we should then be able to see in the `Actions` section of our GitHub repository that the job runs to completion.

![GitHub Actions Output](https://thepracticaldev.s3.amazonaws.com/i/0huz4ocgczi4fihsqczh.png)

💥🙏 We now have continuous deployment configured for our static website repository living on GitHub but deploying to our S3 bucket.

### Conclusion
There are dozens of different ways to continuously deploy our applications and websites nowadays. We have shown but one way of doing it in this post using GitHub Actions and deploying to AWS S3. But that is only one pair of options and there are many more out there like it.

My hope is that in this post you have seen how easy it can be to set up a new GitHub action. This makes setting up a simple continuous deployment setup like this one a breeze. On top of that, if you already host your static site on AWS, it's one small step to push your site to S3 from a GitHub action.

### Want to check out my other projects?
I am a huge fan of the DEV community. If you have any questions or want to chat about different ideas relating to refactoring, [reach out on Twitter](https://twitter.com/kylegalbraith) or drop a comment below.

Outside of blogging, I created a [Learn AWS By Using It course](https://kylegalbraith.com/learn-aws/). In the course, we focus on learning Amazon Web Services by actually using it to host, secure, and deliver static websites. It's a simple problem, with many solutions, but it's perfect for ramping up your understanding of AWS. I recently added two new bonus chapters to the course that focus on Infrastructure as Code and Continuous Deployment.

I also curate my own weekly newsletter. The [Learn By Doing newsletter](https://kylegalbraith.com/learn-by-doing/) is packed full of awesome cloud, coding, and DevOps articles each week. Sign up to get it in your inbox.