How to Use Bedrock with Pantheon Without Losing Your Mind

A client came to us a few weeks back completely frustrated. They were on Pantheon, which is a solid host, but their dev workflow was a mess. Their previous developer had tried to modernize things with Bedrock but gave up, telling them it was impossible on the platform. So they were stuck manually updating plugins via SFTP, with zero dependency management. A total nightmare waiting to happen.

Here’s the deal: using Bedrock with Pantheon isn’t impossible, but it’s not straightforward either. Bedrock is built on Composer, which is how modern PHP projects should be managed. Period. Pantheon, on the other hand, uses a git-based workflow where you push code directly to their servers. The problem? You can’t run `composer install` on their server. That’s the core of the conflict.

My first thought was the “easy” way out. Just commit the `vendor` and `web/wp` directories directly into the git repo. I even spun up a branch to test it. And yeah, it works. But it feels dirty. Your repository gets bloated with files you don’t own, and running updates becomes a high-risk, manual process of deleting folders and recommitting them. Trust me on this, it’s a short-term fix that creates a massive long-term headache.

Automating Bedrock Deployments to Pantheon The Right Way

The professional solution is to stop fighting the platform and automate the build process. You need a Continuous Integration (CI) service like CircleCI or GitHub Actions to act as the middleman. The process is simple in theory: you push your Bedrock project to GitHub, the CI service grabs it, runs `composer install` to build the final site, and then pushes *that* built code to Pantheon. Your main repository stays clean, and deployments are automated and predictable. The initial setup for this kind of workflow was something I first saw over at carlalexander.ca, and it’s a solid approach.

The heavy lifting is done by Pantheon’s command-line tool, Terminus. Your CI script will use it to authenticate and push the code. Here’s a stripped-down version of what a deployment script might look like.

#!/usr/bin/env bash

# Authenticate with Pantheon using a machine token
# This token is stored as a secret in your CI service, NOT in the repo.
terminus auth:login -n --machine-token="$TERMINUS_TOKEN"

# Wake up the dev environment to make sure it's ready
terminus env:wake -n "$TERMINUS_SITE.dev"

# The magic step: Push the built code.
# This command takes your current directory (with vendor/, web/wp, etc.)
# and pushes it to the Pantheon dev environment's git repo.
# It handles the commit process for you.
if [[ $CIRCLE_BRANCH == "master" ]]; then
    terminus build:env:push -n "$TERMINUS_SITE.dev"
fi

So, What’s the Point?

The main takeaway is to embrace a proper build step. Trying to shoehorn a modern tool like Bedrock into a hosting platform that expects a simple `git push` by committing all your dependencies is asking for trouble. It’s an anti-pattern.

• Keep Your Repo Clean: Your git history should track *your* code, not thousands of third-party library files.
• Automate Everything: A CI pipeline makes deployments consistent and removes the chance for human error.
• It’s The Professional Standard: This is how modern web applications are deployed. WordPress shouldn’t be an exception.

Look, this stuff gets complicated fast. If you’re tired of debugging someone else’s mess and just want your site to work with a professional, maintainable workflow, drop my team a line. We’ve probably seen it before.

Setting it up takes a bit of work upfront, but once it’s done, you have a deployment process you can actually rely on. Isn’t that the whole point?