Params are arguments which you can pass to an Airflow DAG or task at runtime and are stored in the Airflow context dictionary for each DAG run. You can pass DAG and task-level params by using the params parameter.
Params are ideal to store information that is specific to individual DAG runs like changing dates, file paths or ML model configurations. Params are not encrypted and therefore not suitable to pass secrets. See also Best practices for storing information in Airflow.
This guide covers:
To get the most out of this guide, you should have an understanding of:
Params can be passed to a DAG at runtime in four different ways:
--conf flag using the Airflow CLI (airflow dags trigger).conf parameter.conf parameter.Param values passed to a DAG by any of these methods will override existing default values for the same key as long as the Airflow core config dag_run_conf_overrides_params is set to True.
While it’s possible to pass non-JSON serializable params, this behavior is deprecated and will be removed in a future release. It is best practice to make sure your params are JSON serializable.
You can pass params to DAGs with pre-defined params from the Airflow UI by clicking on the Play button.

When the DAG that has at least one param defined at the DAG-level this button opens a form in which you can specify details for the DAG run:

In earlier Airflow versions the Play button opened a dropdown menu with two options Trigger DAG and Trigger DAG w/ config. The Trigger DAG w/ config button allowed you to pass params to the DAG run even if no params were defined at the DAG level. To re-enable this behavior in Airflow 2.7+, you need to set the environment variable AIRFLOW__WEBSERVER__SHOW_TRIGGER_FORM_IF_NO_PARAMS=True.

The Trigger DAG form for DAGs without DAG-level params defined will look like this:

In the Trigger DAG form:
start_date and the end_date of the DAG to create DAG runs in the past or future.scheduled, dataset_triggered, manual or backfill) and the logical date (for example: manual__2023-06-16T08:03:45+00:00).If there are previous runs of the DAG with params different from the defaults, the Trigger DAG form will show a dropdown menu Select Recent Configurations with the option to select a previous run and copy its configuration.

After setting the configuration, you can start the DAG run with the Trigger button.
When you run an Airflow DAG from the CLI, you can pass params to the DAG run by providing a JSON string to the --conf flag. For example, to trigger the params_default_example DAG with the value of Hello from the CLI for param1, run:
Run Airflow commands from the Astro CLI using astro dev run:
The CLI prints the configuration for the triggered run to the command line:

You can use a --conf flag with the following Airflow CLI sub-commands:
airflow dags backfillairflow dags testairflow dags triggerThe TriggerDagRunOperator is a core Airflow operator that allows you to start a DAG run from within another DAG. You can use the TriggerDAGRunOperator conf param to trigger the dependent DAG with a specific configuration.
The DAG below uses the TriggerDagRunOperator to trigger the tdro_example_downstream DAG while passing a dynamic value for the upstream_color param via the conf parameter. The value for upstream_color is passed via a Jinja template pulling the return value of an upstream task via XCom.
Runs of the tdro_example_downstream DAG that are triggered by this upstream DAG will override the default value of the upstream_color param with the value passed via the conf parameter, which leads to the print_color task to print either red, green, blue or yellow.
To specify params for all runs of a given DAG, pass default values to the param parameter of the @dag decorator or the DAG class in your DAG file. You can directly specify a default value or use the Param class to define a default value with additional attributes.
The DAG below has two DAG-level params with defaults: param1 and param2, the latter only accepting integers.
If you define DAG-level param defaults, the Trigger DAG form renders a field for each param. From this UI, you can then override your defaults for individual DAG runs. A param with a red asterisk is a required param.

When you specify a required type for a param, the field will be a required input by default because of JSON validation. To make a field optional but still require a specific input type, allow NULL values by setting the type to ["null", "<my_type>"].
By default, Airflow assumes that the values provided to a keyword in the params dictionary are strings. You can change this behavior by setting the DAG parameter render_template_as_native_obj=True. See Render native Python code.
The following param types are supported:
string: A string. This is the default type.null: Allows the param to be None by being left empty.integer or number: An integer (floats are not supported).boolean: True or False.array: An HTML multi line text field, every line edited will be made into a string array as the value.object: A JSON entry field.Aside from the type attribute, the Param class has several other attributes that you can use to define how users interact with the param:
title: The title of the param that appears in the Trigger DAG UI.description: A description of the param.description_md: A description defined in Markdown that can contain links and other Markdown elements. In Airflow 2.8+, if you want to use HTML in the description, you need to set the Airflow configuration webserver.allow_raw_html_descriptions to True (AIRFLOW__WEBSERVER__ALLOW_RAW_HTML_DESCRIPTIONS=True). Note that HTML can introduce vulnerabilities and that adding invalid HTML might lead to the UI not rendering correctly.section: Creates a section under which the param will appear in the Trigger DAG UI. All params with no specified section will appear under the default section DAG conf Parameters.format: A JSON format that Airflow will validate a user’s input against.enum: A list of valid values for a param. Setting this attribute creates a dropdown menu in the UI.const: Defines a permanent default value and hides the param from the Trigger DAG UI. Note that you still need to provide a default value for the param.custom_html_form: Allows you to create custom HTML on top of the provided features. As of Airflow 2.8 this feature is deprecated and will be replaced by a new implementation in the future.All Param attributes are optional to set. For string type params, you can additionally set minLength and maxLength to define the minimum and maximum length of the input. Similarly, integer and number type params can have a minimum and maximum value.
This section presents a few examples of params and how they are rendered in the Trigger DAG UI.
The code snippet below defines a mandatory string param with a few UI elements to help users input a value.

When you define date, datetime, or time param, a calendar picker appears in the Trigger DAG UI.

Providing a list of values to the enum attribute will create a dropdown menu in the Trigger DAG UI. Note that the default value must also be in the list of valid values provided to enum. Due to JSON validation rules, a value has to be selected.

A boolean type param will create a toggle in the Trigger DAG UI.

If you provide custom HTML to the custom_html_form attribute, you can create more complex UI elements like a color picker. For sample code, see this example DAG in the Airflow documentation. Note that this feature is deprecated as of Airflow 2.8 and its implementation will change in the future.

You can set task-level param defaults in the same way as for DAG-level params. If a param of the same key is specified at both the DAG and task level, the DAG-level param will take precedence.
You can access params in an Airflow task like you can with other elements in the Airflow context.
Params are also accessible as a Jinja template using the {{ params.my_param }} syntax.
If you try to access a param that has not been specified for a specific DAG run, the task will fail with an exception.
The order of precedence for params, with the first item taking most precedence, is as follows:
True.