Auto update to minor versions and security releases

Is it possible to set the auto updates just to security releases? But keep composer.

You would need to have a way of getting the changes applied/committed to your git repository

That could complicate things a bit, the company where I work has a lot of clients. I’m rooting for Bedrock + Trellis combo, but we had our share of hacked WP sites so it’s now a bit of an issue, especially if we have to update all the composer files for each minor version that comes out.

Do you know the vector used by the attackers in general? Trellis has some pretty good default security built in.

Composer allows for pretty granular package constraints; for any packages that use SemVer, it’s got what you need to restrict packages to minor/security releases. See

Between using that in your composer.json and writing a small script to run composer update on the server, that should cover your bases.

1 Like

Just have to make sure you don’t accidentally deploy some other change without running composer update on your dev copy. You could overwrite your security updates pretty easily if you’re not careful.


So I could put this in composer.json:
“vendor/package”: "1.0.*"
And do a composer update with cron once in a while? This will be lovely jubbly if it pans out.

Just did it on one site, and got this on composer update:

Two packages cannot share the same directory!

The solution in my case was to rename/delete vendor directory, but this might help in other scenarios:

This might need more testing with uptime monitoring before it becomes part of the standard release routine.
But nice recipe in any case.

Check out the info on the Composer site about version constraints, and specifically Next Significant Release Operators

What would be the best way to trigger the composer update job? I tried the plugin route, but there’s problem with permissions and file usage, because /wp folder is in use while composer tries to update it.
I tried the crontab route, but it seems that cron has some beef with /current symlink in the path to php exec script which has to be under /current to get to composer.json folder through ABSPATH.

Any solution updates to this problem?

If you’re using Bedrock with Trellis, do composer update locally, commit, and deploy.

If you’re using Bedrock on it’s own, it’s probably not a good idea automate this. Even minor versions of plugins and WP can break things. But if you’re hell-bent on doing it, I’d assume a cron that runs composer update would do it…I’m not well versed on cron but see this stackoverflow answer for a potential solution to the symlink issue @Ivan_Svaljek mentioned.

Do you ever have worries about security issues? Missing an update some way or another?

Generally no - I subscribe to a few newsletters that are good about highlighting any security issues w/ WP or a WP Plugin, and then I’ll research whether it warrants action including possible updates.

I’d recommend subscribing to The WhiP by WPMU DEV - the landing page says it’s for members, but you can just sign up for a free trial account, sign up for the newsletter, and you’ll still get it when you cancel your trial.

Then if I need to do an update, it’s logged in version control, which is useful for a variety of reasons.


It would be possible to auto-update on production and keep the repository versions as last well known working defaults from which one can recover - or at least update upwards in case of manual update.

Suitable would be a CI cycle, where new plugin/theme updates are automatically introduced to composer project files, built (docker container/VM spun up with the plugin/theme updates applied) and after automatic testing (e.g. headless browser/selenium, REST API, …) and/or manual review and approval (e.g. Jenkins approval plugin or something like Gerrit) , merged to master (stable/working) deemed non-breaking and automatically deployed (e.g. to a Trellis production server).

Edit: Found a blog post about updating WordPress plugins with CI workflow,
I also posted a comment on the page linking to WordPress Bedrock because the author looks for a way to manage WordPress plugins/themes with composer:


@runofthemill @strarsis Thank you both for the amazing replies. I think for simplicity I’ll stick to runofthemill’s suggestion for now. When I am comfortable, I will consider Travis CI.

1 Like

Would be seriously interested in an article or guide on how to pull this off.

Related feature request for composer: