Skip to main content

Pantheon release notes

Your destination for staying informed about our latest innovations and product updates.
Subscribe to RSS feed

September 18, 2026

Version 1.4.0 of the Pantheon Content Publisher WordPress plugin is now available.

What's new?

New Feature: Smart Components ** You can now embed videos and interactive smart components directly into your posts and pages using the updated Google Docs add-on. #206

Update to 1.4.0 from the WordPress dashboard under Plugins > Installed Plugins, or download it from the WordPress Plugin Repository.

For more details, see the plugin changelog.

September 10, 2026

Starting September 10, 2026, new sites created on Pantheon are provisioned on the next-generation Global CDN, powered by Cloudflare, instead of the legacy Global CDN.

This change applies to newly created sites only. Existing sites are not affected and remain eligible for migration through the normal migration path.

No action is required: the next-generation GCDN is provisioned automatically at site creation.

Advanced Global CDN (AGCDN) customers are not affected by this change. If you have any questions, contact Pantheon Support.

September 10, 2026

Sites on the Next Generation GCDN can now exempt their own trusted automation from bot protection, without contacting support.

Bot protection on the Next Generation GCDN automatically challenges traffic that looks automated. That is the right default for scrapers and attack tools, but it can also challenge automation you rely on: uptime monitors, CI/CD pipelines, feed importers, and custom API clients that are not on the verified bot list.

You can now generate a bot bypass token for your site using Terminus and configure your automation to send it in the x-pantheon-bot-bypass request header. Requests carrying a valid token skip the standard challenge applied to automated traffic; targeted protections, rate limiting, and the managed WAF still apply to every request.

Key details:

  • Tokens are scoped to a single site (all environments) and valid for 6 months. The command returns a current token and a next token that becomes valid 3 months later; both are accepted during the overlap. Send the current token now, switch to the next token on or after its start date, and re-run the command each quarter to pick up the following pair.
  • Treat the token like a credential. Send it only from trusted servers and services, and never expose it in client-side code. If a token is leaked, contact Pantheon support to revoke it; a replacement token becomes available at the start of the following month.
  • Requests without the header are evaluated by bot protection as usual. Requests with an incorrect token are rejected with a 403, so check the header value first if your automation starts failing.

See Bot Bypass Tokens in the Next Generation GCDN guide for setup instructions.

September 3, 2026

Version 0.9.5 of the 'Push to Pantheon' GitHub Action is now available. This release changes how the action handles a push that has no Pantheon environment to deploy to, and corrects the documentation for the target_env and target_env_strategy inputs.

What's new

A Multidev comes from a pull request. A push to any other branch has nothing to derive an environment name from.

In 0.9.4 the action treated that as an error and failed the job, so adding the action to a workflow that runs on every push would fail on a feature branch with no PR. In 0.9.5 the action skips the remaining steps and the job succeeds, and the step log records why the deployment was skipped.

A misconfiguration still fails the job: a target_env value Pantheon will not accept, an unrecognized target_env_strategy, or the branch strategy with no branch to read.

If you want pushes to other branches to deploy, set target_env_strategy: branch to deploy to a Multidev named after the branch, or set target_env explicitly. (#188)

How to upgrade to 0.9.5

Update your workflow file to use 0.9.5:

For more information about this release, see the GitHub release page. To learn more about deploying to Pantheon from GitHub, see GitHub Actions.

If you have questions or concerns about the action, please use the Push to Pantheon issue queue.

September 3, 2026

Version 0.9.4 of the 'Push to Pantheon' GitHub Action is now available. This release fixes a command injection issue in the git_commit_message parameter, adds branch-based Multidev naming, and lets you name the GitHub deployment environment separately for each site.

Action required

Versions 0.9.0 through 0.9.3 interpolated the git_commit_message value into a shell string and evaluated it, so shell metacharacters in the message ran as commands rather than being passed as text. Arbitrary commands, passed through the git_commit_message could run on the GitHub Actions runner, which holds your PANTHEON_MACHINE_TOKEN and PANTHEON_SSH_KEY.

Only workflows that pass text into git_commit_message that someone else could control (e.g. via a PR title or branch name) are affected, and only on a site that has a Live environment and the workflow does not set skip_build_tools: true (e.g. uses the default behavior). The commit message the action generates on its own by default contains no such text, so default configurations are not affected. Versions earlier than 0.9.0 pass the message as a single quoted argument and are also unaffected.

Upgrade to 0.9.4 as soon as possible. If you cannot upgrade immediately, ensure you are not passing untrusted text into git_commit_message.

Reported by @ndewhurst. (#175)

Additional key improvements in this release

  • Branch-based Multidev naming: Set target_env_strategy: branch to name the Multidev after your branch instead of pr-[NUMBER]. Branch names are normalized to satisfy Pantheon's naming rules — lowercased, unusable characters folded to hyphens, and trimmed to 11 characters — and a digit is appended when another branch already holds that name. (#183)
  • Per-site GitHub deployment environments: Set deployment_environment to name the GitHub deployment environment separately from the Pantheon environment. Without it, a branch that deploys to several Pantheon sites reports every deployment under the same name, so only the most recent one stays visible in the pull request timeline. (#182)
  • Multiline commit messages: git_commit_message now accepts multiline values, so you can pass Git trailers such as Source-Commit: to record where a deployment came from. (#175)
  • More reliable Multidev cleanup: delete_old_environments: true now removes environments for closed pull requests that Terminus Build Tools misses. Build Tools stops paginating after roughly 200 pull requests, so environments for older closed pull requests remained until the site reached its Multidev limit. (#174)
  • Multidev limit reported for named environments: The Multidev limit check now runs when you set target_env explicitly. Previously it ran only for automatically derived names, so a deployment to a named environment failed inside Terminus instead of reporting the limit. (#176)

Changes to existing behavior

target_env is now validated against Pantheon's environment naming rules. A value Pantheon would reject (uppercase letters, underscores, more than 11 characters, or a reserved name such as master) now fails immediately with an explanation instead of failing later in Terminus.

How to upgrade to 0.9.4

Update your workflow file to use 0.9.4:

For more information about this release, visit the GitHub release page (https://github.com/pantheon-systems/push-to-pantheon/releases/tag/0.9.4). To learn more about deploying to Pantheon from GitHub, see GitHub Actions (/github-actions).

If you have questions or concerns about the action, please use the 'Push to Pantheon' issue queue (https://github.com/pantheon-systems/push-to-pantheon/issues).

August 31, 2026

You can now delegate site team management with a new site-level role: Site Administrator. It lets you give a trusted person full control over a single site's team - inviting members, changing their roles, and managing Supporting Workspaces - without also granting workspace-level access, or the ability to change billing or site plans.

Previously, there was no role between Workspace Administrator and Site Team Member that could manage a site's team. Organizations had to either grant broad workspace-level admin access just to manage one site, or route every team change through a Workspace Administrator. Site Administrator closes that gap, making it easy for organizations to hand off a site to a lead (or leads) to manage site-level teams.

What's new

  • A new role - Site Administrator appears on the Team tab of the Site Dashboard, visible only to Workspace Administrators and Site Owners — the only roles that can assign it.
  • Delegated team management - Site Administrators can invite and remove Team Members and Developers, change their roles, and add and remove Supporting Workspaces for the site.
  • Everything a Team Member can do - Site Administrators inherit all Team Member permissions, including deploying to Test and Live, managing custom domains, and uploading files.
  • Boundary on billing and deletion - Site Administrators cannot access billing, change the site's plan, transfer ownership, or delete the site.

What you need to do

The Site Administrator role is additive. No existing permissions change. Assign the role when you're ready to delegate site team management.

For the full permissions matrix and step-by-step assignment instructions, see related documentation

August 31, 2026

PHP versions 8.4.25 and 8.5.10 are now available on the platform. These updates include bug fixes and enhancements that improve performance and stability. Updates will be applied automatically over the next few days, so no manual action is required.

August 26, 2026

Pantheon's GitLab support for external repositories is now generally available to everyone directly from the Pantheon Dashboard, alongside GitHub and Pantheon-hosted Git.

What's new

  • Dashboard support — When creating a new site, choose GitLab as your code host right alongside GitHub and Pantheon's integrated Git repository — no Terminus required.
  • Self-hosted GitLab — Connect to GitLab.com or your own self-hosted GitLab instance.
  • Token-based authentication — Authenticate using a personal access token or group access token with api and write_repository scopes.

Where to find it

During site creation, select GitLab on the Where will your code be hosted? screen to connect your repository.

Where will your code be hosted screen showing GitHub, GitLab, and Pantheon options

For full setup instructions, see the related documentation.