Skip to main content

Pantheon release notes

Your destination for staying informed about our latest innovations and product updates.
Subscribe to RSS feed
Tools & APIs
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 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.

August 20, 2026

Terminus 4.3.3 is now available. This release adds a rollbackable column to node:builds:list, a new site_admin role, and automatic session token refresh for long-running commands, along with several bug fixes.

Key improvements in this release

  • rollbackable column for node:builds:list: Surfaces which builds are still eligible for rollback, so you can see rollback eligibility without a separate call. (#2903)
  • New site_admin role: Adds support for the site_admin role. (#2878, #2895)
  • Automatic session token refresh: Terminus now automatically refreshes session tokens that expire during long-running command execution, preventing commands from failing partway through. (#2900)
  • Fixed env:code-log crash on eVCS sites: Guarded against null commit labels that previously caused a crash. (#2911)
  • Fixed plugin installs blocked by composer audit: composer audit.block-insecure is now written directly to composer.json, so plugin installs no longer fail when a pinned dependency has an open security advisory. (#2891)

How to upgrade to Terminus 4.3.3

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.

June 29, 2026

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.

June 23, 2026

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.

June 15, 2026

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.

June 15, 2026

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.