• Global. Remote. Office-free.
  • Mon – Fri: 8:00 AM to 5:00 PM (Hong Kong Time)
English

Warning: foreach() argument must be of type array|object, bool given in /var/www/html/wp-content/plugins/wp-builder/core/Components/ShiftSaas/Global/topbar.php on line 31

WordPress to WP Engine: Manual & CI Deploys with GitHub Actions

By admin July 26, 2025 6 min read

When working on WordPress projects as a team, it is pretty common to run into issues figuring out how to keep everyone on the same page without working alone. Managing your team’s workflow and avoiding deployment headaches—especially when pushing updates to the cloud—can be tricky.

In this guide, we will look at how to handle deployments to WP Engine using GitHub Actions, both manually and with continuous integration, so your team can work smoothly and avoid common problems.

WordPress & Local Environment Setup

Back in the day, people often used XAMPP with their own custom setups—like different PHP versions—which made things a bit messy and hard to get everyone on the same page.

Now, with tools like Local, it is way simpler to set up a local WordPress site because all the settings are in one place, making local development a lot smoother.

Drop this website wpengine.com and get Local tool via https://localwp.com/, after installing it and see the screenshot as below, here is local.shiftsaas.com available for this website you are in shiftsaas.com.

The next step is to create a GitHub repository and configure SSH access keys (https://github.com/settings/keys) for local team members who need to access the repository. We will then add this Git repository to the source code, specifically isolating it within the public folder where the root WordPress project resides.

As you can see, we need to generate an RSA key pair: a private key and a public key. The public key will be added to the GitHub account to enable access, while the private key will remain on the local machine and is used to authenticate when connecting to the GitHub repository.
On macOS, this setup is commonly used and typically looks like this.

macbook@Macbooks-MacBook-Pro .ssh % ls -a
.			known_hosts.old		
..		rsa
config rsa.pub		
config.bak known_hosts

Run the command below to generate a 4096-bit RSA key pair. Replace the email with yours. The keys will be saved as rsa and rsa.pub in ~/.ssh:

ssh-keygen -t rsa -b 4096 -C "[email protected]" -f ~/.ssh/rsa

Using SSH config which tells macOS to use specific key (rsa.pem) for GitHub and store the passphrase in the keychain for easier, secure access.

macbook@Macbooks-MacBook-Pro .ssh % cat config
Host github.com
  IdentityFile ~/.ssh/rsa.pem
  AddKeysToAgent yes
  UseKeychain yes

Using command clears all loaded SSH keys, adds rsa as the active key, and tests the connection to GitHub over SSH.

ssh-add -D && ssh-add ~/.ssh/rsa && ssh -T git@github.com

Git & GitHub Workflow for WordPress Projects

First, after making the repo on GitHub, We will connect it to our local WordPress folder from the path above. For example

macbook@Macbooks-MacBook-Pro public % pwd
/Users/macbook/Local Sites/localshiftsaascom/app/public

Replace your-username/your-repo.git with the URL of your GitHub repository, and update the SSH key path (~/.ssh/id_rsa) if your key is stored elsewhere.

git remote add origin git@github.com:your-username/your-repo.git

Decide which files shouldn’t be pushed to GitHub—like sensitive info or unnecessary files—and list them in the .gitignore file. Here is an example:

Cool, now that you have set up your .gitignore, go ahead and make your first commit — something like Initial project. This keeps your repo clean and avoids pushing stuff you don’t need.

Once it is on GitHub, clone the repo into a new folder named after your project (like shiftsaas instead of just public). That folder will be your main project workspace where you can manage branches like develop, staging.”

We are using two Git remotes:
– origin s linked to the /app/public folder, which connects to WP Engine for deployment.
– shiftsaas is used in a separate folder to manage development work like pull requests, feature branches, and team contributions.

When pushing to a WP Engine environment (dev, staging, or production), work inside the site/app/public folder. Commit any changes from Local WP sync before pulling from shiftsaas/develop to avoid merge conflicts and keep your Git history clean. (Only files are pushed — database stays local).

Deploying from Development to Staging

In practice, we clone the repo or change the remote to shiftsaas to manage development on WP Engine. You can do the same with staging and master branches to handle staging and production environments.

Deploying to WP Engine Staging without affecting content or author data:

  1. Merge changes from shiftsaas/develop into your local shiftsaas/staging branch.
  2. Update your local origin/staging by pulling or fetching the latest shiftsaas/staging.
  3. In Local WP’s /app/public folder (connected to WP Engine), commit any unstaged changes such as synced files or database updates.
  4. Push the clean origin/staging branch to WP Engine through Local WP’s Git connection.

This workflow ensures that fixes from shiftsaas/develop propagate to staging and production, while environment-specific updates are committed locally and merged back into the central repository as needed.

What about deploying to production?

Since staging is usually a copy of production, moving code over doesn’t have to be complicated. WP Engine makes it easier—you can just use the clone environment feature to copy everything from staging to production without doing a manual deploy.

CI Deploys with GitHub Actions

For CI deploys with GitHub Actions, you should generally work with the shiftsaas folder (the central project repo).

Why?

  • The shiftsaas folder is the main Git repo where the team collaborates: all PRs, merges, and branch management happen here.
  • GitHub Actions triggers run on the central repository (i.e., shiftsaas), not on your local app/site/public folder.
  • Your app/site/public folder is mainly for local development and syncing with WP Engine environments but isn’t the source for automated CI workflows.

Having the following structure:

.github
├── scripts
│   └── deploy.sh
└── workflows
    └── deploy-cms.yml
Git Remote SSH Alias Setup

Use the command:

git remote set-url shiftsaas [email protected]:your-username/your-repo.git

to set up the remote repository for app/site/public, so it can trigger actions (like builds or deployments) on every push.

To sync changes from the remote branch:

git fetch origin
git merge origin/develop

To deploy changes, push manually using the Local WP Engine tool.

Instead of pushing to the default origin, we push changes to a GitHub repository that has CI/CD set up. This setup automatically pulls the latest code and runs the deployment process on WP Engine.

We support two ways to handle this:

  • From app/site/public (controlled by shiftsaas)
  • From another local path linked to the GitHub repository (controlled by origin)

These paths can include files like .xml and .sh to help trigger or support the deployment process.

.github/workflows/deploy-cms.yml
name: 🚀 Deploy to WP Engine

on:
  push:
    branches:
      - staging
      - production

jobs:
  deploy:
    name: Deploy to WP Engine
    runs-on: ubuntu-latest

    steps:
      - name: ⬇️ Checkout Repository
        uses: actions/checkout@v4

      - name: 🛠️ Set Up SSH
        uses: webfactory/ssh-agent@v0.8.0
        with:
          ssh-private-key: ${{ secrets.WPENGINE_SSH_KEY }}

      - name: 🚀 Run Deploy Script
        run: bash .github/scripts/deploy.sh

Continue…