ansible.builtin.set_fact – Set host variable(s) and fact(s).


This module is part of ansible-core and included in all Ansible installations. In most cases, you can use the short module name set_fact even without specifying the collections: keyword. However, we recommend you use the FQCN for easy linking to the module documentation and to avoid conflicting with other collections that may have the same module name.

New in version 1.2: of ansible.builtin


  • This action allows setting variables associated to the current host.
  • These variables will be available to subsequent plays during an ansible-playbook run via the host they were set on.
  • Set cacheable to yes to save variables across executions using a fact cache. Variables will keep the set_fact precedence for the current run, but will used ‘cached fact’ precedence for subsequent ones.
  • Per the standard Ansible variable precedence rules, other types of variables have a higher priority, so this value may be overridden.


This module has a corresponding action plugin.


Parameter Choices/Defaults Comments
added in 2.4 of ansible.builtin
  • no
  • yes
This boolean converts the variable into an actual 'fact' which will also be added to the fact cache, if fact caching is enabled.
Normally this module creates 'host level variables' and has much higher precedence, this option changes the nature and precedence (by 7 steps) of the variable created. https://docs.ansible.com/ansible/latest/user_guide/playbooks_variables.html#variable-precedence-where-should-i-put-a-variable
This actually creates 2 copies of the variable, a normal 'set_fact' host variable with high precedence and a lower 'ansible_fact' one that is available for persistance via the facts cache plugin. This creates a possibly confusing interaction with meta: clear_facts as it will remove the 'ansible_fact' but not the host variable.
string / required
The set_fact module takes ``key=value`` pairs or ``key: value``(YAML notation) as variables to set in the playbook scope. The 'key' is the resulting variable name and the value is, of course, the value of said variable.
You can create multiple variables at once, by supplying multiple pairs, but do NOT mix notations.



  • Because of the nature of tasks, set_fact will produce ‘static’ values for a variable. Unlike normal ‘lazy’ variables, the value gets evaluated and templated on assignment.
  • Some boolean values (yes, no, true, false) will always be converted to boolean type, unless DEFAULT_JINJA2_NATIVE is enabled. This is done so the var=value booleans, otherwise it would only be able to create strings, but it also prevents using those values to create YAML strings. Using the setting will restrict k=v to strings, but will allow you to specify string or boolean in YAML.
  • To create lists/arrays or dictionary/hashes use YAML notation var: [val1, val2].
  • Since ‘cacheable’ is now a module param, ‘cacheable’ is no longer a valid fact name.
  • This action does not use a connection and always executes on the controller.

See Also

See also


The official documentation on the ansible.builtin.include_vars module.

Variable precedence: Where should I put a variable?

More information related to variable precedence and which type of variable wins over others.


- name: Setting host facts using key=value pairs, this format can only create strings or booleans
  set_fact: one_fact="something" other_fact="{{ local_var }}"

- name: Setting host facts using complex arguments
    one_fact: something
    other_fact: "{{ local_var * 2 }}"
    another_fact: "{{ some_registered_var.results | map(attribute='ansible_facts.some_fact') | list }}"

- name: Setting facts so that they will be persisted in the fact cache
    one_fact: something
    other_fact: "{{ local_var * 2 }}"
    cacheable: yes

- name: Creating list and dictionary variables
        something: here
        other: there
        - a
        - b
        - c

- name: Creating list and dictionary variables using 'shorthand' YAML
    two_dict: {'something': here2, 'other': somewhere}
    two_list: [1,2,3]


  • Dag Wieers (@dagwieers)

© 2012–2018 Michael DeHaan
© 2018–2021 Red Hat, Inc.
Licensed under the GNU General Public License version 3.