A staging environment (or shadow) can be opened for websites hosted by Seravo. It operates completely independently of your live production site, providing a safe environment to test updates, themes, and plugins.
The number of shadows available for your site depends on your service package level. You can get a staging environment up and running by contacting our customer support.
Warning: If a staging environment is left unused for a long period of time, Seravo may remove it to free up server space without prior notice.
Using the Staging Site (WordPress Dashboard)
Staging environments work using cookies, which means they use the same address as your production site by default. This ensures that all plugins and licenses function correctly.
You can find the list of activated staging environments in the WordPress dashboard under Tools > Site Status > Shadows.
You can also navigate between environments using the dropdown menu in the top admin bar of the site. When you switch to a shadow, the top admin bar and the bottom notification bar of the page turn red.
Changes made in the shadow will not affect the public live site. You can return to production by clicking the red Exit link in the bottom bar.
Data Transfer Between Staging and Production
Resetting a Shadow (Production > Staging)
Before you begin testing, it is recommended to reset the shadow, which copies the current content and database from the live production site to the staging environment.
Go to Tools > Site Status > Shadows and click Reset. Alternatively, on the command line (SSH), you can run the following command in production:
wp-shadow-reset my_instance
By default, media files (
uploads) are not copied; instead, they are loaded in the shadow via a proxy server. If you absolutely need the physical image files in the shadow, use the command:wp-shadow-reset my_instance --full
Note! If you're using a subdomain in the shadow environment, remember to change the address after each shadow reset.
Publishing a Shadow to Production (Staging > Production)
Once you are sure that the changes work correctly in the shadow, you can pull them into production by running the following command on the production environment's command line:
wp-shadow-pull my_instance
Why Are Error Messages Displayed on the Screen in Staging? (Debug Mode)
In a new staging environment, WordPress debugging mode (WP_DEBUG) is enabled by default. Because of this, you might see code-level warnings or error messages on the screen that are normally hidden on the production site. This is intentional and designed to help developers spot faulty plugins or themes.
If you wish to hide these messages from appearing on the screen, you can edit the wp-config.php file (located at /data/wordpress/htdocs/wp-config.php) and change the WP_DEBUG_DISPLAY setting to false:
/**
* For developers: show verbose debugging output if not in production.
*/
if ( 'production' === getenv('WP_ENV') ) {
define('WP_DEBUG', false);
define('WP_DEBUG_DISPLAY', false);
define('WP_DEBUG_LOG', false);
define('SCRIPT_DEBUG', false);
} else {
define('WP_DEBUG', true);
define('WP_DEBUG_DISPLAY', false); // Changed from true > false
define('WP_DEBUG_LOG', '/data/log/php-error.log');
define('SCRIPT_DEBUG', true);
define('WP_DEVELOPMENT_MODE', 'all');
}
Advanced Development (SSH, Git & rsync)
Developers can establish an SSH/SFTP connection directly to the staging environment. You can identify the environment by checking the WP_ENV environment variable (its value is either staging or testing, whereas in production it is production). You can verify environment variables using the command wp-list-env.
Shadow Cookie (seravo_shadow) and API Calls
If you want to test the shadow in a browser without logging in, or make curl requests to the shadow's REST API, you must use the shadow cookie or URL parameter (e.g., ?seravo_shadow=token). This tells the server to route the request to the correct shadow instead of production:
curl -iLs https://example.com/wp-json/wp/v2/?seravo_shadow=token
Transferring Individual Files or the Database with rsync
If you do not want to deploy the entire shadow (wp-shadow-pull), you can transfer only the modified files from production by utilizing the shadow's SSH port (e.g., 11111):
# Transferring files (excluding the uploads folder)
rsync -av --delete-after --exclude=wp-content/uploads -e 'ssh -p 11111' [email protected]:/data/wordpress/ /data/wordpress
# Pulling the database only from staging to production (Note: this overwrites the production database completely!)
ssh [email protected] -p 11111 'wp db export -' | wp db import -
Always remember to clear the cache with the command wp-purge-cache after making changes.
Database Overwriting and Risks
The WordPress database model does not support automated merging of individual content pieces (such as a single new blog post or an isolated settings change) from one database to another.
If you deploy the entire staging database to production, it will overwrite all data currently in production. For active online stores (WooCommerce) or high-traffic sites, this means you will lose all new orders and customer data that arrived after the shadow was created. Therefore, we highly recommend deploying primarily code changes (themes and plugins) from staging to production, and making content updates directly on the live production site.