Chef-Guard protects your Chef server from untested and uncommitted cookbooks

Default Section

Each of the different sections will first show the applicable part of the configuration and then explain every config option separately.

  listenip        =
  listenport      = 8000
  logfile         = /var/log/chef-guard.log
  tempdir         = /var/tmp/chef-guard
  mode            = silent        # Valid options are 'silent', 'permissive' and 'enforced'
  maildomain      =
  mailserver      =
  mailport        = 25
  mailsendby      =               # Leave blank to dynamically use the mailaddress of the user making the API call (preferred)
  mailrecipient   =
  validatechanges = permissive    # Valid options are 'silent', 'permissive' and 'enforced'
  commitchanges   = false
  mailchanges     = true
  searchgit       = true
  publishcookbook = true
  blacklist       =               # This can be multiple regexes divided by a ','
  gitorganization = chef-guard
  gitcookbookorgs = org1, org2    # When using multiple orgs (divided by a ','), the order here determines the lookup order!
  includefcs      =               # This should be the full path to a custom .rb file containing your custom checks
  excludefcs      =               # This can be multiple FC's divided by a ','


The IP address the Chef-Guard server will bind to. As Chef-Guard should always run on your Chef Server, the default of makes the most sense and doesn’t require any additional configuration.


The port the Chef-Guard server will listen on. The default of 8000 makes the most sense as this value doesn’t require any additional configuration.


The logfile Chef-Guard will use to write all log events to.


In order to run the tests (e.g. Foodcritic, Rubocop) the cookbook files need to be on disk. The temp dir is used to stage the files of cookbooks that are being tested.


This determines the mode Chef-Guard operates in. In silent mode it will only do monitoring and auditing. When changing to permissive mode, Chef-Guard will also do validations and tests but in this mode you can bypass failed tests by using --force while uploading a cookbook. When you set Chef-Guard to operate in enforced mode there is no more escaping or bypassing possible. All validations and tests must be green in order for a change or cookbook upload to succeed. Please see (among other sections) the Cookbook Upload section for more details.


This domain is used to set the sending mail domain. Settings this to a correct value may help prevent mail from Chef-Guard being treated as spam. In addition the domain is also used to convert Chef usernames to mail addresses (by simply prepending the mail domain to the username).


The server Chef-Guard will use to send mail.


The port Chef-Guard will connect to when connecting to the mail server.


The mail address used as reply address when sending any mail.


A mail(list) address used to send all configuration changes to.


This configures the behavior of the change validation workflow. Silent mode will prevent validating the changes all together. Enforced mode on the other hand requires the validation to be succesfull (e.g. your cookbook constraints should all be met). So the mode in between is permissive. In this mode your changes are saved even when there are constraints that are not met, but next to saving the change it will also give you an error message so you know what still needs to be fixed. So this is a very good mode to use when starting with Chef-Guard.


A configuration option to enable or disable commiting changes to Github.


A configuration option to enable or disable sending changes by mail.


A configuration option to enable or disable searching GitHub/GitLab for source cookbooks.


A Configuration option to enable or disable the automatic uploading of cookbook to a private Supermarket.


A comma separated list of regexes. Cookbooks matching one of the regexps will not be uploaded to the Supermarket, even when publishcookbooks = true.


The GitHub organization or GitLap group Chef-Guard uses to commit all config info into. When using Open Source Chef 11 a repo/project called config needs to be created in this organization/group. When using Enterprise Chef 11 or Chef 12, you need to create a repo/project for every Chef Organization you have configured to be monitored using Chef-Guard.


A comma separated list of GitHub organizations and GitLab groups that Chef-Guard will use to search for source cookbooks.


A (full) path to a ruby file containing custom Foodcritic tests. When a file with custom checks is supplied, these will be executed in addition to the default Foodcritic tests.


A comma separated list of Foodcritic tests you would like to exclude (e.g. FC001, FC0031)