ACF Pro as a Composer dependency (without committing your license key)


Hey y’all,
I found this while looking for a way to install ACF Pro without committing our license key to the Git repo in composer.json:

Below is a VERY ROUGH SKETCH for how to make this work with Trellis without committing your unencrypted ACF Pro key to your Git repo. I wanted to get this up for others to see and comment on:

Adapting this for Trellis:
In trellis/group_vars/[environment]/vault, add acf_pro_key:

# Documentation:
vault_mysql_root_password: devpw

# Variables to accompany `group_vars/development/wordpress_sites.yml`
# Note: the site name (``) must match up with the site name in the above file.
    admin_password: admin
      acf_pro_key: YOUR_KEY_HERE
      db_password: example_dbpassword

You’ll need to reprovision your environment to regenerate the .env file where your key is put.

VirtualBox. Trellis. Ansible. Bedrock All Set. Now what

Thanks for sharing this. But it looks like you can skip the 2nd step of editing wordpress_sites.yml. You can just include that key in the env part in the vault file:

# Documentation:
vault_mysql_root_password: devpw

# Variables to accompany `group_vars/development/wordpress_sites.yml`
# Note: the site name (``) must match up with the site name in the above file.
    admin_password: admin
      acf_pro_key: YOUR_KEY_HERE
      db_password: example_dbpassword

The env dictionaries get merged together.


Aha! Thank you! I’ve updated the first post to reflect this.

Hopefully others will find this helpful.


I don’t get errors but I don’t see ACF after provision and deploy, either… is this how composer.json should look?

      "type": "package",
      "package": {
        "name": "advanced-custom-fields/advanced-custom-fields-pro",
        "version": "5.3.8",
        "type": "wordpress-plugin",
        "dist": {
          "type": "zip",
          "url": ""
        "require": {
          "philippbaschke/acf-pro-installer": "^1.0",
          "composer/installers": "^1.0"
      "type": "composer",
      "url": ""
  "require": {
    "php": ">=5.5",
    "composer/installers": "~1.0.12",
    "vlucas/phpdotenv": "^2.0.1",
    "johnpbloch/wordpress": "4.5.2",
    "oscarotero/env": "^1.0",
    "roots/wp-password-bcrypt": "1.0.0",
    "wpackagist-plugin/flamingo": "dev-trunk",
    "wpackagist-plugin/contact-form-7": "dev-trunk",
    "wpackagist-plugin/autodescription": "~2.",
    "wpackagist-plugin/google-sitemap-generator": "~4.",
    "wpackagist-plugin/wordfence": "dev-trunk",
    "wpackagist-plugin/wp-smushit": "dev-trunk",
    "wpackagist-plugin/akismet": "dev-trunk",
    "advanced-custom-fields/advanced-custom-fields-pro": "5.3.8"


So I …

  • Ran composer update locally
  • Tried adding another random plugin to composer.json
  • Pushed it to GitHub
  • Deployed and provisioned a few times

…in no particular order, and it worked. Kinda wish I knew which order did the thing I wanted it to.


GitHub was having problems all day today. I wonder if you got caught in a coincidence.


Anyone else having problems with ACF+Composer again? Getting trying to update.

Problem 1 - The requested package advanced-custom-fields/advanced-custom-fields-pro dev-trunk exists as advanced-custom-fields/advanced-custom-fields-pro[5.3.8] but these are rejected by your constraint.


It’s an issue with the plugin. Likely related to this bug. Which was “fixed”, but now there is a problem with pulling version 5.3.10 - I submitted an issue about this here


Don’t use the ACF Pro Installer Composer Plugin, too unpredictable. Instead use the Trellis deploy-hook:

- name: Copy ACF Pro
    src: "{{ project.local_path }}/web/app/plugins/advanced-custom-fields-pro"
    dest: "{{ deploy_helper.new_release_path }}/web/app/plugins/"
    group: no
    owner: no
    rsync_opts: --chmod=Du=rwx,--chmod=Dg=rx,--chmod=Do=rx,--chmod=Fu=rw,--chmod=Fg=r,--chmod=Fo=r


The plugin makes ACF a composer dependency, which for me, is much better and easier to maintain. The guy behind the plugin is actually really good and really responsive. Also, you can just fork it and adapt it to your needs if you feel like it’s not adapting to your specific project.
Either way, managing your plugins from composer is always preferable and gives you more control over your project.


I also had some issues with installing the right version, as well as installing the right version of another private plugin that isn’t on I think there might be a composer related issue, but between the fixed bugs that @jamiechong mentioned and following the usage instructions in the repo, I got ACF Pro working perfectly through Composer on version 5.3.10. @Nicolo_Sacchi - try again now that the ACF Pro Installer seems to be fixed!


Thank you @MWDelaney for promoting acf-pro-installer and thank you @Nicolo_Sacchi for your kind words. :blush:

If anyone has questions or troubles feel free to ask me here. I’ll try to help as good as possible :sweat_smile: :wrench: :desktop:.


Hi Phillipp,

Thanks for the plugin! Just wondering how you would go about including the ACF key in the env variable. It seems like I can get it work in multiple ways… just wondering which is the best.

Thanks :slight_smile:


I am glad you like the plugin. Thank you! :slight_smile:

If you use Trellis you probably should go with the approach from @MWDelaney and @swalkinshaw (see above).

I usually use a .env file for development. This way you just have to set the key once and can then forget about it. I deploy most of my projects with shipit, which is a node.js alternative to capistrano. I wrote a simple shipit routine that copies my local .env file to the local temporary deploy folder, runs composer install and then deletes the .env file. That works but I don’t feel it is the most elegant solution :wink:

If you use a CI Service like Travis CI you can usually specify environment variables in your build settings (e.g. see Travis CI Docs). I would prefer that compared to my approach if I would use such a service.

I hope this helps a little. If you have more questions, feel free to ask.

Maybe someone else can also share their best practices or tell me if some of my ideas make no sense. Thank you! :blush:


Hey @philippbaschke, so it turns out that Beaver Builder offers a composer option very similar to ACF’s, and with just as much danger of committing your license key to GitHub.

The instructions to install via composer are here:

Would you have any interest in setting up a similar tool to the one you built for ACF for this plugin as well?


Hey @MWDelaney. I though about creating a more general fork of acf-pro-installer to support every plugin/theme that has a similar way of installing via composer. And since you are not the first to ask about this, I will try to do that as soon as I have time. But as you can tell from the speed of my answer that will probably not happen in the very very near future. :blush:

If any of you knows about more plugins that you want supported, just let me know. It helps to have more examples when coming up with a general solution.


I’m trying to use the acf-pro-installer, and it has succeeded locally, but when I try to push to production, I keep getting an error stating that

[PhilippBaschke\\ACFProInstaller\\Exceptions\\MissingKeyException]                                      ", "  Could not find a key for ACF PRO. Please make it available via the environment variable ACF_PRO_KEY

I added the key to .env file in the bedrock folder, which now looks like this


As I said, this worked locally and downloaded ACF PRO on my machine, but do I need to create a new .env file specific to production or something?


Your staging and production environments need to have a copy of the ACF key in their .env file. I THINK this is regenerated each time you deploy, so if you add the key to the appropriate vault.yml (just like you did for development ) and redeploy it should work.

Can a Roots team member confirm this? When does .env get regenerated?


Thank you MWDelaney, I did try adding the key to the dev/production vault.yml, and then re-provisioning but it didn’t work.

I’m also concerned adding it to those files because then the key would be publicly available on the projects github repo.


The Trellis documentation covers encrypting those Vault files, and also recommends using a private repo in addition to encryption. But ultimately yes you’re committing the key, even if it’s encrypted, to your repo.

The top post in this thread indicates that the key will still be committed in an encrypted fashion, just like your (potentially more damaging!) database and user passwords.