Automating Deployments with GitHub Actions

This guide will walk you through how to automate your deployments with GitHub Actions. This is useful for deploying your application to your servers when you push to your repository.

Video Overview

We have a video that goes over this process in more detail.

Default Behavior

By default, Spin Pro comes with a GitHub Actions workflow that will deploy your application to your server when you push to your main branch in your repository. This workflow is located in the .github/workflows directory of your repository. You can customize this workflow to fit your needs.

Prepare an .env.<environment> file

Make sure you don't miss the process of preparing your .env.<environment> file. Ensure this is done before moving forward.

Learn how to prepare your .env.<environment> file →

Create a GitHub Repository and prepare for deployment

Once we have an environment variable file created, we can create a GitHub repository for our app right from the CLI using the GitHub CLI with spin gh.

spin gh repo create

# Make sure to push an an EXISTING repository (since we initialize a Git repo for you)

Configure GitHub Actions Secrets/Environment Variables

In order for deployments to work automatically with our GitHub Actions workflows, we need to configure secrets and environment variables in GitHub Actions. You can do this manually via the UI, but we found it a lot easier to combine this all into an automated process.

spin configure gha <environment>

The above command takes out all the heavy lifting for you and will upload your environment variables to GitHub Actions. You can verify their existence by going to the Settings tab in your GitHub repository and then clicking on Secrets and variables then Actions.

Once spin configure gha <environment> completes, you're now ready for deployment! 🚀

Running a deployment

To run a deployment, you simply need to push your changes to your repository. By default, any code pushed to main will trigger a deployment to "production."

git push origin main

Changing the deployment trigger

Some teams may want to change the default deployment trigger. For example, instead of deploying to production when you push to main, you may want to use "release" triggers.

You'll see in the default triggers by looking at the on section of the workflow file. Refer to the GitHub Actions documentation for more information if you'd like to change the trigger.

If you'd like advanced customization, refer to the following GitHub Actions that we've created:

• serversideup/github-action-docker-swarm-deploy
• serversideup/github-action-docker-build

You can also refer to the Workflow syntax for GitHub Actions document if you'd like even more customization options.

Where to watch the status of your deployment

You can watch the status of your deployment by going to the Actions tab in your repository. You can see the status of the deployment and any logs that are generated.

Using self-hosted runners to improve security

If you'd like to improve the security of your deployments, you can use self-hosted runners. This will allow you to run your deployments on your own infrastructure instead of GitHub's infrastructure. You can learn more about self-hosted runners in the GitHub Actions documentation.

Once you have a self-hosted runner set up, you can use a firewall to limit SSH access to your server only from IP addresses that are associated with your self-hosted runner and a dedicated VPN for your team.

Viewing the deployment

Once your deployment is complete, you can visit your application that you set with the APP_URL environment variable in your .env.<environment> file. If everything works, you should see your application! 🥳

Connecting to your server

If you need to connect to your server, you can:

• Connect to your server via SSH
• Connect to your database

If things didn't work, see our troubleshooting guide.