Skip to content

Staging environments and cloning

A staging environment is a second copy of your website or application, on its own domain, that you can break without anyone noticing. When the change works there, 'Clone' copies it over to production.

This article explains what a staging environment is, what is and isn't separate from production, and exactly what 'Clone' does.

Two things to know before you clone

  • 'Clone' copies files only. The database doesn't move, so a change that lives in the database — a WordPress setting, a new page, a Craft entry — stays on staging.
  • It runs staging to production only. There's no button to copy production back over staging.

What a staging environment is

A project has a production environment, and optionally a staging environment. Each is one running copy of the website or application.

Each environment runs under its own account, so staging has:

  • Its own files, in its own home directory.
  • Its own database, when the template uses one.
  • Its own domain.
  • Its own SSH and SFTP login.
  • Its own processes running its code.

Nothing in staging can reach production's files, and a crash in staging does not take production down.

They do share the same server. A staging job heavy enough to load that server can still slow production down, so treat a big import or reindex on staging the way you would treat one on production.

Creating a staging environment

Turn on 'Create Staging Environment' when you create the project, and fill in the 'Staging Domain'. See Creating a project.

Adding staging to a project that does not have one is not self-service. Contact Cyberfusion support.

Switching between environments

A 'Production' / 'Staging' switch sits in the left sidebar of the project page. Most sidebar items follow it, so 'Crons', 'Databases', 'SFTP & SSH' and the rest always show the selected environment.

Check which side the switch is on before you change anything.

Keeping staging private

A staging environment is reachable on the public internet, and search engines index it if they find it. Two ways to stop that:

Cloning staging to production

Before you clone

  1. Check that production has a recent backup. See All about backups.
  2. Remember the database does not come along. If the change needs a database migration, run it on production yourself afterwards.
  3. If your deploys already run from Git over SSH, use that instead. Clone is for when staging is where the work happened.

The steps

  1. Open 'Clone'. Core compares the two document roots and shows the differences as two file trees, 'Staging' left and 'Production' right. If nothing differs, it says so.
  2. Check the comparison, then click 'Continue'.
  3. The 'Review clone' step names the exact document root being copied from and to, and states that production files will be overwritten.
  4. Click 'Clone to production' and confirm.

The comparison step exists to catch the common mistake: a file changed directly on production — by a plugin update, or an edit over FTP — that the clone is about to throw away.

Production files that differ are replaced with the staging version.

Search and replace

For WordPress projects, 'Search & Replace' replaces a string throughout the environment's database.

Usual reason: a domain still stored in the database. A WordPress database holds absolute URLs in thousands of rows, so a copy of a site keeps pointing at the domain it came from until you replace it.

Enter the 'Search string' and 'Replace string'. It runs against the environment selected in the sidebar.

Check that switch first. Running a search and replace on production when you meant staging cannot be undone without a restore.

How staging is typically used

  • Client approval — put basic auth in front of staging and hand the client one username and password.
  • Testing theme and plugin updates — storefront breakage after an update is the most common cause of a shop being down, and it shows up on staging just as clearly.
  • A rehearsal for the release, not a deploy mechanism. Keep deploying production from your pipeline.
  • With atomic deploys through a document-root symlink — deploy to both environments from the pipeline and use staging as the last check before promoting. See the automatic FPM pool reload.