This usage guide explains the features in the Staging tool available with your WPMU DEV hosting account. Learn how to use Staging to simply pull a Production site to a Staging environment for safely developing and testing updates to plugins, themes, or your server and pushing your changes live.

Quickly navigate this usage guidance from the index.

If you haven’t set up your WPMU DEV hosting account yet, visit the hosting page, where you can explore the features, see pricing packages, and start a free trial.

Already a member?

Visit your hosting dashboard to get started. More on getting started with WPMU DEV hosting can be found here.

9.1 Setting up a staging site

Copy chapter anchor to clipboard

You can create a Staging site by visiting the Staging tab of your Hosting Hub. Simply follow the prompts there to create and access your new Staging site, which is a full copy of your live site. Perfect for trying out new plugins or themes, proofing content changes, and other development work.

Hosting overview Staging tab

To move a website to Staging for the first time, visit the Staging module and click the Start button.

setup staging environment

This will generate a copy of your live site with a modified URL, such as: When the Staging environment is created, a hotlink to the Staging environment will be available under the Domain field.

New staging domain hotlink


Staging sites do not have backups and can not be recovered after resyncing with Production. If you are working on a rewrite or long-term design project, consider local development or working from a password-protected Production environment with regular backups. For Production sites hosted with WPMU DEV, use managed backups. For sites hosted with a 3rd-party, use Snapshot.

9.2 Staging Options

Copy chapter anchor to clipboard

This section covers the three options available in the Staging module. Options include:

  • Move Staging to Production
  • Reset Staging
  • Delete Staging

9.2.1 Move Staging to Production

Link to chapter 2

When you are ready to make the contents of your Staging site live, move them to Production. This will replace your live, or Production site, with the contents of the staging site.

To move your Staging site to Production, click the Go button.

Push Staging to production button

This will open a module where you can select to move the Staging Files or Files & Database to Production.

  • Production Files – Your site’s framework without the content, including your WordPress installation files, themes, and plugins.
  • Production Database – The content and settings you add or apply to the framework stored in your Production Files.

Use the dropdown to select whether you wish to replace only your site files, or both the files and database. Click Move to Production to continue.


By moving either the Files or Files & Database from the Staging environment to Production all of the current Production changes will be lost. As a precaution, a pre-staging backup of the live site is created each time staging is moved to production.

9.2.2 Reset Staging

Link to chapter 2

This option will replace the current Staging environment with a fresh copy of Production. All of the Staging files and database will be overwritten.

Click Reset to open the Reset module.


Clicking Confirm Reset will automatically reset your Staging environment. Click cancel to close the module without resetting your Staging environment.

9.2.3 Delete Staging

Link to chapter 2

This option will delete the current Staging environment completely. All of the Staging files and database will be lost.

Click Delete to access the pop-up and then Continue to immediately delete the Staging environment or cancel to close without deleting.


To the right of the Staging Options module, you will find information about your Staging site, configuration options, and settings.


The domain is the URL created for accessing your Staging site. The domain section will display the URL and is hotlinked so you can quickly access the site.

Note that the links shown here are already encoded with the HTTP Auth username and password you set in the Password Protection section below. So when you click on either of them, you’ll automatically bypass the HTTP Auth. Of course, if anyone enters the plain URL in a browser, they would still need to provide those credentials to access your staging site.

New staging domain hotlink


The current version of WordPress being run by your staging site is displayed here. If you are testing an update to core on your Staging site, and push to a different version, use the Refresh button next to the version number to verify the changes.

If you are running a different version of WordPress core on your Staging site when pushing back to your Production site, your Production site will be overwritten.

Last Sync

The Last Sync field is the date and time your Staging and Production sites were synced. This can be valuable if you are developing on a Staging site over a long period of time before syncing to Production and don’t want to lose changes in your Production environment.

PHP Version

The PHP Version is the version of PHP being used for your Staging site. This can be used to test your site when Upgrading or Downgrading your PHP version.

Click the pencil icon to switch between the list of supported versions of PHP.


We recommend using the latest available version of PHP on Production sites when possible for the fastest, most secure site.

Click Apply to save your changes or click the X or Cancel to close the PHP module without switching your PHP.

9.3.1 Password Protection

Link to chapter 3

HTTP Auth Password Protection is required for all Staging sites to help ensure that Staging sites aren’t indexed by search engines and that your Staging site is not visited by the public. The password is not the same as any WordPress user account and can be set from your Hosting Hub.

HTTP Auth password protection for staging sites

  • Username — The Username field lists the current Username. By default, this will be your admin Username. You can change the Username by clicking the pencil icon next to your Username.

Click the Save button to save your new Username or Close to close without making any changes.

  • Password — A strong password is generated when the Staging site is setup. Click the copy button for storing the password to your clipboard for pasting in. Use the pencil icon to customize or change your password.

Click the Save button to save your new Password or Close to close without making any changes.


Note that the staging Domain links in your Hub are already encoded with the username & password you set here, as seen in Settings above.

9.3.2 Manage Database

Link to chapter 3

Get access to make changes to your Staging websites database. Click the Manage Database link to open the phpMyAdmin manager for your Staging site. This will not make changes to your Production site unless it is pushed live.

Hosting phpMyAdmin

Detailed documentation for using phpMyAdmin can be found on the phpMyAdmin site.

9.3.3 Manage Files

Link to chapter 3

Click the Manage Files link to pop open the WPMU DEV File Manager for your site in a new tab.

Production and Staging server location in File Manager

The left panel allows you to navigate through files and logs from both the Production server and the Staging server.

For more information about the File Manager, see the Files chapter in the WPMU DEV Hosting > Tools guide.

9.3.4 Reset WP

Link to chapter 3

Use the Reset WP option if you ever need to revert your staging site to a fresh, default WordPress installation. The option here does not affect your live site; there is a separate Reset WP option for your live site under the Tools tab.

Note that this is very different than the Reset Staging option above which pulls in a fresh copy of your existing live site.

Click Reset to pop open a modal window where you’ll be prompted to enter your WPMU DEV password, and confirm the action.

Reset WP Staging dialog

This reset will delete all files (including non-WordPress files) in the Staging directory of your staging site before the fresh re-install of WordPress. Unlike when resetting WP on your live site, a backup will not be created of your staging site.

Once you click the Continue button, you’ll be prompted to create a new WordPress administrator account for the fresh install. You can use the same email, username and password as you had for your admin user before, or create a brand-new admin user.

Create WordPress Administrator account

Click the Continue button and you’ll then see a screen indicating the reset is underway. Depending on the size of the site, it can take several minutes for this to complete.

Reset WordPress on staging site progress

When the reset process is complete, visit your staging site where you’ll see a brand new default install of WordPress for you to build on.

9.4 Troubleshooting & Notes

Copy chapter anchor to clipboard

You can sync a new copy of your Production site to your Staging site at any time by simply clicking the Reset button.

When you push a copy of the Staging site to your Production site, we will automatically make a backup of your Production site first. This helps with fast recovery should you need it.

Staging Resources

Staging uses an incremental clone of your Production file system. This means that it normally uses very little of your storage space. Only new/changed files on Staging or deleted files on Production will increase the amount of storage used by Staging and doing a fresh sync from Production will reset that to zero again.

Object Cache and Static Server Cache are not enabled on Staging sites. This will make Staging sites a bit slower than your Production sites but helps make development easier.

Staging is given limited server resources to prevent it from adversely affecting your Production site. This too can make Staging run slightly slower, and in rare cases cause errors with some plugins that demand lots of resources.

For example, staging sites only have 2 PHP workers (the processes that run PHP on the server), regardless of the hosting plan.

Multisite Staging

Depending on how your multisite is set up, creating a staging copy may or may not work as expected.

  • Subsites in a staging environment of a subdirectory-based multisite will work just fine.
  • Subsites in a staging environment of a subdomain-based multisite will work with one caveat: they will not be secured by SSL. So if any processes require HTTPS, you will need to bypass or ignore SSL errors on the staging subsites.
  • Subsites in a staging environment of a multisite using a plugin for domain mapping (like WP-Ultimo), will work as above as long as you deactivate the domain-mapping plugin on the staging site so the subsites are accessed at their “normal” staging URLs.
  • Subsites in a staging environment of a multisite that have been natively domain-mapped will not work at all. The domain-mapped subsites on staging will still point to their mapped domains. It would require significant manual effort to make such domain-mapped subsites work on staging. You would need to run a search & replace in the staging database to change all instances of the mapped domain URLs to what they would normally be on staging, then change them back again after edits, before and/or after pushing to live.