Subtle diagonal pinstripe pattern in light grey and cream, giving an impression of printed editorial paper

Setting Up a WordPress Staging Environment with Git and WP-CLI

A reliable staging workflow is one of the smartest investments an Australian WordPress shop can make. Whether you are a solo freelancer in Melbourne or part of a small agency in Brisbane, replicating a production site in a safe, separate branch lets you test theme updates, plugin upgrades, and database migrations without risking live traffic.

Git provides the version control backbone for this setup, while WP-CLI gives you command-line control over WordPress itself. Together they remove most of the manual, error-prone steps that slow teams down when a release looms.

The approach below works for any standard LAMP or LEMP stack running on a VPS in Sydney, a local Ubuntu machine, or a managed host that exposes SSH. You will move from edit-and-pray releases to a structured pipeline where every change is reviewable, traceable, and reversible.

Why a Version-Controlled Staging Workflow Matters

A staging environment is a copy of your live site where you can break things on purpose. Pushing directly to production is a habit that costs Australian businesses real money, particularly when WooCommerce checkouts drop during a sale that coincides with an unrelated plugin update.

Git turns the staging environment into something richer than a simple clone. Every commit is a snapshot, every branch is an experiment, and every merge is a documented decision. Roll back a failed schema change by checking out an earlier tag rather than restoring from a backup tape in Adelaide.

Pairing Git with WP-CLI means theme and plugin operations happen in a controlled, repeatable way. Instead of clicking through wp-admin, you run wp plugin update or wp theme activate and capture the output in your terminal history. The result is an audit trail you can hand to a client or a compliance officer when something eventually needs explaining.

Preparing Local and Server Environments

Before a single commit is pushed, your machine and your staging server need a few things in common: SSH access, a recent version of PHP (7.4 or higher, ideally 8.1+), MySQL or MariaDB, and WP-CLI installed locally with a matching version on the remote host.

Mac and Linux developers usually have a working PHP stack within minutes via Homebrew or apt-get. Windows users often opt for WSL2, which now runs smoothly across most NBN-connected offices from Perth to Hobart. Whichever path you choose, confirm the local PHP version matches production to avoid the classic works-on-my-machine mismatch.

For the staging server itself, an entry-level VPS from an Australian provider such as VentraIP, Panthur, or NetOrigin is usually enough for a single site. Allocate at least 2 GB of RAM if you plan to test WooCommerce imports with the sample products data, and make sure the database server lives on the same continent to keep latency low for the team in your timezone.

Configuring Git for a WordPress Project

Start by initialising a repository at the root of your WordPress installation, then add a sensible .gitignore. Core themes like twentytwentyfour, the wp-content/uploads directory, and any cache folders should never enter version control.

A typical .gitignore for WordPress looks like this:

/wp-content/uploads/
/wp-content/cache/
/wp-content/backup-db/
/wp-content/w3tc-config/
/wp-content/plugins/*/
!/wp-content/plugins/custom-plugin/
!/wp-content/plugins/akismet/

The two ! lines keep your bespoke plugin and any premium plugin you have licence files for. Store licence keys and salts in a .env file that stays uncommitted, then load them with a small mu-plugin. This keeps secrets out of the repository, an important habit given the ACSC's ongoing guidance about credential exposure in Australian businesses and the broader push from Canberra on baseline cyber standards.

Add a remote that points to your staging server, or to a private repository on a service you trust. Bitbucket, GitHub, or self-hosted Gitea all work well. If you want a refresher on best practices for WordPress repositories, there are practical walkthroughs worth bookmarking before you start committing.

Provisioning and Automating the Branch with WP-CLI

With the repo ready, log in to the staging server over SSH and pull the branch into a dedicated document root. A common pattern is /var/www/staging.example.com.au, kept separate from the live path so the two never collide.

WP-CLI speeds up the install dramatically. A single command sequence can create the database, download WordPress, generate salts, and run the installer without a single browser prompt:

wp core download --path=/var/www/staging.example.com.au
wp config create --dbname=wp_staging --dbuser=staging --dbpass=$(cat /var/db.pass) --locale=en_AU
wp core install --url=https://staging.example.com.au --title="Acme Staging" --admin_user=ops --admin_email=ops@example.com.au --skip-email

The --locale=en_AU flag localises the install for Australian English, which sets the date format to d/m/Y and aligns the admin interface with how teams in Sydney read their data. Once the core is in place, replace the wp-content/plugins and wp-content/themes directories with symlinks to the matching folders in your cloned repository so changes flow directly from commits.

A small post-receive hook on the staging server turns a git push into a full refresh:

#!/bin/bash
git --work-tree=/var/www/staging.example.com.au checkout -f main
cd /var/www/staging.example.com.au
wp core update-db
wp cache flush

For multi-developer teams, consider Deployer, Buddy, or a GitLab CI pipeline that runs linting and PHP_CodeSniffer before deployment. Adding a smoke test with wp eval that hits the front page and confirms a 200 status is another small step that catches broken rewrites before a stakeholder in your client's office notices them.

Moving Content, Media, and Database State Safely

WordPress stores two different kinds of data in version-controlled folders: code (themes, plugins, mu-plugins) and uploads. Code belongs in Git. Uploads do not, they belong in object storage such as Amazon S3 or a local directory synced through a tool like rsync or a purpose-built media mirror.

For a first push from production to staging, take a sanitised database dump with wp db export. Anonymise any user records that contain personal information, even if the staging site sits behind a basic auth prompt. The Notifiable Data Breaches scheme applies broadly to Australian organisations, and treating test environments with the same care as production is a low-cost habit that pays off during audits.

Then run wp search-replace 'https://example.com.au' 'https://staging.example.com.au' --dry-run to preview URL swaps. Once the dry-run output looks right, drop the flag and pipe the SQL straight into the staging database. Search-replace is far more thorough than a manual sed pass across the dump, particularly when serialised data is involved, and you avoid the brittle edge cases where a stray option name breaks a widget block.

Habits That Keep the Staging Pipeline Trustworthy

Below are a few habits that make the difference between a staging environment your team trusts and one nobody opens. Treat these as living rules rather than rigid policies, adjusting them as your team and your projects evolve.

If something does go wrong, rolling back is a single git revert away. Tag every successful deploy with a date-stamped annotation, such as git tag -a deploy-2024-03-15 -m "march release", so you always know exactly what was live at any given moment. Once these habits are in place, the staging site stops being a chore and starts being the safest place in your entire workflow to try something new, whether your day starts in a coworking space in Brisbane's Fortitude Valley or in a busy agency office in Melbourne's Cremorne.