Setting up a Drupal staging environment with Pantheon
A staging environment gives a Drupal team a safe place to test code, configuration, content changes, and updates before they reach the public website. Pantheon provides a practical workflow for this through separate Dev, Test, and Live environments, with optional Multidev environments for feature branches and parallel work.
For an Australian organisation, this separation is particularly useful when a website serves customers across several time zones or supports busy publishing schedules. A council site in Brisbane, a university in Melbourne, or an ecommerce business in Sydney may need updates checked carefully before a campaign, enrolment period, or public holiday.
Pantheon handles hosting infrastructure, version control, deployment workflows, and environment management, while Drupal still requires careful configuration. The best results come from treating staging as a realistic copy of production rather than as a spare installation that is rarely updated.
Why a separate Drupal staging site matters
Testing directly on a Live Drupal site creates unnecessary risk. A module update can alter database schemas, a theme change can affect responsive layouts, and a configuration import can disable an essential view or content type. Even a seemingly small CSS change can cause problems for users on mobile devices or slower NBN connections.
Pantheon’s standard workflow separates development from public traffic. The Dev environment is generally used for active coding, Test acts as a staging environment, and Live serves visitors. Multidev branches can provide additional isolated environments for larger features, agency work, or experiments that should not interfere with the main Dev environment.
Staging should contain representative content and settings without exposing confidential information. Production database copies may include customer names, contact submissions, or staff details, so Australian organisations should consider the Privacy Act 1988, internal data-handling policies, and any contractual requirements before copying information into a lower environment.
Prepare the Pantheon workspace
Start by creating or selecting the Drupal site in Pantheon and connecting the correct code repository. A Composer-managed Drupal project should include composer.json, composer.lock, the Drupal core requirement, contributed modules, themes, and any required libraries. Commit the lock file so that Dev, Test, and Live install the same dependency versions.
The Pantheon dashboard provides the environment URLs, connection information, backups, and deployment controls. Install Terminus if command-line access is useful, then authenticate it with a machine token or personal token. Typical commands include terminus site:list, terminus env:list, and terminus drush <site>.<env> -- status.
Before making changes, confirm that the team understands which environment is authoritative for each type of work. Code should normally move through Git. Configuration should be exported and imported deliberately. Content is usually created in Live and pulled down to Dev or Test when a realistic content snapshot is required.
A site serving audiences in Perth and Sydney may also need time-zone checks. Drupal’s site time zone, PHP date handling, scheduled jobs, and editorial deadlines should be tested with the business’s actual operating hours rather than assuming that server time matches local time.
Create and configure Multidev environments
Multidev environments are useful when several branches need to be reviewed at once. A developer might create a branch called feature-search-redesign, push it to Pantheon, and create a matching Multidev environment. The resulting URL can be shared with a product owner, client, or content editor without changing the main Dev site.
A common workflow uses Git locally:
git checkout -b feature-search-redesign
git add .
git commit -m "Improve search results layout"
git push origin feature-search-redesign
After the branch is available in Pantheon, create the Multidev environment from the dashboard or Terminus. The environment receives its own code and database, but it should still be treated as temporary. Old branches can consume storage and create confusion, particularly when a Melbourne agency is managing several client sites from one Pantheon organisation.
Each Multidev environment should have a clear purpose and an owner. Add a short README or issue reference explaining what is being tested, which database snapshot was used, and whether the branch includes configuration changes. Do not let a review environment become an unofficial production site with unique content that nobody knows how to preserve.
Move code, database, and files safely
Pantheon’s deployment model makes code movement relatively straightforward, but database and file movement require more care. Code is committed and pushed through Git, while database and uploaded files can be cloned between environments using the dashboard or Terminus. Take a backup before replacing data in any environment.
The following comparison helps define the role of each environment:
| Environment | Main purpose | Typical data source | Deployment direction | Public exposure |
|---|---|---|---|---|
| Dev | Active development and debugging | Fresh or sanitised database copy | Git branch to Dev | Restricted or temporary |
| Multidev | Isolated feature or client review | Dev or selected snapshot | Feature branch to Multidev | Temporary URL |
| Test | Release candidate and acceptance testing | Copy from Live or controlled test data | Dev to Test | Limited review access |
| Live | Public website and production content | Authoritative production data | Test to Live | Public |
When pulling a Live database into Dev or Test, check whether personal data must be removed first. Contact form submissions, user accounts, order records, and unpublished editorial notes should not automatically be distributed to every developer. Database sanitisation can be scripted with Drush, database queries, or a deployment process designed for the site.
Files need a separate review because Drupal’s public files directory can contain documents, images, and generated styles. Private files must remain protected, and file permissions should be checked after synchronisation. If the site uses a CDN or image optimisation service, disable or isolate production integrations in staging so tests do not generate unnecessary costs.
Keep configuration and secrets under control
Drupal configuration management is central to a reliable Pantheon workflow. Export configuration from the environment where a change was made, commit the resulting YAML files, and import them into the next environment. This makes changes visible in Git and reduces the chance of manually reproducing settings.
A typical local workflow may look like this:
drush cex -y
git add config/sync
git commit -m "Update Drupal site configuration"
git push origin feature-search-redesign
After code reaches the target environment, import configuration with Drush or the Pantheon dashboard. Review the differences before running the import. A configuration change that removes a field, alters a text format, or changes permissions can affect existing content and editorial workflows.
Environment-specific values should not be committed as ordinary configuration. API keys, SMTP credentials, payment settings, and private service URLs belong in protected environment variables or Pantheon secrets. Use environment-aware settings in settings.php or settings.local.php so that staging uses sandbox services and Live uses production services.
This is especially important for Australian websites connected to local payment gateways, email providers, CRM platforms, or government integrations. A staging checkout must never charge a real card, and a test form should not send messages to a live customer service queue. The same separation applies to analytics, advertising pixels, SMS services, and webhook endpoints.
Test the release before publishing
A useful staging test follows the way real people use the site. Check anonymous and authenticated pages, search, forms, navigation, responsive layouts, accessibility, caching, and error handling. Test the most important user journeys first, such as finding a service, submitting an enquiry, registering for an event, or purchasing a product.
Review content editing as well as front-end output. Editors should be able to create, revise, moderate, schedule, and publish content with the expected permissions. If the organisation uses a workflow spanning Canberra, Adelaide, and regional offices, test approvals with the correct roles and time zones.
Performance checks should include cache behaviour, image sizes, database queries, and pages with large listings. Pantheon’s metrics can help identify slow requests, while browser developer tools reveal JavaScript errors and blocked assets. Confirm that robots directives, canonical URLs, XML sitemaps, and social metadata are appropriate for staging; a test site should generally discourage indexing.
Custom modules deserve their own test cases. A simple contact form module may involve routing, validation, mail handling, permissions, and configuration. The custom contact form guide can help structure that kind of feature before it is promoted through the Pantheon workflow.
Automated checks can run before deployment. Depending on the project, these may include PHPUnit tests, Drupal coding standards, PHPStan analysis, JavaScript linting, and Composer validation. A release candidate is much safer when failures are detected before a content editor begins acceptance testing.
Deploy to Live with a controlled process
Before deploying, create a backup of Live and record the release commit, configuration changes, database updates, and rollback approach. Confirm that cron, queues, caches, search indexing, email delivery, and third-party services are ready. If a migration or update changes the database schema, allow enough time for it to complete without interrupting normal traffic.
Pantheon deployments commonly promote code from Dev to Test and then from Test to Live. Keep the promotion sequence consistent so that the Live environment receives the same tested code. Avoid making emergency edits directly in Live unless there is a clear incident process, because untracked changes are difficult to reproduce and may be overwritten later.
After deployment, perform a short smoke test immediately. Open the home page, test a key form, log in as an editor, inspect a representative content page, and review the browser console. Clear caches only when required, since indiscriminate cache clearing can create a temporary performance impact on a busy site.
Practical release habits
- Take a named backup before database updates, configuration imports, and major module upgrades.
- Use separate API credentials and payment accounts for Dev, Test, and Live.
- Record the release commit and configuration change in the project issue or deployment log.
- Restrict staging access with suitable authentication and prevent search engine indexing.
- Remove obsolete Multidev environments and old branches after feature review is complete.
Pantheon’s workflow supports rollback through previous code, database backups, and documented deployment steps, but recovery is strongest when the team has practised it. A staging environment should therefore be part of routine maintenance: refresh representative data, apply Drupal security updates, test scheduled jobs, review logs, and keep the process familiar before a high-pressure release such as an Australian EOFY campaign or a major public announcement.