One of my favorite features of WPEngine is its integrated git push deployment. Instead of manually transferring files over SFTP, you can push code changes directly while keeping your project under version control.
WPEngine allows you to create unlimited transferrable installs, so it’s convenient for developing multiple client sites. When you’re ready to hand a site to a client, you can enter their email and WPEngine will send step-by-step instructions to complete the transfer.
Create a site on WPEngine
From the WPEngine dashboard click “Add Install” and give the new install a name. To clone an existing live site, install the WPEngine Automated Migration plugin on the live site, enter your new WPEngine install details, and let the plugin handle the migration.
After creating the install, open “Git Push” in the sidebar, enter your name, and paste your SSH public key. WPEngine’s support documentation explains the steps to enable Git for the install.
Setup locally
Set up a local development environment using tools such as MAMP, Local, or similar. I also recommend installing WP-CLI for command-line WordPress management.
Open a terminal in the website’s top-level folder and initialize git: git init. Instead of versioning everything (core, themes, plugins), it’s often best to limit version control to the code you actively edit using a .gitignore file. For example, many developers track only a custom theme and a core functionality plugin.
If you already have a GitHub repo, copy its clone URL and add it as a remote. For example: git remote add origin [email protected]:yourname/your-repo.git
Return to the Git Push page in the WPEngine dashboard. In the Git Push settings you’ll see remotes for production and staging. Add those remotes to your local repo, making sure to use the correct URLs. Example:
git remote add production [email protected]:production/mysite.git git remote add staging [email protected]/mysite.git
Pushing code updates
During development, commit your changes regularly: git commit -am 'Describe your changes'. Push changes to GitHub with git push origin master. When you want to deploy to WPEngine, push to the appropriate remote: git push production master or git push staging master.
When you push, WPEngine scans the files for PHP errors, updates the site files, and clears the cache automatically.
For database and media synchronization, I recommend WP Migrate DB Pro to push and pull databases and media between environments. If your site contains a large media library, consider referencing production media from your local environment instead of syncing all files locally to save disk space and time.
Migrating environments
WPEngine supports multiple environments. Enabling the Multi-Environment Site option provides Production, Staging, and Development environments which simplify workflow for redesigns and major updates.
For redesign projects already hosted on WPEngine, a common workflow is to copy production to development, build the new theme and functionality in development, then push the finished environment to production.
When sites accumulate substantial new content during development—such as many posts and comments—you’ll want to preserve that content. A tested migration process looks like this:
- Implement a content freeze on production: clients should avoid creating or editing content during final migration steps.
- Create fresh backups of all environments (Production, Staging, Development).
- Deploy the latest production backup to the staging environment.
- Push code updates to staging:
git push staging master. - Rebuild the site on staging: configure plugins, menus, widgets, forms, and update pages that need new content.
- Conduct a final review of the staging site with the client.
- Once approved, deploy staging to production, overwriting production files and the database.
Minimize downtime with a hidden feature flag
By default, deploying a staging environment to production can make the production site unavailable until the migration completes to avoid data loss during the process. For some clients that downtime is unacceptable, so we use an undocumented WPEngine option that minimizes downtime.
Contact WPEngine support and request the clone_site_use_deploy_dir site config option for the specific install. Because this is not a public setting, you may need to ask support to escalate the request.
When this option is enabled, WPEngine copies the source site to a temporary directory and database, performs search-and-replace operations there, and then atomically moves the completed temporary copy into place. The production site remains available during the copy and only experiences a short downtime during the final move.
We enable this flag for many client sites and typically see no noticeable downtime during deployments.
Important caution: enabling this option introduces a risk of data loss if new content is written to the production site while the copy is in progress. Any data created on the target site during the copy will be overwritten when the final move occurs. For sites that collect critical, time-sensitive data—such as ecommerce or membership sites—avoid this approach or coordinate a strict content freeze during the migration.