The Airflow executor determines which worker resources run your scheduled tasks.
On Astro, every Deployment requires an executor and you can change the executor at any time. After you choose an executor for an Astro Deployment, you can configure your dags and Deployment resources to maximize the executor’s efficiency and performance. Use the information provided in this topic to learn how to configure the Astro, Celery, and Kubernetes executors on Astro.
To learn more about executors in Airflow, see Airflow executors.
The difference between executors is based on how tasks are distributed across worker resources. The executor you choose affects the infrastructure cost of a Deployment and how efficiently your tasks execute. Astro currently supports three executors:
Read the following topics to learn about the benefits and limitations of each executor. For information about how to change the executor of an existing Deployment, see Update the Deployment executor.
This feature is only available for Airflow 3.x Deployments.
The Astro executor is the default for all new Airflow 3.x Deployments. The Astro executor consists of agents (workers) that pull work from an API server. The API server manages the agent lifecycle and controls task assignment logic, enabling more efficient workload distribution and scaling. This design differs from the Celery executor, where workers fetch tasks directly from a queue, and the Kubernetes executor, where the scheduler launches pods for each task.
By centrally managing both agent scaling and task assignment, the Astro executor offers increased reliability, improved performance, and cost efficiency compared to other Airflow execution models.
The Astro executor is a good fit for your Deployment if:
The Celery executor uses a group of workers, each of which can run multiple tasks at a time. Astronomer uses worker autoscaling logic to determine how many workers run on your Deployment at a given time.
The Celery executor is a good option for most use cases. Specifically, the Celery executor is a good fit for your Deployment if:
If you find that some tasks consume the resources of other tasks and cause them to fail, Astronomer recommends implementing worker queues or moving to the Kubernetes executor.
See Manage the Celery executor to learn more about how to configure the Celery executor.
The Kubernetes executor runs each task in an individual Kubernetes Pod that’s defined either in your task or Deployment configuration. When a task completes, its Pod is terminated and the resources are returned to your cluster. On Astro, the infrastructure required to run the Kubernetes executor is built into every Deployment and is managed by Astronomer.
You can specify the configuration of a task’s Pod, including CPU and memory, as part of your dag definition using the Kubernetes Python Client and the pod_override arg. Any task without a pod_override runs in a default Pod as configured on your Deployment.
The Kubernetes executor is a good option for some use cases. Specifically, the Kubernetes executor is a good fit for your Deployment if:
If you’re running a high task volume or cannot tolerate startup latency, Astronomer recommends the Celery executor. To learn more about using the Kubernetes executor, see Manage the Kubernetes executor.
For the Kubernetes executor, Astro bills for the number of A5 workers necessary to accommodate the total amount of CPU and Memory, rounded up to the nearest A5. One A5 worker corresponds to 1 CPU and 2 GiB Memory. In order to ensure reliability, Astro allocates the limit requested by each task. If a task doesn’t have specified limits, then Astro uses the Deployment defaults.