What changed
Pantheon is replacing the Valhalla shared filesystem it built for horizontally scaled PHP sites with a filesystem backed by Google Cloud Storage FUSE. New sites began moving in August; migrations of existing sites began September 1, 2026. Pantheon lists Free sites first, followed by Basic on October 5, Performance on November 16 and Elite on November 30. The company says the new filesystem improves backup and restore performance and reliability, and that no customer action is required.
Why it matters
For hosted WordPress and Drupal sites, uploaded media and other CMS-managed files sit on the shared storage layer even when application containers scale horizontally. Changing that layer alters a core piece of runtime architecture beneath existing sites. Pantheon says the migration is transparent, but teams with unusual filesystem assumptions, large media libraries, custom backup workflows or integrations that depend on file timing should treat the rollout as an infrastructure event worth observing rather than a cosmetic platform update.
Valhalla is being replaced beneath existing sites
Pantheon created Valhalla to make WordPress and Drupal uploaded files behave like a shared local filesystem across horizontally scaled containers. The company now says Cloud Storage FUSE has surpassed that design for its needs and is becoming the replacement storage layer.
The existing-site rollout starts with Free plans
New sites began receiving the new filesystem in August. Existing sites entered the migration phase on September 1, starting with Free sites. Pantheon plans later waves for Basic, Performance and Elite tiers through November.
Pantheon says the migration is automatic
The release notes do not ask customers to copy files or change application code. Pantheon says no additional action is required and exposes a Filesystem Generation value in Site Details so operators can see whether a site has moved.
The practical risk is hidden filesystem assumptions
Most standard WordPress and Drupal sites should not need changes, but custom code, media-processing jobs, backup tooling and integrations sometimes rely on subtle filesystem behavior. Teams running those patterns should verify them after migration, especially around write visibility, backup/restore behavior and large file sets.