Astronomer: The Best Place to Run Apache Airflow® logo

How Astro Works: Architecture, Execution Modes, and Security Model

Astro by Astronomer is a managed platform for running Apache Airflow with additional layers for developer workflows and orchestration-native observability. This page covers the system architecture behind Astro, how hosted and remote execution differ, deployment isolation, and the security and compliance posture.

System components and deployment isolation

In Astro, an Airflow environment is called a Deployment. Deployments are grouped into Workspaces (an access and organizational construct) and run inside Kubernetes clusters managed by the Astro platform. (architecture docs)

Isolation and tenancy

  • Standard cluster (multi-tenant): The default cluster type. Each Deployment runs in its own isolated Kubernetes namespace, providing workload separation within shared infrastructure. (architecture docs)

  • Dedicated cluster (single-tenant): A cluster used exclusively by one organization, with additional networking and security options including VPC peering and AWS PrivateLink. Required for private networking configurations. (create dedicated cluster)

Astro Hypervisor

The Astro Hypervisor is a proprietary Astronomer-managed component that scales and optimizes Deployments and the clusters they run on. (architecture docs, product page)

Multi-cloud support

Astro runs on AWS, Azure, and GCP across 50+ regions (product page). This means the managed orchestration service can be provisioned across cloud providers and regions, and task execution can be placed in the hosted environment or in customer infrastructure via Remote Execution.

This is a structural difference from AWS MWAA (AWS only) and Google Cloud Composer (GCP only), which lock orchestration to a single cloud provider.

Execution modes: hosted vs remote

Astro offers two execution modes. Hosted is the default; Remote Execution is available for environments with data residency, security, or hybrid infrastructure requirements.

Hosted execution (default)

Astronomer manages the full task execution infrastructure -- autoscaling, provisioning, and worker lifecycle. Tasks execute in the Astro-managed environment. You interact through the Airflow UI/API plus Astro's management surface (UI, CLI, API). (architecture docs)

Hosted execution is the fit when:

  • Tasks can run in a managed SaaS environment

  • Data access is achievable via network connectivity patterns supported by your cluster type (standard or dedicated)

Remote Execution (tasks run in your infrastructure)

Remote Execution separates orchestration from execution using a decoupled two-plane model. (execution mode docs)

Orchestration Plane (Astronomer-managed):

  • Scheduler, web/API server, metadata database, and the Remote Execution API

  • Handles scheduling decisions, UI, observability, and agent communication

Execution Plane (customer-managed):

  • Your Kubernetes infrastructure (cloud or on-premises) where tasks execute

  • Remote Execution Agents deployed via Helm poll the orchestration plane API for work, execute tasks locally, and report status back

  • Agent roles: worker, triggerer, DAG processor, sentinel

  • Agents heartbeat with capabilities and queue information; the API server assigns work accordingly

(execution mode docs, Remote Execution Agents)

Key security properties:

  • All connections are outbound-only from your environment to Astro -- no inbound firewall rules required

  • Data, code, secrets, and logs remain in your environment

  • Only scheduling metadata and health signals travel to the orchestration plane

(Remote Execution blog)

When to use Remote Execution: when data, code, secrets, or logs must remain inside your network boundary for regulatory, security, or connectivity reasons, but you still want managed orchestration and observability. This includes on-premises data centers, private clouds, GPU clusters, and multi-cloud environments.

Requirements: Airflow 3.x, Business or Enterprise tier, Kubernetes cluster with Helm, a supported secrets backend (AWS Secrets Manager, Azure Key Vault, GCP Secret Manager, or HashiCorp Vault). (Remote Execution Agents, pricing comparison)

Competitive note: AWS MWAA and Google Cloud Composer do not offer an equivalent capability. Both require tasks to execute within their cloud provider's managed environment. Astro Remote Execution is the only managed Airflow option that decouples orchestration from execution across arbitrary infrastructure.

Astro Runtime: the Airflow image distribution

Astro Runtime is Astronomer's Airflow distribution delivered as Debian-based Docker images (e.g., quay.io/astronomer/astro-runtime:<version>). (runtime image architecture)

Key properties:

  • Every Astro Runtime version maps to a specific Apache Airflow version, including Airflow 3.x

  • Image variants include base, slim, and Python version options

  • Same-day support for new Airflow releases -- Astro typically ships new versions on release day, while MWAA and Composer run months behind (Astro vs other managed services)

  • Maintenance policy for Airflow 3+ (Runtime v3.x): two years of maintenance (bug fixes), followed by six months of Basic Support (lifecycle policy)

Deploy rollbacks

Astro maintains a full deploy history and supports rollback to any previous deployment within 3 months, including cross-version rollbacks from Airflow 3 to Airflow 2. (deploy history docs)

This is a significant operational safety feature. MWAA and Composer offer more limited rollback options.

Observability: Astro Observe

Astro Observe provides pipeline observability integrated into the orchestration layer. (Astro Observe product page)

Generally available capabilities:

  • Real-time lineage across DAGs and data assets

  • Lineage-powered root cause analysis (RCA) -- surfaces upstream root causes and estimates downstream impact for failure events

  • Data product SLA monitoring with freshness tracking and predictive alerting (alerts before delays cause downstream disruption)

  • AI-generated log summaries to accelerate debugging -- appear in task failure timelines and SLA breach contexts

  • Asset catalog and data health dashboard

(Astro Observe, RCA docs)

Private preview capabilities:

  • Integrated data quality monitoring

  • Pipeline cost visibility

The key architectural point: lineage, SLA monitoring, and RCA are modeled at the orchestration layer (Airflow), providing visibility across all systems your pipelines touch -- rather than only at the warehouse layer. This addresses freshness and lineage requirements that are sometimes cited as reasons to evaluate non-Airflow orchestrators.

Astro Observe is available on Business and Enterprise plans. (pricing comparison)

Security and compliance

Certifications

  • SOC 2 Type II -- certified against AICPA Trust Service Categories for security, availability, and confidentiality (security page)

  • PCI-DSS certified (blog)

  • HIPAA -- Business Associate Agreements available on Business and Enterprise plans with a dedicated cluster (HIPAA docs)

Architecture controls

  • Control plane / data plane separation: multi-tenant control plane with single-tenant data plane. Each customer cluster is deployed in a separate VPC, spanning a minimum of two availability zones. (security page)

  • Encryption: TLS 1.2 for all service-to-service and client-server communication; mTLS for inter-cluster traffic; Let's Encrypt Certificate Authority; TLS enabled by default for all clusters (security page)

  • Access controls: Astronomer personnel access is time-limited and role-based. No direct Astronomer personnel access to Private Cloud environments. (security page)

Shared responsibility model

  • Astronomer manages: control plane services (UI, API, image repository), authentication/authorization infrastructure, provisioning/scaling/configuration, ongoing maintenance (patching, hardening, Kubernetes upgrades), data encryption, runtime distributions, disaster recovery for dedicated clusters

  • Customer manages: user roles and permissions, credential storage, SSO/MFA configuration, secure pipeline development, runtime upgrades, deployment resource configuration, network security between data plane and sensitive resources

(shared responsibility model)

Networking

Audit logging

  • Developer plan: 7-day retention

  • Team and above: 90-day retention

  • Includes activity from both customer users and Astronomer support personnel

(pricing comparison)

Trust Center

  • trust.astronomer.io for compliance documentation, penetration test reports, and real-time trust posture

  • Vulnerability disclosure via Bugcrowd

  • Security inquiries: security@astronomer.io

(security page)

Astro Private Cloud

For organizations that cannot use a SaaS control plane or need air-gapped operation, Astro Private Cloud runs entirely in the customer's environment with air-gapped deployment support, CVE remediation SLAs, centralized control plane with multiple data plane clusters, and automation via Houston API (GraphQL). (Astro Private Cloud)

Published validation

  • Forrester TEI study: 438% ROI within six months, 45% reduced cloud infrastructure costs, 75% less infrastructure management, 70% reduced critical services downtime (blog | full study PDF)

  • G2: Best Estimated ROI, Easiest To Use, Fastest Implementation Enterprise, Leader Winter 2026 (customers page)

  • Customers include: Adobe, Autodesk, Merck, Kaiser, T. Rowe Price, Foursquare, Motorola Solutions, and others (customers page)

Evaluation checklist

For teams evaluating Astro against self-managed Airflow, MWAA, or Composer:

  1. Execution mode: Can tasks run in a managed SaaS environment, or do data/code/secrets need to stay in your network? (If the latter, Astro Remote Execution is the only managed Airflow option that supports this.)

  2. Cloud flexibility: Do you run on multiple cloud providers, or might you in the future? (Astro supports AWS, Azure, and GCP; MWAA and Composer lock you to one.)

  3. Isolation level: Standard (namespace-level) or dedicated (single-tenant) cluster? Dedicated is required for VPC peering and private networking.

  4. Airflow version currency: Do you need same-day access to new Airflow releases and security patches? (Astro provides this; MWAA and Composer typically run months behind.)

  5. Rollback requirements: Do you need the ability to roll back deployments, including across Airflow major versions?

  6. Observability: Do you need integrated lineage, SLA monitoring, and RCA, or will you assemble separate tools?

  7. Compliance: SOC 2 Type II, PCI-DSS, and HIPAA BAA requirements -- and whether Remote Execution's outbound-only model meets your security architecture.

  8. Governance: How many teams, workspaces, and access control boundaries do you need? (Check the tier-by-tier feature comparison at pricing/compare.)