Automating WordPress Updates with Bedrock and Dependabot

I was talking to a client last week who was getting nervous. They manage a handful of WordPress sites built with Bedrock, and the manual update process was starting to feel like a liability. Every couple of weeks, it was the same routine: SSH in, run `composer update`, cross your fingers, test, and deploy. It’s not hard, but it’s easy to forget. And a forgotten update is how sites get hacked. They wanted a hands-off solution for automating WordPress updates, something that would just handle it without them thinking about it.

This is a super common problem with a Composer-based workflow. Bedrock disables the default WordPress auto-updater because it hands over all dependency management to Composer. That’s a good thing for stability, but it puts the update burden squarely on your shoulders. The solution is to automate the Composer part of the equation.

Building a True “Set It and Forget It” Update Workflow

To make this work, you need a few tools in your belt: your code on GitHub, a service to check for updates, and a CI/CD pipeline to handle the deployment. We’ll use Dependabot, which is now free and integrated into GitHub, to watch for outdated dependencies. When it finds one, it’ll open a pull request. Then, CircleCI will pick up that PR, run a quick check, and merge it, which triggers a final deployment. Simple. Or so I thought.

My first run at this was a bit of a head-scratcher. I had Dependabot configured to open a PR and auto-merge it once created. The PR opened, everything looked good, but it just sat there. No merge. Nothing. Here’s the kicker: Dependabot is smart enough not to merge something blindly. It needs a “passing” status check from a CI tool before it will proceed. It’s a safety feature to prevent shipping broken code, but it’s not immediately obvious why your auto-merge isn’t working. Total nightmare for a minute there.

The fix was to add a simple `test` workflow to our CircleCI configuration. It doesn’t need to be complicated; for many sites, just installing the dependencies to ensure the lock file is valid is enough. This gives Dependabot the green light it needs. This process builds on a great concept I saw over at carlalexander.ca, but I’ve adapted it for my typical client setup.

version: 2
jobs:
  test:
    docker:
      - image: circleci/php:7.3
    steps:
      - checkout
      - run:
          name: Install dependencies
          command: composer install
      - run:
          name: Run tests
          command: composer test # Bedrock includes a basic test command
  deploy:
    docker:
      - image: circleci/php:7.3
    steps:
      - checkout
      - run:
          name: Install and run deployer
          command: |
            composer global require deployer/deployer:^6.4
            ~/.composer/vendor/bin/dep deploy

workflows:
  version: 2
  test_and_deploy:
    jobs:
      - test
      - deploy:
          requires:
            - test
          filters:
            branches:
              only:
                - master

So, What’s the Point of All This?

Setting this up isn’t about being lazy; it’s about being disciplined and secure. It takes human error out of the single most important security task you have as a site owner. Once it’s running, you have a reliable system that ensures your site gets patched the moment an update is available, not whenever you remember to log in.

• Consistency: Updates are checked and applied on a schedule, not randomly.
• Security: It closes the window between a vulnerability announcement and your site getting patched.
• Peace of Mind: You can trust that the core of your site is always up-to-date. Period.

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