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 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 straight 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, 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. In theory it’s simple: 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. I first saw this kind of workflow 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 uses 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"
fiSo, what’s the point?
The main takeaway is to use 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 run on 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.
