Configuration: Short List of Important Settings

This version of Puppet is not included in Puppet Enterprise. The latest version of PE includes Puppet 4.10. A newer version is available; see the version menu above for details.

Puppet has about 230 settings, all of which are listed in the configuration reference. Most users can ignore about 200 of those.

This page lists the most important ones. (We assume here that you’re okay with default values for things like the port Puppet uses for network traffic.) The link for each setting will go to the long description in the configuration reference.

Why so many settings? There are a lot of settings that are rarely useful but still make sense, but there are also at least a hundred that shouldn’t be configurable at all.

This is basically a historical accident. Due to the way Puppet’s code is arranged, the settings system was always the easiest way to publish global constants that are dynamically initialized on startup. This means a lot of things have crept in there regardless of whether they needed to be configurable.

Getting New Features Early

We’ve added improved behavior to Puppet over the course of the 3.x series, but some of it can’t be enabled by default until a major version boundary, since it changes things that some users might be relying on. But if you know your site won’t be affected, you can enable some of it today.

  • trusted_node_data = true (puppet master/apply only) — This enables the $trusted and $facts hashes, so you can start using them in your own code.
    • And then the $facts variable can be independently disabled with the immutable_node_data setting, but you probably want both.
  • stringify_facts = false (all nodes) — This enables structured facts, allowing facts to contain arrays, hashes, and booleans instead of just strings. This requires Facter 2.0, and none of the core facts use this yet, but enabling it will let you take advantage of structured facts as they are gradually released.
  • ordering = manifest (all nodes) — This causes unrelated resources to be applied in the order they are written, instead of in effectively random order. It allows you to be “lazy” in small classes and write resources in chronological order instead of specifying dependencies. But be careful when writing manifests like this, since it makes it harder to share code with other users.

Possibly Disruptive

Both of these only affect the puppet master (and puppet apply nodes).

  • parser = future (puppet master/apply only) — This enables the future parser, which is explained in more detail on the future parser page. Since it swaps out the entire Puppet language, there’s a good chance you’ll find something in your code it doesn’t like, but it now runs at a decent speed and lets you explore what’s eventually coming in Puppet 4.
  • strict_variables = true (puppet master/apply only) — This makes uninitialized variables cause parse errors, which can help squash difficult bugs by failing early instead of carrying undef values into places that don’t expect them. This one has a strong chance of causing problems when you turn it on, so be wary, but it will eventually improve the general quality of Puppet code.

Settings for Agents (All Nodes)

Roughly in order of importance. Most of these can go in either [main] or [agent], or be specified on the command line.


  • server — The puppet master server to request configurations from. Defaults to puppet; change it if that’s not your server’s name.
    • ca_server and report_server — If you’re using multiple masters, you’ll need to centralize the CA; one of the ways to do this is by configuring ca_server on all agents. See the multiple masters guide for more details. The report_server setting works about the same way, although whether you need to use it depends on how you’re processing reports.
  • certname — The node’s certificate name, and the name it uses when requesting catalogs; defaults to the fully qualified domain name.
    • For best compatibility, you should limit the value of certname to only use letters, numbers, periods, underscores, and dashes. (That is, it should match /\A[a-z0-9._-]+\Z/.)
    • The special value ca is reserved, and can’t be used as the certname for a normal node.
    • (Yes, it’s also possible to re-use certificates/certnames and then set the name used in requests via the node_name_fact / node_name_value settings. Don’t do this unless you know exactly what you’re doing, because it changes Puppet’s whole security model. For most users, certname = only name.)
  • environment — The environment to request when contacting the puppet master. It’s only a request, though; the master’s ENC can override this if it chooses. Defaults to production.

Run Behavior

These settings affect the way Puppet applies catalogs.

  • noop — If enabled, the agent won’t do any work; instead, it will look for changes that should be made, then report to the master about what it would have done. This can be overridden per-resource with the noop metaparameter.
  • priority — Allows you to “nice” puppet agent so it won’t starve other applications of CPU resources while it’s applying a catalog.
  • report — Whether to send reports. Defaults to true; usually shouldn’t be disabled, but you might have a reason.
  • tags — Lets you limit the Puppet run to only include resources with certain tags.
  • trace, profile, graph, and show_diff — Tools for debugging or learning more about an agent run. Extra-useful when combined with the --test and --debug CLI options.
  • usecacheonfailure — Whether to fall back to the last known good catalog if the master fails to return a good catalog. The default behavior is good, but you might have a reason to disable it.
  • ignoreschedules — If you use schedules, this can be useful when doing an initial Puppet run to set up new nodes.
  • prerun_command and postrun_command — Commands to run on either side of a Puppet run.
  • pluginsync — This defaults to true these days, so you don’t need it in your config file. But you might see it in default config files still, because in versions ≤2.7 you had to turn it on yourself.

Service Behavior

These settings affect the way puppet agent acts when running as a long-lived service.

  • runinterval — How often to do a Puppet run, when running as a service.
  • waitforcert — Whether to keep trying back if the agent can’t initially get a certificate. The default behavior is good, but you might have a reason to disable it.

Useful When Running Agent from Cron

  • splay and splaylimit — Together, these allow you to spread out agent runs. When running the agent as a daemon, the services will usually have been started far enough out of sync to make this a non-issue, but it’s useful with cron agents. For example, if your agent cron job happens on the hour, you could set splay = true and splaylimit = 60m to keep the master from getting briefly hammered and then left idle for the next 50 minutes.
  • daemonize — Whether to daemonize. Set this to false when running the agent from cron.
  • onetime — Whether to exit after finishing the current Puppet run. Set this to true when running the agent from cron.

Settings for Puppet Master Servers

Many of these settings are also important for standalone puppet apply nodes, since they act as their own puppet master.

These settings should usually go in [master]. However, if you’re using puppet apply in production, put them in [main] instead.


  • dns_alt_names — A list of hostnames the server is allowed to use when acting as a puppet master. The hostname your agents use in their server setting must be included in either this setting or the master’s certname setting. Note that this setting is only used when initially generating the puppet master’s certificate — if you need to change the DNS names, you must:
    • Turn off the puppet master service (or Rack server).
    • Run sudo puppet cert clean <MASTER'S CERTNAME>.
    • Run sudo puppet cert generate <MASTER'S CERTNAME> --dns_alt_names <ALT NAME 1>,<ALT NAME 2>,....
    • Re-start the puppet master service.
  • basemodulepath — A list of directories containing Puppet modules that can be used in all environments. See the modulepath page for details.
    • The modulepath setting controls the final modulepath, and can be set for each environment (when using config file environments). Starting with Puppet 3.5, though, we recommend setting basemodulepath and letting modulepath take care of itself.
  • manifest — The main entry point for compiling catalogs. Defaults to a single site.pp file, but can also point to a directory of manifests. See the manifest page for details.
  • reports — Which report handlers to use. For a list of available report handlers, see the report reference. You can also write your own report handlers. Note that the report handlers might require settings of their own, like tagmail’s various email settings.
  • ssl_client_header and ssl_client_verify_header — These are used when running puppet master as a Rack application (e.g. under Passenger), which you should definitely be doing. See the Passenger setup guide for more context about how these settings work; depending on how you configure your Rack server, you can usually leave these settings with their default values.


These features configure add-ons and optional features.

CA Settings

  • ca — Whether to act as a CA. There should only be one CA at a Puppet deployment. If you’re using multiple puppet masters, you’ll need to set ca = false on all but one of them.
  • ca_ttl — How long newly signed certificates should be valid for.
  • autosign — Whether (and how) to autosign certificates. See the autosigning page for details.

↑ Back to top