Auto-deploy with GitHub Webhooks + Content Island

One of the most important steps in a project is deployment. It’s the moment when our project becomes real and accessible to everyone.

If you haven’t deployed your Content Island project to a server yet, I recommend starting with the Automatic deployment with Astro and Content Island using GitHub Actions.

Once your project is deployed, you might want to automate the deployment process every time you make a change in your Content Island project. That is, every time you add a new post, update data, or remove something from visibility, you want your server to redeploy—without having to do it manually.

To achieve this, we’ll use Content Island and GitHub webhooks.

What is a webhook?

A webhook is a way to notify another application that something has happened in ours. That is, when an event occurs in our app, it sends a request to a predefined URL.

GitHub allows two types of webhooks:

Repository webhooks: notify external services when changes occur in a repo, like a push or a pull request.
Workflow webhooks: trigger a GitHub Actions workflow when an external service sends a request to a URL.

In our case, we’ll use the second option—we’ll trigger a GitHub Actions workflow to redeploy our project to GitHub Pages every time a change is made in Content Island.

Step 1: Create a webhook in GitHub

We’ll use the project already deployed to GitHub Pages and trigger the deploy.yml workflow using the repository_dispatch event from GitHub Actions.

To do this, update the deploy.yml file:

Add the repository_dispatch event in the on section.
Define a custom event name, e.g., deploy-from-content-island. This name helps identify which event was triggered.
In this case, we’re deploying to GitHub Pages, but this could also be used to deploy to any other provider like Azure, AWS, etc.

./.github/workflows/deploy.yml

name: Deploy to GitHub Pages

on:
  push:
    branches:
      - main
+ repository_dispatch:
+   types: [deploy-from-content-island]
...

Commit and push the changes:

git add .
git commit -m "add repository_dispatch event"
git push

To trigger this event, GitHub provides a dispatch event endpoint for sending POST requests.

You’ll need:

An access token with proper permissions.
The repository owner and name.
The custom event type you want to trigger.

Step 2: Create an access token

We need an access token to trigger the deploy-from-content-island event. As shown in the documentation, it must have write access to Contents.

Go to your GitHub profile settings (not the repo settings) and:

In the sidebar, go to Developer settings → Personal access tokens → Fine-grained tokens.
Create a new token:
- Name it, e.g., deploy-content-island-to-gh-pages.
- Set the repository owner if needed (e.g., content-island).
- Choose an expiration date—GitHub will notify you when it's about to expire.
- Grant access only to the repo you’ll be deploying.
- Under Repository permissions, give write access to Contents.

Generate the token and copy it—you won’t be able to view it again. Store it securely.

Step 3: Create a webhook in Content Island

Now we need to create a webhook in our Content Island project.

After logging in and selecting your project, go to the Webhook tab.

Click Create Webhook:

Enter the organization or repo owner name (e.g., content-island).
Enter the repository name.
Paste the access token you just created.
Enter the event name defined in the workflow, e.g., deploy-from-content-island.
Save your changes.

Now you can make changes to your content. For example, unpublish a post.

Go to the Content tab, select the post to edit, and click Unpublish. This sets the content status to draft, so it will no longer be visible.

Also, if you check the Actions tab in your GitHub repo, you’ll see a new workflow triggered with the name deploy-from-content-island. Opening the deployed site, you’ll now see only four posts available.

If you publish the post again, the workflow will run once more and the post will reappear in the application.

And that’s it! Now everything is set up so you can focus on what really matters—your content—without worrying about manually redeploying your app.