Staging is a copy of production at staging.<domain>, password-protected and not indexed. Safe Push publishes staging's code only after Performance Guard has measured both versions. The reason for each step is in Staging, Safe Push and Performance Guard.

Create staging

1. Open the production site and choose the Staging tab.
2. Press Create staging. The task Staging clone started begins.
3. When the task ends, the tab shows the staging domain and the User and Password that protect it. Press Visit to open it, or Open staging to manage it as a site.

A site has at most one staging copy, and a staging copy cannot be staged itself. A WordPress site with an external database cannot be cloned.

Staging gets only production's primary database, in a database of its own (site_<staging-id>, with its own user). The site's other databases are not copied: they stay in production only, and staging does not see them.

NoteThe staging certificate

Staging starts without a certificate: until you issue one it answers with the server's self-signed fallback certificate, which browsers refuse. Point staging.<domain> at the server too (an A or AAAA record, or a wildcard *.<domain>), then press Open staging, SSL tab, Issue / renew, or run cgctl --wait cert issue <staging-id>. Recreate staging makes a new site: issue the certificate again.

Compare staging and production

The Staging vs production section lists the files added, modified and removed on staging. Press Refresh after a change. The comparison skips wp-content/uploads and .git folders, and stops at 1000 files per list: beyond that the page says List truncated.

Publish all the code

1. In the Safe Push panel, type in Pages to measure the paths to compare, separated by spaces or commas (at most 10, each starting with /). The initial value is /.
2. Press Publish everything and confirm.
3. Follow the task. Performance Guard requests each page 200 times from staging and 200 from production, then the release is built, made live and verified. For a page PHP renders in 60 ms the whole push takes about 30 seconds; at 300 ms, about 2 minutes per page.
4. Open the Releases tab: the new release is live, or blocked with the reason. Press Guard: … on its row to see the report.

Publish only some files

1. In the list of differences, select the files to publish. To add a path that is not in the list, type it in Add a file or folder and press Add.
2. Press Publish selection and confirm.

The release starts from production's code, with the chosen paths taken from staging. wp-config.php and paths under wp-content/uploads cannot be chosen: configuration and uploaded files always stay production's.

Publish database tables

The tables go from staging's primary database to production's. Production's other databases never change with a publish.

1. In the Database tables panel, select the tables (1 to 50).
2. Press Publish tables, type the production domain to confirm, and confirm.

Before it touches production, the panel takes a safety snapshot and checks it with a restore test. If the snapshot fails the test, production stays as it was. Tables marked protected live data cannot be published: users, and on a store orders, customers and sessions.

Recreate staging

Press Recreate staging and type the staging domain to confirm. The current staging copy, files and database, is deleted and replaced by a fresh copy of production.

From the command line

bash

cgctl --wait staging create <site-id>
cgctl --wait safe-push <site-id> / /shop/

<site-id> is the production site's number; the paths after it are the pages to measure. With no paths, Performance Guard measures / and /?cloudground-probe=uncached.

Next step

If a published release misbehaves, roll back a release.