Hook into platform workflows and manage advanced site configuration via the
pantheon.yml file. Add it to the root of your site's codebase, and deploy it along with the rest of your code.
Set up existing scripts and write your own with help from our experts. Pantheon delivers custom workshops to help development teams master our platform and improve their internal WebOps.
api_version property in order for
pantheon.yml to be valid:
Protect files and directories inside of your docroot from public web access with
protected_web_paths. For example, the following ensures that a visitor to
https://example.com/example_directory/any_nested_file receives Access Denied (403):
protected_web_paths: - /example.txt - /example_directory
/and are relative to your docroot
HTTPS adds a layer of encryption that prevents others from snooping on or tampering with traffic to your site. HTTP Strict Transport Security (HSTS) instructs browsers to only connect via HTTPS and helps protect websites against protocol downgrade attacks and cookie hijacking.
Pantheon sites (using the default Pantheon upstreams) created or updated on or after September 30 2019 default to enforcing HTTPS via a redirect and a short, 5-minute duration, HSTS header. You can override the default with the
enforce_https directive in a site-specific
enforce_https, review and understand the configuration options and all considerations to avoid unintended consequences.
Use of the HSTS header is defined by the
enforce_https directive, and takes five possible values which are handled by Pantheon as shown below:
|❌||Disabled||Not set by Pantheon||❌||❌|
For example, to set
full+subdomainsshould be treated as a commitment. HSTS headers are cached by browsers for the duration of the max-age period. If your site is unable to serve HTTPS (e.g. by moving to a host that doesn't support HTTPS), visitors will be unable to access your site.
+subdomainsshould only be used if you want to enforce HTTPS for all subdomains, even those not connected to Pantheon.
SSL Labs provides a free, online service that you can use to test your Site's configuration. In order to obtain an A+ rating, a long-duration HSTS header using the
full+subdomains value is required.
transitional+subdomains), before committing to the long-duration HSTS header.
Nest your docroot one level beneath your code repository in a directory named
The name of the nested directory is not configurable.
For more information, see Serving Sites from the Web Subdirectory.
Override the upstream's default PHP version with the
php_version property. PHP version is managed in version control and deployed along with the rest of your site's code to encourage testing before making a change on your Live site.
For example, to override the upstream default value at the site level to PHP 7:
pantheon.ymlas soon as possible to ensure you don't miss the latest recommended PHP version.
drush_version to the top level of the
pantheon.yml file to configure the Drush version used when making calls remotely on Pantheon:
For more information, see Managing Drush Versions on Pantheon.
Pantheon provides a cloud-based filesystem to store user-generated content and other website files. By default, we create a symlink to this filesystem at
/sites/default/files (Drupal) or
/wp-content/uploads (WordPress), but you can change the location with the
This creates a new symlink to the filesystem at the specified location. Note that this setting is only recommended when creating a custom upstream. Instead, consider using a symlink as described in Non-Standard Files Locations.
Complete the following before deploying
Add path to the
private subdirectory of the new path within
pantheon.yml file to define scripts you want executed automatically when a particular workflow is triggered on Pantheon by you or a teammate. For example, you can write a script to post a message to Slack whenever code is pushed to the Site Dashboard.
For more information, see Automate your Workflow with Quicksilver Platform Integration Hooks and check our growing set of Platform Integration guides demonstrating Quicksilver hooks.
pantheon.upstream.yml file to your organization's Custom Upstream to set default configurations for all downstream sites. The same properties described above can be used in this file. In addition, it is also possible to define a
deploy_product Quicksilver hook here; however other Quicksilver workflows are not supported.
This file should only be edited in the Custom Upstream repository where it is defined. Similarly, the Custom Upstream repository should not define a
pantheon.yml file; it should place all configuration settings in the upstream file instead.
When the same configuration value is defined in both files, the value from
pantheon.yml will override the value from
pantheon.upstream.yml at the site-level.
The Platform will automatically reject a commit that includes a
pantheon.yml error. The error message will resemble:
remote: PANTHEON ERROR: remote: remote: Changes to `pantheon.yml` detected, but there was an error while processing it: remote: remote: remote: Version '2' is not a valid pantheon.yml version! remote: Valid versions are: 1
While our parser will reject a
pantheon.yml that is invalid, it won't necessarily give you the exact reason the file is invalid. Please refer to the examples above for exact syntax, or try running the contents of your
pantheon.yml file through a YAML linter.
Changes made to
pantheon.yml file on a branch are not detected when creating the Multidev environment for that branch. As a workaround, make some modification to
pantheon.yml file and re-commit to the Multidev environment. You will then receive a notice indicating configuration changes have been detected and applied to the Multidev environment:
remote: remote: PANTHEON NOTICE: remote: remote: Changes to `pantheon.yml` detected. remote: remote: Successfully applied `pantheon.yml` to the 'new-feature' environment. remote: remote:
Changes made to
pantheon.yml are not detected when deployed as a hotfix. As a workaround, make a modification to your
pantheon.yml file in a development environment (e.g, add a code comment), then deploy up to production using the standard Pantheon workflow.