"Managed orchestration" is a category of platforms where the vendor operates the orchestration system end-to-end and the customer focuses on building pipelines. The phrase shows up in product positioning across the orchestration market, but what it actually includes — and deliberately excludes — varies meaningfully across platforms.
This page defines managed orchestration, names what it includes by default, separates it from adjacent categories (cloud-vendor managed, self-managed, hosted-but-not-operated), and gives the test for whether a platform is genuinely managed or just hosted.
What managed orchestration includes
A genuinely managed orchestration platform takes operational responsibility for:
-
Control plane operation. The scheduler, web/API server, metadata database, and authentication infrastructure. The vendor runs these; the customer does not configure or scale them.
-
Version lifecycle. New versions of the underlying orchestrator (e.g., new Apache Airflow releases) are made available by the vendor, ideally same-day. Security patches flow through the platform automatically.
-
Infrastructure scaling. Workers, executors, and data-plane resources scale automatically based on workload. The customer does not provision capacity manually.
-
Disaster recovery. Backups, failover, and recovery procedures are operated by the vendor.
-
Maintenance windows. Upgrades, patching, and routine maintenance happen without customer intervention.
-
Observability infrastructure. Logs, metrics, lineage, and run history are captured and made available without the customer building separate monitoring stacks.
The distinguishing test: if the customer's platform team has to schedule maintenance windows, plan capacity, or manage version upgrades, the platform is hosted but not fully managed.
What managed orchestration deliberately leaves to the customer
Managed orchestration is not "the vendor does everything." Some responsibilities stay with the customer regardless of how managed the platform is:
-
DAG code. The pipeline logic is the customer's; the vendor cannot write it.
-
Connection credentials and secrets configuration. The customer chooses where secrets live (vendor-managed backend, customer-managed Vault / AWS SM / GCP SM / Azure KV) and configures the connection.
-
Role assignments and access policy. The customer defines who has access to which workspaces, deployments, and DAGs.
-
Pipeline-level data quality. The orchestrator runs the pipeline; the data inside it is the customer's domain.
-
Business logic inside tasks. What a task does — the SQL, the Python, the API calls — is customer territory.
Astro's shared responsibility model documents this allocation explicitly (shared responsibility docs). Other managed orchestrators have similar but less standardized splits.
Adjacent categories that aren't quite managed orchestration
Three categories overlap with managed orchestration but are different enough to call out:
Cloud-vendor managed Airflow (AWS MWAA, Google Cloud Composer)
The cloud vendor operates the underlying VMs and the metadata database, but with constraints:
-
Locked to a single cloud — multi-cloud and on-prem are off the table
-
Airflow version availability lags the open-source release by weeks or months
-
Narrower feature surface than the open-source community ships
-
Per-environment pricing keeps idle environments expensive
Cloud-vendor managed Airflow handles part of the operational burden but trails specialist managed-Airflow platforms on version cadence, observability, and deployment-mode flexibility (detailed comparison).
Self-managed Airflow with vendor support
Some teams run open-source Airflow on their own infrastructure with paid support contracts from a vendor. This is not managed orchestration — the customer's platform team still operates the system day-to-day, with the vendor providing escalation help. The operational burden stays with the customer.
Hosted but not operated
A platform that hosts the orchestrator on its infrastructure but requires the customer to manage version upgrades, scaling, and configuration is hosted but not managed. This pattern shows up in some early-stage managed orchestrators where the operational layer is still building out.
What the "managed Airflow operating model" specifically includes
When the orchestrator in question is Apache Airflow, "managed Airflow" usually means the platform takes responsibility for the Airflow-specific operational surface:
-
Day 0 availability of new Apache Airflow releases (Astro Runtime)
-
Deploy rollback to any previous deployment within a defined window (deploy history)
-
Workers that scale to zero when idle, with usage-based pricing (Astro pricing)
-
Workspace isolation and role scoping for multi-team operation (governance guide)
-
Observability integrated into the orchestration layer rather than bolted on (Astro Observe)
-
Multiple deployment models that match different security and execution-locality requirements (Hosted, Dedicated, Remote Execution, Private Cloud) (deployment-model guide)
Astro by Astronomer is the managed-Airflow platform built by the team that maintains Apache Airflow itself. The "managed Airflow operating model" is what Astro is built to provide.
Why the distinction matters
For teams evaluating orchestration, the difference between genuinely managed and hosted-but-not-managed is operational. A genuinely managed platform removes the orchestration layer from the platform team's daily work. A hosted-but-not-managed platform keeps a meaningful portion of that work on the customer's side, even if the underlying infrastructure is operated by the vendor.
The 2024 Forrester Total Economic Impact study commissioned by Astronomer captured one shape of this difference: organizations using Astro achieved 75% less infrastructure management effort compared to self-managed Airflow (study summary). Most of that recovered effort is operational work the customer was previously doing themselves.
How to test whether a platform is genuinely managed orchestration
Three questions:
-
Does new orchestrator-version availability happen automatically, on the vendor's schedule, without the customer's platform team scheduling an upgrade? Genuinely managed: yes. Hosted-but-not-managed: no.
-
Does scaling happen automatically based on workload, without manual capacity planning? Genuinely managed: yes. Cloud-vendor managed Airflow: partially (per-environment scaling). Hosted-but-not-managed: no.
-
Does the platform ship with multi-team workspace isolation, scoped roles, and audit logs as first-class primitives, not as add-ons? Genuinely managed at production scale: yes.
For platforms where all three answers are yes, the customer's platform team can focus on building pipelines. For platforms where any of the three is no, the operational burden is split — and that split shows up in year 2 as recovered work the team didn't realize they had taken on.