Skip to main content
Link to Pressjitsu home page
Log in
PricingFeaturesAboutContactBlogLog in

Staging Environments for Your WordPress Sites

Last updated on Sep 29th, 2016

A staging environment is a complete copy of your live WordPress website, including all files and database tables. Also called a development environment, it runs on an off-site isolated server and is useful for exactly that—development purposes. You can use it to test changes, new plugins and even a new theme, or any other functionality while avoiding accidents and downtime on your live website.

Now, there are some staging plugins for WordPress out there, like WP Staging or WP Stagecoach. But often such plugins don’t afford to give you the resources that your web host can. Some plugins even create the staging environment in a subdirectory on the same server, which can affect your live site. And in our experience, it’s hugely better to tweak your site on an isolated server.

So, we gathered the know-how of the Pressjitsu Team and built our own staging feature—just the way we ourselves as WordPress users would like to use it.

Without further ado, let’s take a closer look at how to set up and use a staging server on the Pressjitsu Dashboard.

Create New Staging Environment

To create a staging environment with Pressjitsu log in to your Dashboard and select Staging from the navigation panel on the left. At the top, a drop-down menu with all your sites is displayed, and below, the staging server settings for the selected site (staging options for the site that you added first are shown by default). If you haven’t created a staging server for the selected site before, you will see the message “You haven’t created a staging server yet” and a button for creating one.

Now, the Pressjitsu Dashboard lets you create new staging sites with one click. There’s only one thing you should keep in mind before you click the Create staging server button. That is, you should make sure you’ve selected your desired site from the drop-down menu at the top. Then, after you’ve selected the right site and clicked the button, our backend will automatically start cloning your live WordPress site to the staging environment. Usually, this will take 1–2 minutes, but it can take around 10 minutes at most.

Once the server has been created, you can modify the settings. Take a look below for info on the specific connection details and account settings.

Connection details

Once your staging server is ready, you can connect to it in two ways. Both are as secure as connecting to your live site thanks to the fact that Pressjitsu issues SSL certs to staging sites by default.

1. URL

Use the URL that’s in the HTTP field on your Dashboard’s Staging page. You can access your staging site’s WordPress Dashboard by using the same URL. This URL and its subdomain are automatically generated when the staging server is created and they can’t be changed. The staging wp-admin username and password are the same as on your live site. If you change them, the changes will be copied to staging on the next sync.

To limit who has access to your staging site via URL, you can modify Access settings and add users or IPs.


For accessing your staging site through SSH or SFTP, your staging site has its own hostname. Its SSH username and password are the same as for your live site. However, unlike the WordPress credentials, they are copied when you first create the staging server. So, if you change your production site’s SSH/SFTP password, the one for staging will not be updated during the next sync.

If the hostname of your staging site is, then you can connect to it with the following CLI command:




Then, you will have to enter your SSH/SFTP password, which you can find in the email that you received when you first created the production site.

In case you’ve lost your SSH/SFTP access details, contact us at and our support engineers will get you new ones.

Access settings

By default, anyone with the URL or SSH/SFTP info can visit your staging site.

However, you can restrict or grant access to your staging site in two ways:

  1. Create usernames and passwords
  2. Add IP addresses to the IP whitelist

If you haven’t created any users, anyone with the URL will be able to visit your staging site. However, adding the first user will password-protect it. This means only visitors with a username and password will be able to visit the staging site and everyone else will be blocked. And keep in mind that the usernames and passwords added under Access settings won’t give anyone access to the WordPress admin area of your staging site—only the ability to visit. On top of that, once you add a username/password combination and click Save access settings, the password field won’t show the passwords.

Similarly to usernames, if you add no IPs to the IP whitelist, then all IPs will be able to visit your staging site. As soon as you add one IP to the whitelist, though, the list will become exclusive. Then, all IPs not on the list will be blocked from accessing your staging server.

Keeping your staging site publicly accessible to anyone who knows the URL can be useful. For example, if you’re testing some third-party services and tools.

However, in terms of SEO, it might be better to hide your staging website from search engines. And adding password protection to your staging site is one of the best ways to avoid indexing.

Working With Your Staging Environment

On the Pressjitsu Staging Dashboard, you will mainly be carrying out these tasks:

  • Sync from live (pull) – Overwrites your staging server so it becomes an exact copy of your live site. Any unpublished changes on the staging server will be lost during syncing.
  • Review & publish – When you click the Review and publish button, a pop-up opens that shows you the staging server files and data tables that have changed compared to the live ones. There, you can select the ones that you want to publish. However, keep in mind that these changes will only show up if you click the Check for changes button first.
  • Check for changes (diff) – Compares the files and database on the staging and live servers. The output will show you which files and tables on the staging server have changed from the live ones. Depending on the number of changes and the size of your site, this check can take a few minutes.
  • Publish changes (push) – Overwrites the selected changed files on the live server. This can involve adding new files and deleting or changing existing ones.

Bear in mind, though:

If you modified more files after checking for changes but didn’t click the Check for changes button again, then these added changes won’t be shown in the pop-up. This means they won’t be published when you click Publish changes. Instead, after publishing, an automatic re-check is done and you’ll be able to see the newer changes if you open the Review & publish pop-up again.

In case you made a mistake on your staging server or if you simply need to refresh it, you can use the Sync with live button. This will re-sync all files and the database with the live site, overwriting any changes to your staging site.

Disable Third-Party Plugins on Staging

Some WordPress sites use third-party plugins and tools, such as for posting on social networks or sending e-mail notifications. Please note that your WordPress staging site will mirror your production environment, and these plugins will likely follow the same triggers on your staging server.

Thus, we recommend disabling WordPress plugins on staging before making any content changes that could cause them to take action. If you’re working on some custom code or plugin, you can disable these actions by using this snippet:

if ( ! is_callable( array( 'Pj_Staging', 'is_staging' ) ) || ! Pj_Staging::is_staging() ) {
    // Send notification with wp_mail() ...

If you’re working on anything earlier than muplugins_loaded, for example, your wp-config.php file, you can find out whether you’re on a staging server by comparing the hostname:

if ( gethostname() == '' ) {
   define( 'WP_DEBUG', true );
   define( 'WP_DEBUG_DISPLAY', true );

Caching & CDN

Redis-based page caching and the short-term Nginx page cache are both available and enabled by default on a staging server. This allows you to test cache-related changes, such as cookie-based cache varying, etc. If you’d like to bypass caching on your staging server, you can either login (logged in users never hit page cache), or disable page caching altogether in wp-config.php using the gethostname() method above.

If you’re working on anything related to the CDN on your staging server, keep in mind that the requests are still routed through the CDN. However, nothing is cached on the POPs.

Destroying the Staging Environment

Are you done working with your staging environment? Then you can simply destroy it and create a new one whenever you need it.

Also note that, unlike production servers, staging servers don’t have backups. If you wish to backup your staging server, you’ll have to do it manually using the available CLI tools, or via Pressjitsu’s WordPress developer support.

Do you still have any questions or difficulties setting up a staging server for your WordPress site? Feel free to reach out to us via e-mail or live chat.

WordPress staging environments are just one of Pressjitsu’s many features—we are a managed WordPress hosting company that offers fast, secure, and reliable web hosting plans that can really speed up your site. Discover all our benefits!

Pressjitsu—a WordPress hosting provider that truly cares for your sites and their performance.