> ## Documentation Index
> Fetch the complete documentation index at: https://astronomer.io/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Astro executor

<Note>
  **Airflow 3**

  This feature is only available for Airflow 3.x Deployments.
</Note>

## Overview

The Astro executor is the default for all Airflow 3.x Deployments, and is the only executor you can use for Deployments in remote execution mode. The Astro executor consists of Agents 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.

## Remote Execution mode

In a remote execution mode Deployment, the Remote Execution Agents, data sources, code, secrets, and logs are housed in your environment while the API server is hosted in Astro's Orchestration Plane. To configure workers and scaling in Remote Execution mode, see [Remote Execution Agents](/docs/astro/remote-execution-configure-agents).

For more information on Remote versus Hosted execution mode, see [Execution mode](/docs/astro/execution-mode).

## Astro worker autoscaling logic in Hosted execution mode

If your Deployment is in [Hosted execution mode](/docs/astro/execution-mode), the number of Astro workers running per worker queue on your Deployment at a given time is based on two values:

* The total number of tasks in a `queued` or `running` state.
* The worker queue's setting for **Concurrency**.

The calculation is made based on the following expression:

`[Number of workers]= ([Queued tasks]+[Running tasks])/(Concurrency)`

[Kubernetes Event Driven Autoscaling](https://keda.sh/) (KEDA) computes these calculations every ten seconds. When KEDA determines that it can scale down a worker, it waits for five minutes after the last running task on the worker finishes before terminating the worker Pod.

When you push a new image to a Deployment, workers running tasks from before the code push don't shut down until those tasks are complete. To learn more about how changes to a Deployment can affect worker resource allocation, see [What happens during a code deploy](/docs/astro/deploy-project-image#what-happens-during-a-project-deploy).

## Configure the Astro executor in Hosted execution mode

In Hosted execution mode, you can configure Astro executor in the following ways with the Astro UI:

* The type and size of your workers.
* The minimum and maximum number of workers that your Deployment can run at a time.
* The number of tasks that each worker can run at a time.

You can set these configurations per [worker queue](/docs/astro/configure-worker-queues). With the Astro executor, you can configure multiple worker queues for different types of tasks and assign tasks to those queues in your Dag code.

The following document explains basic Astro executor configurations for a single worker queue. For instructions on how to configure multiple worker queues, see [Create a worker queue](/docs/astro/configure-worker-queues#create-a-worker-queue).

<Tip>If you plan to use only the `KubernetesPodOperator` in your Deployment, set your worker resources to the lowest possible amounts, because the worker is only required for launching your Pods. See [`KubernetesPodOperator`](/docs/astro/kubernetespodoperator) for more information.</Tip>

<Tip>
  **A new Astro UI is here**

  Astronomer has redesigned the Astro UI. Try the new experience and switch your instructions using the **New Astro UI** and **Legacy UI** tabs on this page. Your selection is remembered across the docs.
</Tip>

## Configure Astro worker scaling in Hosted execution mode

For each worker queue on your Deployment, you have to specify certain settings that affect worker scaling behavior. If you're new to Airflow, Astronomer recommends using the defaults in Astro for each of these settings.

<Tabs>
  <Tab title="New Astro UI" language="astro-next-ui">
    1. In the Astro UI, click **Deployments**.

    2. Click the Deployment's **More actions** menu (⋯), then click **Edit Deployment**.

    3. In the **Execution** section, edit the worker queue and configure the following settings:

       * **Worker type**: Choose the amount of resources that each worker will have.
       * **Concurrency**: The maximum number of tasks that a single worker can run at a time. If the number of queued and running tasks exceeds this number, a new worker is added to run the remaining tasks. This value is equivalent to the Apache Airflow [worker concurrency](https://airflow.apache.org/docs/apache-airflow/stable/configurations-ref.html#worker-concurrency) setting. It is 16 by default.
       * **Storage**: Choose the amount of ephemeral storage in GiB that each worker has. This storage volume is transient and allows for temporary storage and processing of data within the worker. The worker is assigned the minimum 10 GiB by default. The maximum quota is 100 GiB. Only ephemeral storage requests that are greater than the default minimum of 10 GiB are chargeable.
       * **Worker Count (Min-Max)**: The minimum and maximum number of workers that can run at a time. The number of running workers changes based on **Concurrency** and the current number of tasks in a queued or running state. By default, the minimum number of workers is 1 and the maximum is 10.

       <Info>The number of running workers might temporarily exceed the max when longer duration tasks delay scaled-down workers from shutting down.</Info>

    4. Click **Update Deployment**.
  </Tab>

  <Tab title="Legacy UI" language="legacy-ui">
    1. In the Astro UI, select a Workspace, click **Deployments**, and then select a Deployment.
    2. Click the **Details** tab and then click **Edit** in the **Execution** section to edit a worker queue.
    3. Configure the following settings:

       * **Worker type**: Choose the amount of resources that each worker will have.
       * **Concurrency**: The maximum number of tasks that a single worker can run at a time. If the number of queued and running tasks exceeds this number, a new worker is added to run the remaining tasks. This value is equivalent to the Apache Airflow [worker concurrency](https://airflow.apache.org/docs/apache-airflow/stable/configurations-ref.html#worker-concurrency) setting. It is 16 by default.
       * **Storage**: Choose the amount of ephemeral storage in GiB that each worker has. This storage volume is transient and allows for temporary storage and processing of data within the worker. The worker is assigned the minimum 10 GiB by default. The maximum quota is 100 GiB. Only ephemeral storage requests that are greater than the default minimum of 10 GiB are chargeable.
       * **Worker Count (Min-Max)**: The minimum and maximum number of workers that can run at a time. The number of running workers changes based on **Concurrency** and the current number of tasks in a queued or running state. By default, the minimum number of workers is 1 and the maximum is 10.

    <Info>The number of running workers might temporarily exceed the max when longer duration tasks delay scaled-down workers from shutting down.</Info>

    4. Click **Update Queue**.
  </Tab>
</Tabs>

## See also

* [Configure worker queues](/docs/astro/configure-worker-queues).