Managed Updates is a service offered by our Professional Services team. We help keep your site updated so you can focus on what's important. Learn more about Managed Updates in the Managing Updates for WordPress and Drupal webinar
With Pantheon Managed Updates (PMU), you get:
- CMS core updates
- Module / plugin updates
- Visual Regression Testing (VRT)
To make Managed Updates available to customers of all sizes and needs, Pantheon offers three versions: Premium, Lite, and Portfolio Upstreams.
Managed Updates Premium is for standalone sites and includes support for custom workflows, testing, and CI/build processes. Premium also offers personalized update issue remediation, and email notifications when updates are scheduled.
Managed Updates Lite is for standard sites on Pantheon, and offers basic CMS and plugin updates (with visual regression testing) on a customizable schedule. It's for WordPress or Drupal 7 sites that use the standard Pantheon WebOps workflow, or Drupal 8 sites using a Composer-build workflow without continuous integration processes (see below for details).
Managed Updates for Portfolio Upstreams provides provides core, plugin, and module updates for customers managing site collections using Custom Upstreams.
- Sites use Pantheon’s update workflow
- Codebase changes are pushed to client's remote repo and then applied to each of the sites
- Build step does not rely on 3rd party sources
- No other special deployment instructions
- Drupal 7 or WordPress 5.4 or above
|Feature||Description||Managed Updates Portfolio Upstreams||Managed Updates Lite||Managed Updates Premium|
|Core, plugin, and module updates||Full code updates from publicly accessible repositories and sources.||✔||✔||✔|
|Regular update detection||Daily scans of official repositories to detect when updates are available.||✔||✔||✔|
|Visual Regression Testing||VRT for every environment through which changes are deployed.||✔||✔||✔|
|Custom deployment scheduling||Adjustable scheduling for the deployment of core, plugin, and module updates.||❌||✔||✔|
|Standalone sites||Maintenance of logically distinct and/or customized sites.||❌||✔||✔|
|Workflow customization||Support for bespoke site update workflows.||❌||❌||✔|
|Remote pull requests to external repositories||Receive pull requests for successful updates that can be accepted at your convenience.||❌||❌||✔|
|Personalized update issue remediation||Expert support for remediating update and deployment issues.||❌||❌||✔|
|Headless site support||Updates for headless and decoupled sites.||❌||❌||✔|
|Composer compatibility support (Drupal 8)||Updates for Composer-built Drupal sites.||N/A||❌||✔|
|Custom build/CI process||Updates for sites using custom CI or build processes.||❌||❌||✔|
|Patched code support||Preserves patched code in applied updates.||Test and Deploy Only||Drupal 7 sites excluded||✔|
|Custom VRT||VRT for authenticated pages or custom DOM elements.||❌||❌||✔|
In order to be supported by Pantheon Managed Updates, Drupal 8 sites should be in a "Composer-clean" state. This requires making sure the site’s codebase meets several criteria.
A Drupal 8 site using Managed Updates must:
have build and deployment handled by Pantheon, not by an external CI/CD service,
not include a
pantheon.upstream.ymlfile in the codebase (unless it’s custom upstream), only
use a nested docroot structure,
be connected to the "Empty drupal8" Pantheon upstream ,
have a code-structure based on the Composer Drops-8 Example project.
Convert your D8 site to the example Composer Drops-8 structure
Clone or download example-drops-8-composer locally. This will be your initial project folder.
.gitfile (if present).
Review the top-level
.gitignorefile. Make sure package installation paths are not ignored (
web/core). Make sure paths to user files are ignored (
Rename the project in the top-level
composer.jsonfile to something matching the site name, for example: “client-org-name/site-name”.
Clone the existing Pantheon site repo to the separate folder.
Copy all of the existing site’s custom modules to
Copy all of the existing site’s custom themes to
Finally, take the
composer.jsonfile from the site’s codebase and add all packages from
require-devsections to the new project’s
composer.json. If there are duplicates, prefer versions from the example project, rather than from site.
Drupal core must be required as "
drupal/core-recommended" package, not "
All Drupal modules should be required by Composer (via
Drupal core, themes, and modules should be locked to the exact versions currently installed on the Live environment. In
composer.json, the "require" section should look like this for Drupal packages:
"drupal/module": "1.2", "drupal/core-recommended": "8.8.0"
"drupal/module": "~1.2", "drupal/module2": ">=1.2", "drupal/core-recommended": "^8.8"
Drush 9 or greater should be required by
Custom modules should be stored in
Custom themes should be stored in
Local patches should be sourced from the
patchesdirectory in the project root.
After removing the
composer installshould run with exit status
Composer-specific files and directories SHOULD NOT be included in the
There should be no
.gitfolders in the
"topfloor/composer-cleanup-vcs-dirs": "^1.0"should be required in the top-level