Staging site

A staging site is a private copy of a live Drupal site that sits between the development site and production. A release lands on it first, with the same code and configuration it will have live, so the team can see whether the update, deployment or new feature works before visitors do.

How it works in Drupal 11

Staging is a practice, not a Drupal feature: core has no "staging" switch. What core provides are the tools that make a faithful copy possible. The code travels as a commit plus composer.lock. Drupal.org's deployment guide says to run composer install on the server, then the Drupal updates, and, when the release carries configuration, to import it. drush deploy wraps those steps: it runs updatedb, config:import, cache:rebuild, deploy:hook and, on Drupal 11.2 and later, cache:warm.

The data side uses drush sql:sync, which copies a database from a source site to a target. Configuration import works only when the source files carry the same system.site UUID as the target, so a staging site made from a copy of live accepts the same configuration that live will.

Core's own settings comment lists staging next to development as a "secondary installation" where settings.local.php overrides variables, for example to reroute outgoing email.

Example

A security release for Drupal core is out. The team updates core on its development site, commits composer.lock, and deploys the commit to staging. On staging they copy the live database, run drush deploy, and watch the pending updates run against real-sized data. The hook_update_N() documentation warns that an update author cannot know what state the site will be in when the update runs, which is one more reason to try it on a copy first. If the Status report is clean and the key pages work, the same commit goes to production.

Common mistakes

• Letting staging drift from live. A copy with different code, configuration or an old database proves little. Refresh the database and deploy the exact commit that will ship.
• Emailing real customers. A copied live database holds real addresses. Run drush sql:sanitize, which replaces emails with user+%uid@localhost.localdomain by default and randomizes passwords, and reroute outgoing mail.
• Running different software underneath. The Status report on each site lists the PHP and database versions. Compare the two before trusting a result.

For marketing and content teams

Staging is the place to preview a new page template, form or navigation change before launch. Treat what you see as a snapshot: the next copy from live overwrites staging content, and a deployment does not carry staging content to the live site. Ask developers which date the staging data was copied from live, and make final edits on live.

Sources

• Drupal.org: Deploying a Drupal update
• Drupal.org: Updating Drupal core via Composer
• Drush deploy command
• Drush sql:sync command
• Drush sql:sanitize command
• Drupal core 11.4.10: default.settings.php
• Drupal core 11.4.10: module.api.php, hook_update_N()
• Drupal core 11.4.10: SystemConfigSubscriber