One of the features I rely on most with WPEngine is the built-in git push deployment. Rather than manually transferring files via SFTP, you can push code from your local repository to your WPEngine install while keeping everything under version control. This streamlines development and reduces the risk of human error during deployments.
WPEngine allows the creation of multiple transferable installs, making it convenient to develop and hand off sites to clients. When the site is ready, you can initiate a transfer by providing the client’s email address and WPEngine will send instructions for completing the transfer.
Create a site on WPEngine
From the WPEngine dashboard, click “Add Install” and assign a name. To clone an existing live site, use the WPEngine Automated Migration plugin on the source site and provide the new install details; the plugin handles migrating content, files, and settings. After the install is created, open the Git Push settings, enter your name, and paste your SSH public key to enable git-based deployments.
Setup locally
Prepare a local development environment using MAMP, Local, or another tool of your choice. Installing WP-CLI is also helpful for command-line management of WordPress. In your project folder, initialize git with git init. Rather than tracking every file in the WordPress install, use a .gitignore to limit version control to the code you actively edit—typically a custom theme and any custom plugins or functionality.
If you maintain a remote repository on a hosting service, add that remote and push your local repository there. Then, in the WPEngine Git Push screen you will find the git remote URLs for your production and staging environments. Add these as remotes in your local repository. Example commands for adding WPEngine remotes look like:
git remote add production [email protected]:production/mysite.git git remote add staging [email protected]/mysite.git
Pushing code updates
During development, commit changes regularly using clear commit messages, for example: git commit -am 'Add homepage layout and responsive styles'. Push updates to your origin repository with git push origin master. When you want to deploy to a WPEngine environment, push to the corresponding remote, for example git push staging master or git push production master.
WPEngine will scan the pushed files for errors, apply only the necessary changes, and clear caches as part of the deployment process. For database and media synchronization between environments, using a database migration tool is recommended. If your site includes a large media library, consider methods that allow the local environment to reference production media rather than copying everything locally.
Migrating environments
WPEngine supports multiple environments—commonly Production, Staging, and Development—so you can build and test changes safely before pushing them live. For redesign projects, a typical workflow is to copy the production site to development, build the new theme and functionality there, and then push the changes through staging before deploying to production.
To protect newly created content during a redesign (for example, posts and comments added while development is ongoing), follow a careful migration process:
- Announce a content freeze on production so the client does not create or edit content during the final migration window.
- Take fresh backups of all environments (Production, Staging, Development).
- Deploy the latest production backup to the staging environment.
- Push code to staging with
git push staging master. - Rebuild and test site elements on staging: plugins, menus, widgets, forms, and pages that require new content.
- Perform a final review of staging with the client and address any issues.
- When approved, deploy the staging environment to production, overwriting the production files and database.
Minimize downtime with a hidden feature flag
Deploying a full environment copy to production normally makes the site temporarily unavailable during the migration to prevent data loss. If minimal downtime is a priority, there is an optional site configuration that creates the copy in a temporary directory and database, performs necessary search-and-replace operations there, and then atomically moves the prepared site into place. This reduces the period when the production site is inaccessible to only the final move operation.
Requesting this configuration from WPEngine support can significantly reduce downtime during large deployments. However, take care: because the production site remains accessible during the copy, any new data written to production while the copy is in progress can be overwritten when the deployment completes. For sites that collect critical data during migrations—such as ecommerce or membership platforms—this approach introduces risk and should be used only with appropriate safeguards in place.