Pantheon release notes

Pantheon Search now supports Apache Solr 9.10.1 for Drupal 7, 10, and 11 sites, with improved security defaults, the unified highlighter, and performance enhancements. See the major changes in Solr 9 for details.

How to get Solr 9

Drupal 10 and 11

Solr 9 support is available through Search API Pantheon version 8.5.0.

For detailed setup instructions, see the Solr for Drupal 10/11 guide.

Drupal 7

Solr 9 support is available through the Pantheon Drupal 7 upstream version 7.105.1.

For detailed setup instructions, see the Solr for Drupal 7 guide.

Solr 3 and Solr 8 removal timeline

The previously announced removal schedule still holds:

• Solr 3 will be removed on February 9, 2027. Drupal sites using Solr 3 must migrate to Solr 9 before this date. WordPress sites using Solr 3 through the Solr Power plugin should consider switching to Elasticsearch.
• Solr 8 will be removed on July 11, 2027. Drupal 10 and 11 sites using Solr 8 should migrate to Solr 9 before this date.

Feedback

Report issues or provide feedback in the drupal.org issue queue for Drupal 10/11, or through Pantheon Support for Drupal 7.

PHP versions 8.4.22 and 8.5.7 are now available on the platform. PHP 8.5.7 includes security fixes (CVE-2026-44927, CVE-2026-44928) along with bug fixes. PHP 8.4.22 is a maintenance release with bug fixes and stability improvements. Updates will be applied automatically over the next few days, so no manual action is required.

Pantheon's external repository integration now supports GitLab in addition to GitHub. You can connect a GitLab repository to a Pantheon site via Terminus using --vcs-provider=gitlab, with support for both GitLab.com and self-hosted GitLab instances.

What's new

• GitLab repository support — Create Pantheon sites connected to GitLab repositories using terminus site:create --vcs-provider=gitlab
• Self-hosted GitLab — Connect sites to self-hosted GitLab instances using the --vcs-host=<your-gitlab-domain> flag
• Token-based authentication — GitLab uses legacy personal access tokens or group access tokens rather than OAuth. Tokens require api and write_repository scopes. Group access tokens also require a Maintainer role or higher to create repositories and manage webhooks.

For full setup instructions, see the external repositories documentation.

The Security tab is now available for Next.js sites in the Site Dashboard. You can password protect any environment with basic authentication, the same way you can for Drupal and WordPress sites. When an environment is locked, visitors are prompted for a username and password before the site is served.

To lock an environment, select the environment, open the Security tab, choose Locked, provide a username and password, and save. To make it public again, choose Public. For step-by-step instructions, see Lock Environments with the Dashboard Security Tool.

Run a new build after changing lock status

On Next.js sites, locking or unlocking an environment does not take effect until a new build is deployed to that environment. After you change the lock or unlock status in the Security tab, trigger a new build using the Rebuild option (available in the Site Dashboard and through Terminus) or by pushing a new commit to the connected branch, so the change is applied to the running site.

For more details about Next.js on Pantheon, see our Next.js documentation.

Terminus 4.3.2 is now available. This release adds GitLab support for VCS commands, a new --custom-domains flag for drush:aliases, and custom build path support.

Key improvements in this release

• GitLab support for VCS commands: vcs:connection:add and site:create now support GitLab as a VCS provider, enabling customers using GitLab to manage repository connections via Terminus. (#2873)
• --custom-domains flag for drush:aliases: A new flag allows including custom domains in generated Drush alias files. (#2779)
• Custom build path support: You can now pass a custom build path when creating sites. (#2851)

How to upgrade to Terminus 4.3.2

If you use Homebrew (macOS-only) to manage your Terminus installation, you should upgrade using:

If you installed Terminus directly from the .phar file, you should upgrade using the self:update command:

For more information about this release, visit the GitHub release page.

If you have questions or concerns around Terminus, please use the Terminus issue queue.

Pantheon now supports Bun as a package manager for Next.js sites, alongside npm, yarn, and pnpm. We've also added support for Node.js 26 (LTS).

Bun support

To use Bun, add a bun.lock file to your repository. Pantheon automatically detects the lock file and uses Bun to install your dependencies during the build process.

You can specify a Bun version in the engines.bun or packageManager field of your package.json. If no version is specified, Pantheon defaults to the latest stable release.

Node.js 26 support

Node.js 26 is now available as an LTS runtime for Next.js sites. Set the engines.node field in your package.json to use it:

Node.js 20 removed

Node.js 20 has reached end of life and is no longer available as a runtime. Sites using Node.js 20 must upgrade to Node.js 22 or later.

For more details about Next.js on Pantheon, see our Next.js documentation.

Terminus 4.3.1 is now available. This patch release makes the --org option required for site:create, enforcing the requirement that all new sites belong to an organization.

Key improvements in this release

• --org now required for site:create: The --org option is no longer optional when creating sites. Previously a warning was displayed; now omitting --org will return an error with a clear message. This aligns Terminus with the platform requirement that all sites belong to an organization. (#2845)

How to upgrade to Terminus 4.3.1

If you use Homebrew (macOS-only) to manage your Terminus installation, you should upgrade using:

If you installed Terminus directly from the .phar file, you should upgrade using the self:update command:

For more information about this release, visit the GitHub release page.

If you have questions or concerns around Terminus, please use the Terminus issue queue.

We've released the final update to the build-tools-ci Docker image. We will not publish any further updates, bug fixes, or security patches to the following tags:

• pantheonpublic/build-tools-ci:9.x-php8.2
• pantheonpublic/build-tools-ci:9.x-php8.3
• pantheonpublic/build-tools-ci:9.x-php8.4
• quay.io/pantheon-public/build-tools-ci:9.x-php8.2
• quay.io/pantheon-public/build-tools-ci:9.x-php8.3
• quay.io/pantheon-public/build-tools-ci:9.x-php8.4

Background

These base images were created at a time when CI providers recommend using customized Docker images to speed up execution and reduce the need for replicating boilerplate configration. It has since become more common to run CI jobs on standard base images for speed and the reduction in boilerplate code comes from reusable GitHub Actions or CircleCI Orbs.

Recommended migration

Use a standard base image from your CI provider and install the Pantheon tools you need during the CI run. Standard images are better cached by CI runners, so your pipelines will perform better overall than with a custom image.

Learn more about Pantheon's reusable GitHub Actions and CircleCI Orb.

Action required

If you use any of the build-tools-ci image tags listed above, migrate to a standard base image before the included dependencies become outdated.