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

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 "your-email@example.com" -f ~/.ssh/rsa

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

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

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

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

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

In this setup, GitHub Actions handles the deployment process from the GitHub repository to WP Engine. Instead of manually uploading files, the workflow is triggered automatically whenever changes are merged into the release branch.

The workflow files are stored in the .github directory of the repository. This directory contains the configuration and deployment scripts used by GitHub Actions.

.github
├── scripts
│   └── deploy.sh
└── workflows
    └── deploy-cms.yml

.github
├── scripts
│   └── deploy.sh
└── workflows
    └── deploy-cms.yml

You will still do all your building and testing in your local WordPress project (app/site/public). But deployments don’t run from your laptop. Instead, they get kicked off by GitHub Actions.
That means:

• Deployments come from the code in the repo, not someone’s local machine.
• Everyone on the team follows the same process.
• WP Engine environments get updated based on what is in the main GitHub repo.

Branch per Environment

• develop → Deploy to WP Engine Development
• staging → Deploy to WP Engine Staging
• main (or production) → Deploy to WP Engine Production

Triggered by Push

Secrets & credentials

Go..

Continue…