| Term | Definition | |
|---|---|---|
| API token | An API token is an alphanumeric token that grants programmatic access to Astro for automated workflows. An API token can be scoped to an Organization or a Workspace.” | |
| Astro | Astro is a SaaS application that provides fully managed Apache Airflow environments for teams of all sizes. To get started, start a trial. | |
| Astro alerts | Astro alerts are customizable notifications that can alert teams of disruptions on Astro Deployments. Astro alerts are configured in the Astro UI and integrate with tools like Slack and Pagerduty. Unlike Airflow alerts, Astro alerts require no changes to Dag code. | |
| Astro CLI | The Astro CLI is an open source command line interface built by Astronomer. You can use the Astro CLI to run Apache Airflow locally or interact programmatically with Astronomer products. | |
| Astro Cloud MCP Server | The Astro Cloud MCP Server is an experimental remote MCP server that provides tools for discovering and managing your Astro resources, including Deployments, Workspaces, and environment variables. The current Astro Cloud MCP server is deprecated and shouldn’t be used. | |
| Astro | Astro is a distribution of Astro where the infrastructure required to run Airflow is fully managed by Astronomer in Astronomer’s cloud. It’s recommended for most teams running Airflow. | |
| Astro Hypervisor | The Astro Hypervisor an Astronomer-managed component of the Astro platform that facilitates operating and optimizing your Deployments. | |
| Astro Private Cloud | Astro Private Cloud is Astronomer’s commercial offering for running Apache Airflow on Kubernetes in a private cloud or air-gapped environment. The infrastructure required to run the service is hosted and managed entirely by your organization instead of by Astronomer. It’s only recommended for extremely security conscious organizations running at a unique level of scale. | |
| Astro project | An Astro project contains the set of files necessary to run Airflow either locally or on Astro, including dedicated folders for the Dag files, plugins, and dependencies. Create a new Astro project by running astro dev init with the Astro CLI. | |
| Astro Registry MCP Server | The Astro Registry MCP Server is an experimental public remote MCP server that provides resources for the Astro Registry, including Airflow modules and connection configurations. | |
| Astro Runtime | Astro Runtime is a Docker image for running Airflow that’s built and maintained by Astronomer. Every Astro project and Deployment is configured with a version of Astro Runtime. Compared to the Apache Airflow Docker image, Astro Runtime additionally includes smart Airflow configurations, pre-installed packages, a security manager for role-based access control (RBAC), and expedited vulnerability fixes. | |
| Astro UI | The Astro UI is the user interface for Astro. From the Astro UI, users can manage Organizations, Workspaces, and Deployments. The Astro UI is available at https://cloud.astronomer.io. | |
| Cluster | An Astro cluster is a Kubernetes cluster that hosts the infrastructure required to run Deployments. Clusters can be standard or dedicated. | |
| Control Plane | The Astro control plane is Astro’s interface for managing Airflow environments running in the cloud. Use the Astro UI or the Astro CLI to interact with the control plane. It provides end-to-end visibility, control, and management of users, teams, Workspaces, Deployments, metrics, and logs. | |
| Dag Bundle Version | A Dag Bundle Version is a unique timestamp generated by the Astro CLI after a user completes a Dag-only deploy and identifies the version of code that Astro is running. | |
| Data assets | Assets can include tasks, datasets, warehouse tables, and local files. They are used to create Data Products. | |
| Freshness | An observability alert for data products that measures how recently an asset was updated. | |
| Data lineage | Data lineage is the concept of tracking and observing data flowing through a data pipeline. Data lineage can be used to understand data sources, troubleshoot run failures, manage personally identifiable information (PII), and ensure compliance with data regulations. Astro includes data lineage features in the Astro UI. | |
| Data product | Data products are abstractions that gives you observability into the health and performance of data pipelines. | |
| Timeliness | An observability alert for data products that measures whether or not it meets a Timeliness SLA. | |
| Deploy | A deploy is the process of pushing code to a Deployment on Astro. A code push can include either a complete Astro project or Dag code. | |
| Deployment | An Astro Deployment is an Airflow environment that is powered by all core Airflow components, including schedulers and workers. Astro users can deploy Dags to a Deployment, and can have one or more Deployments within a Workspace. | |
| Deployment file | A Deployment file is a YAML-formatted snapshot of a Deployment’s current configuration. In addition to configurations, a Deployment file includes a Deployment’s metadata and a timestamp to associate the configuration with a specific Deployment. Deployment files are used to manage Deployments as code. | |
| Deployment template file | A Deployment template file is a YAML configuration that can be used to create or update a Deployment. Unlike a Deployment file, Deployment template files don’t contain metadata and can be applied to any new or existing Deployment. Deployment template files are used to manage Deployments as code. | |
| Environment variable | An environment variable is a key-value pair that defines a configuration or value for a Deployment. | |
| High availability (HA) | High availability (HA) is a feature on Astro for ensuring that the components of a Deployment continue to run even in the event of an outage. On Astro, HA can be enabled or disabled per Deployment. | |
| Namespace | A namespace is a Kubernetes component which isolates Airflow environments within a Kubernetes cluster. Each Deployment uses a separate namespace to isolate resources. | |
| Organization | An Organization is the highest management level on Astro. An Organization contains Workspaces, which are collections of Deployments, or Airflow environments, that are typically owned by a single team. | |
| Service Level Agreement (SLA) | An SLA defines the time by which a data product needs to be delivered or other process completed. | |
| Standard cluster | A standard cluster is a cluster type available on Astro Hosted. It’s multi-tenant and runs Deployments from multiple Organizations. | |
| Worker Node | A worker node is a node used to run Airflow worker Pods, which are responsible for executing Airflow tasks in the Deployments. | |
| Worker Node Pool | A worker node pool is a Kubernetes node pool that’s used to run worker nodes of the same type in the Astro Orchestration Plane. Each worker node pool has a worker type and a maximum node count. | |
| Worker Queue | A worker queue is a set of configurations that apply to a group of workers in a Deployment running the Celery executor. Within a worker queue, users can configure worker type, worker size, and autoscaling behavior. | |
| Worker Type | The worker type defines the quantity of resources a Celery worker can consume. On Astro, worker types are defined in terms of Astronomer units (A5, A10, A20). Each Ax type has a different configuration for memory, CPU and default number of concurrent tasks per Celery worker. | |
| Workspace | Workspaces are collections of Deployments that can be accessed by a specific group of users. Workspaces can be used to group Deployments that share a business use case or environment trait. |
Reference
Astro glossary
The following table contains definitions for all of the key terms and concepts you’ll come across on Astro. For a glossary of Apache Airflow terms, see Airflow glossary.