Skip to main content
This document is a reference for all environment variables on Astronomer with different default values than open source Apache Airflow. You can override default Runtime environment variables, but you can’t override system environment variables. For information on setting your own environment variables, see Environment variables.

System environment variables

On Astro, certain environment variables have special handling. There are three types of special handling:
  • Override variables have their value set by Astro, regardless of what you set in your Deployment.
  • Default change variables have values that are different from the values in open source Apache Airflow. But, if you specify a value, your value takes precedence.
  • Unsafe to change variables are environment variables used by Astro to function. Do not override variables listed as Unsafe to change, because it can break Astro functionality.
The following table provides information about each global environment variable set by Astronomer.
The Astro UI does not currently prevent you from setting the environment variables listed as Unsafe to change. Attempting to set them can result in unexpected behavior that can include access problems, missing task logs, and failed tasks.If you need to set one of these variables for a particular use case, contact Astronomer support.

Default changed

Override

Unsafe to change

XCom and state store backends

On Astro Hosted, Astro stores XCom values larger than 64 KB in an Astro-managed object storage bucket instead of the Airflow metadata database. On Astro Runtime 3.3 and later, Astro also stores task and asset state values larger than 64 KB in the same bucket. Values of 64 KB or less stay in the metadata database. To do this, Astro sets the following environment variables on Deployments that run Astro Runtime 3.0 or later:
  • AIRFLOW__CORE__XCOM_BACKEND
  • AIRFLOW__WORKERS__STATE_STORE_BACKEND, on Astro Runtime 3.3 and later only
Astro doesn’t set these variables on Remote Execution Deployments.

Use your own XCom or state store backend

Astro keeps your own backend when you set the variable as an Astro environment variable, either on the Deployment or as a Workspace-level environment variable linked to the Deployment. If you set the variable anywhere in your Astro project image, such as with an ENV instruction in your Dockerfile, Astro replaces it with its own backend.
A backend can’t read values that a different backend stored in object storage. When a Deployment changes backends, tasks in Dag runs that are already in progress can fail if they read an XCom or state value stored before the change. Make the change when no Dag runs that depend on these values are in progress.
To move a backend from your image to a Deployment environment variable:
  1. Open your Astro project Dockerfile and find the ENV instructions that set AIRFLOW__CORE__XCOM_BACKEND or AIRFLOW__WORKERS__STATE_STORE_BACKEND.
  2. Add each variable to your Deployment with the same value. See Use the Astro UI.
You need to move only the backend variables. Other settings that your backend reads, such as AIRFLOW__COMMON_IO__XCOM_OBJECTSTORAGE_PATH, can stay in your Dockerfile. You can also keep the backend ENV instructions for local development, because the Deployment environment variable takes precedence on Astro. To switch a Deployment back to the Astro backend, delete the variable from the Deployment and from any Workspace-level environment variables linked to it. The same risk to in-progress Dag runs applies.