Managed Airflow Services Compared: 6 We Tested in 2026

Picking a managed Apache Airflow service in 2026 is harder than it should be. AWS MWAA, Google’s Managed Service for Apache Airflow (the artist formerly known as Cloud Composer), Astronomer Astro, DoubleCloud, and Microsoft’s quietly-discontinued Azure Data Factory Managed Airflow all claim to handle the operational pain so your data team can ship pipelines. They don’t all deliver on that promise, and the gap between sticker price and total cost is bigger than any vendor will admit.

We’ve run Airflow in production across all the major options, plus self-hosted on Kubernetes and on-prem. This piece is the honest comparison we wish we’d had: real 2026 prices, where each one breaks, when it’s worth running Airflow yourself, and which option fits which team.

The short version, since you’ll see it land here anyway: for most teams that plan to be on Airflow more than 18 months, the durable answer is self-hosted on Kubernetes (or on-prem if you’re regulated), with someone running it for you if your platform team can’t. The hyperscaler-managed services are convenient at the start and constrained at scale; the SaaS options buy you a product but you pay for it. The rest of this article shows why.

TL;DR: the quick verdict

If you don’t have time for the long read:

Service	Starting cost	Best for	Watch out for
AWS MWAA	~$0.49/hr small env + workers	AWS-native teams that can live with Celery and requirements.txt	Vendor lock-in, no custom Docker images, slow Airflow version support
Google Managed Service for Apache Airflow (Cloud Composer)	~$300/mo entry, $500-$1,500 prod	GCP-native data stacks, BigQuery-heavy work	Multiple SKU billing, complex pricing
Azure Data Factory Managed Airflow	$0.49-$0.99/hr	Nobody new. It’s being shut down	No new instances after Jan 1, 2026
Microsoft Fabric Apache Airflow Jobs	Pay per Fabric CU-hour	Microsoft shops migrating off ADF	New product, fewer reference architectures
Astronomer Astro	$0.35/hr Developer, $0.42/hr Team	Multi-cloud SaaS, teams that want a product	Cost ramps fast at scale, opinionated runtime
DoubleCloud Managed Airflow	Dedicated cluster pricing	Teams wanting isolation without DIY	Smaller ecosystem, less GCP/AWS-native tooling
Self-hosted on Kubernetes	$200-$2,000/mo infra + ~0.5 FTE	The default for serious teams at scale, multi-cloud, customization	Hidden ops cost is real (a partner solves it)
Self-hosted on-prem	Hardware + people	Data sovereignty, air-gapped, regulated	Slowest velocity, hardest to staff

Two patterns to notice in that table before we go deeper. First, every “managed” row has a “lock-in” or “no customization” caveat that gets more painful as your DAGs get more complex. Second, the only options without a lock-in caveat are the self-hosted ones, and their downside (engineering time) is a fixable problem, not a structural one. You can hire, train, or outsource the operations layer. You can’t undo Airflow being trapped inside a hyperscaler’s executor restrictions.

Now let’s actually look at each one.

What “managed Airflow” really means in 2026

Before the contender list, a short clarification. There are three shapes of managed Airflow on the market:

1. Hyperscaler-managed services: AWS MWAA, Google’s Managed Service for Apache Airflow, Microsoft Fabric’s Airflow Jobs. The cloud provider owns the infrastructure, you ship DAGs.
2. Independent SaaS: Astronomer Astro, DoubleCloud, Elestio. Cloud-agnostic, multi-cloud, often with extra product features (lineage, observability, RBAC).
3. Managed-by-a-partner: a consulting firm runs your Airflow on your cloud, on Kubernetes, with their SLA and engineers. This is what we do at Tasrie IT Services, but it’s a real category with multiple providers.

Most “vs” articles only compare category 1 and 2. The third path matters because the hyperscaler options are surprisingly restrictive at scale, and not every team has the DevOps capacity to self-host correctly.

OK, on to the services.

1. AWS Managed Workflows for Apache Airflow (MWAA)

What it is: AWS’s managed Airflow, fully hosted, integrated with IAM, VPC, S3, CloudWatch, Secrets Manager. As of 2026 it supports Apache Airflow 3.2, with the new asset-based scheduling and a “micro” environment size for cheap dev/test work.

Real cost:

• You pay for the environment by the hour, plus auto-scaled workers, plus the metadata DB storage.
• Small environment runs around $0.49/hr, large around $0.99/hr, with worker instances billed separately at hourly rates that vary by class (e.g., large worker is $0.22/hr in us-east-1).
• A representative small production environment lands around $350/month, medium ~$700/month, large ~$1,400/month, before worker scaling. See the official MWAA pricing page for the current rate card.

Pros:

• Tight AWS integration. IAM-based permissions, VPC endpoints, KMS-encrypted metadata, S3-backed DAG storage.
• 99.9% SLA, autoscaling workers, managed upgrades.
• Easy procurement if you’re already on an AWS EDP.
• Now keeps closer pace with upstream Airflow than it used to.

Cons:

• Celery executor only. No KubernetesExecutor, no CeleryKubernetesExecutor. If you need pod-per-task isolation, you’re stuck.
• No custom Docker images. You ship a requirements.txt and that’s it. System packages, custom Python builds, native binaries: not happening.
• DAG deploys go through S3, which means slower feedback loops than other options.
• Version support lags upstream by months. You’ll be on whatever AWS has blessed, not whatever Airflow shipped last week.
• Costs add up fast once workers scale.

Choose MWAA when: you’re AWS-only, your DAGs are pure Python with PyPI dependencies, you don’t need per-task pod isolation, and the procurement story (already on AWS) outweighs the executor limits.

Skip MWAA when: you need custom system libraries, KubernetesExecutor, multi-cloud, or fast access to brand-new Airflow features.

2. Google Cloud Managed Service for Apache Airflow (formerly Cloud Composer)

What it is: Google rebranded Cloud Composer to “Managed Service for Apache Airflow” in 2025 and shipped Gen 3, which hides most of the infrastructure (the underlying GKE cluster, the Cloud Storage bucket, the SQL metadata DB) behind a consumption-based pricing model. It’s the natural choice if your data lives in BigQuery, Dataflow, or Pub/Sub.

Real cost:

• Gen 3 prices by Data Compute Unit (DCU) hours, GB-months, and network egress. There’s no single “size” SKU.
• Real-world deployments: about $300/month for minimal, $500-$1,500/month for production. See Google’s pricing page for current rates.
• Cross-region or internet data transfer SKUs apply if you move data around, which is the surprise on the first bill.

Pros:

• Best-in-class BigQuery integration. The operators just work, the IAM model is consistent with the rest of GCP.
• DAG versioning and scheduler-managed backfills are clean in Gen 3.
• Supports Apache Airflow 3 in newer environments.
• Less restrictive than MWAA on environment customization.

Cons:

• Pricing is genuinely hard to estimate before you run a workload. Multiple SKUs, DCU math, network egress all stack.
• GCP-only. Not realistic for AWS or Azure workloads.
• Some users report the Gen 2 to Gen 3 migration is rough if you have a lot of historical state.
• Operator versioning can drift behind upstream.

Choose Cloud Composer when: you’re GCP-native, you live in BigQuery, and you want the orchestration to feel like the rest of your data stack.

Skip Cloud Composer when: you need predictable, line-item billing, or you’re on AWS/Azure.

3. Azure Data Factory Managed Airflow (Workflow Orchestration Manager): the one you shouldn’t pick

This is the big news most comparison posts miss.

What it is: Microsoft launched Workflow Orchestration Manager (their official name for Managed Airflow inside Azure Data Factory) a couple of years ago. As of Microsoft’s official guidance, you can no longer create new Airflow instances using ADF’s Workflow Orchestration Manager after January 1, 2026, and existing customers are being pushed to migrate to Apache Airflow jobs in Microsoft Fabric before December 31, 2025.

Real cost (legacy):

• Small node (D2v4, up to 50 DAGs): $0.49/hr. Large (D4v4, up to 1000 DAGs): $0.99/hr.
• Additional nodes: $0.055/hr (small), $0.22/hr (large).

Should you pick it: No. New deployments aren’t possible. Existing ADF Managed Airflow workloads need to move.

Where to go instead if you’re on Azure:

• Microsoft Fabric Apache Airflow Jobs is the official successor. Pricing is based on Fabric Capacity Units. Each Airflow job runs in its own pool. The Starter pool gives zero-latency startup and auto-shuts after 20 minutes of inactivity; the Custom pool stays up for production. You pay for pool uptime in CU-hours.
• Astronomer on Azure runs cleanly on AKS, gives you a fully managed Airflow without the Microsoft product roadmap risk.
• Self-hosted on AKS with a partner who knows the Azure-side networking gotchas.

This is the migration moment for Microsoft shops. We’ve covered the Azure migration angle in more depth on the managed Airflow service page, but the headline is: if your DAGs are running on Workflow Orchestration Manager today, you’ve got a forced migration to plan.

4. Astronomer Astro

What it is: Astronomer is the company behind a lot of upstream Airflow development, and Astro is their managed product. It runs on AWS, Azure, or GCP, with a control plane that’s the same everywhere. It’s the closest thing to a “best-in-class Airflow SaaS.”

Real cost:

• Four tiers: Developer, Team, Business, Enterprise. See Astronomer’s pricing page for current rates.
• Developer plan: deployments start at $0.35/hr.
• Team plan: around $0.42/hr per deployment, plus features like network isolation, dedicated clusters, 24x5 support, audit logging.
• Business and Enterprise: custom quote, with things like SCIM, custom RBAC, remote execution.
• Workers scale to zero when idle, so you only pay for compute while tasks are actually running.

Pros:

• Multi-cloud, including private cloud deployments through Astro Hybrid.
• Strong product features: Astro Observe (lineage, data product SLAs, AI-assisted RCA), local dev parity, opinionated CI/CD.
• Same-day support for new Airflow versions, since Astronomer ships a lot of upstream code.
• Best-in-class developer experience for teams who want Airflow as a product, not a toolkit.

Cons:

• Cost climbs fast once you’re running multiple environments. Multi-team setups can hit five figures monthly.
• Opinionated runtime. If your DAGs assume specific OS images or system libraries, you’ll be working within Astronomer’s constraints, not yours.
• Some teams find the abstraction over Kubernetes a feature, others find it limiting.

Choose Astronomer when: you want a real product (not just managed infra), multi-cloud is a hard requirement, your team will use the platform features (observability, RBAC, lineage), and budget isn’t the binding constraint.

Skip Astronomer when: you need deep customization of the underlying compute layer, or your scale makes the per-deployment hourly cost uneconomic.

5. DoubleCloud Managed Airflow

What it is: A managed Airflow service that gives you dedicated clusters by default, with data residency options across AWS, GCP, and their own infrastructure.

Real cost: dedicated cluster pricing varies by region and size. Check DoubleCloud’s managed Airflow page for current details.

Pros:

• Dedicated isolation comes standard, which is unusual at the price point.
• Reasonable choice for teams who want managed Airflow without the Astronomer feature surface or price tag.
• Multiple cloud regions, with European data residency options that matter for EU customers.

Cons:

• Smaller ecosystem than Astronomer. Fewer integrations, fewer community resources, smaller support team.
• Less hyperscaler-native than MWAA or Cloud Composer (no deep IAM, no native VPC niceties).
• Roadmap is harder to predict than the bigger vendors.

Choose DoubleCloud when: you want dedicated, isolated managed Airflow without the Astronomer pricing, or you have European data residency requirements.

Skip DoubleCloud when: you need deep hyperscaler integration or a large community to lean on.

6. Self-hosted Airflow on Kubernetes

This is where things get interesting. Most teams who can do this cheaply, should.

What it is: Apache Airflow deployed on your own Kubernetes cluster (EKS, AKS, GKE, or on-prem), typically via the official Helm chart or a vendor-built one. You run the scheduler, the metadata database (usually managed Postgres), the workers (KubernetesExecutor or CeleryExecutor), and the web server yourself.

Real cost (infrastructure only):

• Production-grade Airflow on Kubernetes typically lands between $200 and $2,000/month in infrastructure depending on worker scale, metadata DB size, and HA setup.
• That looks very cheap next to MWAA’s $1,400 large environment, until you add the human cost.

Real cost (the human side):

• Industry rule of thumb: 0.25 to 0.5 FTE of DevOps engineering time to run Airflow on Kubernetes well at production scale. That covers upgrades, monitoring, scheduler tuning, DAG parsing performance, scaling rules, security patching, metadata DB maintenance, and on-call.
• At a senior DevOps loaded cost of $180k/year, 0.5 FTE is $90k/year. That’s $7,500/month in headcount alone, on top of your $200-$2,000 infrastructure bill.
• The teams who run this well have either deep Kubernetes experience already (so the marginal cost is low) or a managed Kubernetes partner handling the platform layer.

Pros:

• Full control. Any executor, any Docker image, any Python library, any scheduler config.
• Cheapest infrastructure cost for medium-to-large workloads at scale.
• Multi-cloud, no vendor lock-in.
• Direct access to logs, metrics, the metadata DB. You can fix things immediately when they break.
• You upgrade when you want, on your testing cadence. Useful if you’ve been planning the move off Airflow 2 before its end-of-support deadline, or are mid-migration to Airflow 3 (we wrote a detailed Airflow 2 to 3 migration guide on Kubernetes covering DAG API changes and metadata DB cutover).
• GitOps-driven DAG deployments via ArgoCD or Flux feel cleaner than uploading to S3.

Cons:

• The hidden costs are real. Most teams who choose self-hosted to “save money” underestimate the engineering time by 2-3x.
• Single bus-factor risk. If your one Airflow expert leaves, you’re in trouble.
• Security and compliance is your problem now. RBAC, secrets, audit logs, network isolation: all DIY.
• Disaster recovery testing has to happen, and rarely does.

Choose self-hosted Kubernetes when: you already have a strong DevOps or platform engineering team, your scale makes managed services genuinely expensive, you need customization the hyperscalers don’t allow, or you’re multi-cloud.

Skip self-hosted Kubernetes when: your team is two data engineers and a single platform engineer, your workload fits cleanly in MWAA or Composer, or your “savings” math doesn’t include the FTE cost.

If self-hosted is appealing but you don’t have the headcount, this is the spot where a managed-by-partner setup actually pencils out. You get the customization of self-hosted with someone else’s on-call rotation, often for less than your loaded FTE cost.

7. Self-hosted Airflow on-prem (bare metal or private cloud)

Smaller market, but it exists for good reasons.

What it is: Airflow on physical servers or a private cloud (VMware, OpenStack, etc.), with metadata DB, workers, and scheduler all running in your own data center. Often deployed for installing Airflow directly on Linux hosts where Kubernetes isn’t an option.

Real cost:

• Capex on hardware (refreshed every 3-5 years), facility costs, plus the same 0.25-0.5 FTE for ongoing operations.
• For most workloads this is more expensive than self-hosted on Kubernetes in the cloud, because the cloud version can scale to zero and you can’t.

Pros:

• Complete data sovereignty. Nothing leaves your network.
• Suitable for air-gapped environments (defense, regulated healthcare, financial services with hard data residency rules).
• No surprise cloud bills.

Cons:

• Slowest velocity of any option. Hardware lead times, manual scaling, no auto-scale to zero.
• Hardest to staff. You need people who understand both Airflow and on-prem operations, and that talent pool is shrinking.
• Disaster recovery is genuinely your problem.

Choose on-prem when: regulatory or sovereignty rules force it, you’re in an air-gapped environment, or you have an existing on-prem data platform and Airflow needs to live with it.

Skip on-prem when: you have the option to use cloud. Almost everyone does.

The total cost of ownership picture nobody draws

Here’s the math most “managed vs self-hosted” articles skip. Let’s compare three realistic scenarios at the same workload:

Scenario: 5 production DAGs, ~20 tasks/min peak, ~200 task runs/day, HA scheduler.

Option	Monthly infra	Engineering time	True monthly cost
AWS MWAA (medium env + workers)	~$900	~0.1 FTE for DAG dev and triage = ~$1,500	~$2,400
Cloud Composer (Gen 3 small prod)	~$700	~0.1 FTE	~$2,200
Astronomer Astro Team	~$1,200	~0.05 FTE (less ops work)	~$1,950
Self-hosted on EKS	~$400	~0.4 FTE for ops = ~$6,000	~$6,400
Self-hosted EKS + managed partner	~$400 + ~$3,000 partner	~0.05 FTE	~$4,150

Now the same math at real production scale.

Scenario: 50+ DAGs, multi-team, ~500 tasks/min peak, ~50k task runs/day, HA scheduler, 3 environments (dev, staging, prod).

Option	Monthly infra	Engineering time	True monthly cost
AWS MWAA (large env + heavy worker scaling, 3 envs)	~$5,500	~0.3 FTE (DAG dev, vendor escalations, workaround engineering) = ~$4,500	~$10,000
Cloud Composer (Gen 3 large, 3 envs)	~$4,800	~0.3 FTE	~$9,300
Astronomer Astro Business (3 deployments)	~$8,000+	~0.15 FTE	~$10,250
Self-hosted on EKS/AKS/GKE	~$1,800	~0.5 FTE for ops = ~$7,500	~$9,300
Self-hosted + managed partner	~$1,800 + ~$5,000 partner	~0.05 FTE	~$7,550

At this scale the picture inverts. Self-hosted with a managed partner is the cheapest true total cost, and pure self-hosted matches the hyperscalers on price while removing the lock-in. A few things jump out across both tables:

• Self-hosted is the cheapest infrastructure at every scale. It’s only the most expensive total cost at small scale, because the FTE overhead doesn’t amortize over a small workload.
• The crossover is sharper than people expect. By the time you’re running 30 to 50 DAGs across multiple teams, the hyperscaler bill is already at parity with self-hosted plus a partner, and you have less flexibility.
• The managed-by-partner option is the path most “build vs buy” articles miss. You get the customization, executor flexibility, multi-cloud portability, and no-lock-in upside of self-hosted, with someone else absorbing the 0.4 to 0.5 FTE of operations work. At anything above small scale, the math is hard to argue with.
• The hyperscaler “savings” disappear faster than vendors will tell you. MWAA looks cheap at $900/month until your workers scale 6x for daily backfills and you’re suddenly at $5,500.

If you want to dig deeper, Astronomer published their own TCO breakdown which is more thorough on the hidden cost side, and Datacoves wrote about the real cost of self-hosting Airflow + dbt which is the most honest piece we’ve read on this.

Decision matrix: when to choose what

Putting it all together. This is the matrix we use when scoping Airflow engagements. Note that “self-hosted (DIY or partner-managed)” shows up as the right answer in more rows than people expect, because it’s the one option that doesn’t trade away long-term flexibility for short-term convenience.

Your situation	Best fit	Second choice
AWS-only, simple Python DAGs, small team, won’t grow	MWAA	Self-hosted on EKS + partner
AWS, growing fast or already complex deps	Self-hosted on EKS (DIY or partner-managed)	Astronomer on AWS
AWS, need pod isolation, custom Docker images, or fast Airflow upgrades	Self-hosted on EKS	Astronomer
GCP-native, BigQuery heavy, simple stack	Cloud Composer (Gen 3)	Self-hosted on GKE + partner
GCP, complex DAGs, want optionality	Self-hosted on GKE (DIY or partner-managed)	Cloud Composer
Azure, currently on ADF Managed Airflow	Migrate to self-hosted on AKS (DIY or partner-managed)	Fabric Airflow Jobs as interim
Azure, greenfield	Self-hosted on AKS + partner	Astronomer on AKS
Multi-cloud, want a SaaS product feel	Astronomer Astro	Self-hosted on K8s + partner
Multi-cloud, want control and no lock-in	Self-hosted on K8s (DIY or partner-managed)	DoubleCloud
Regulated, data residency hard requirement, air-gapped	Self-hosted on-prem	Self-hosted private cloud K8s
Strong DevOps team, scale > 30 DAGs	Self-hosted on K8s	Self-hosted + partner for off-hours coverage
Small data team, no DevOps capacity	Self-hosted on K8s + managed partner	MWAA / Composer / Astronomer
Planning to be on Airflow 3+ years	Self-hosted on K8s (any flavor)	Astronomer

What we’d actually pick

Hard rules from running this for clients. We’ve inverted the way most articles order these. Start from “what gives you the most long-term optionality” and only step away when there’s a clear reason.

1. Default for any team that plans to be on Airflow longer than 18 months: self-hosted on Kubernetes. EKS, AKS, or GKE depending on which cloud you live in. You get every executor, custom Docker images, fast upstream version adoption, multi-cloud portability, and no lock-in. The only honest objection is operations capacity, and that’s solvable.
2. If your team can’t run Kubernetes Airflow on its own: self-hosted on Kubernetes with a managed partner. Same upside as #1, someone else’s pager. At anything above small scale, this is cheaper total cost than MWAA or Astronomer and removes the architectural ceiling.
3. If you’re regulated, sovereign, or air-gapped: self-hosted on-prem (with a partner if you don’t have the on-prem ops muscle). DoubleCloud’s EU regions if your residency requirement is European and your stack is mostly cloud already.
4. If you’re truly AWS-only, your DAGs are pure Python with PyPI deps, and you don’t expect to grow into complex orchestration: MWAA is the path of least resistance. Take it knowing you’ll want to migrate if your DAGs ever outgrow Celery or requirements.txt.
5. If you’re truly GCP-native and your work is BigQuery-heavy: Cloud Composer Gen 3 is good. Same caveat as MWAA: it’s the right call until your DAGs need flexibility you don’t have.
6. If you’re on Azure right now: you have a forced migration off Workflow Orchestration Manager. Don’t replace one Microsoft-managed Airflow with another (Fabric Airflow Jobs is new and the migration to self-hosted later is harder than doing it now). Use this moment to move to self-hosted on AKS, with a partner if needed.
7. If you specifically want Airflow as a SaaS product: Astronomer Astro. It’s the best in its category. Just go in eyes-open that you’re paying SaaS-product economics for what’s still Apache Airflow underneath, and that the budget pressure will eventually push you toward self-hosting anyway.

We’ve seen teams pick MWAA because the sticker was low, then spend a year working around requirements.txt and Celery before migrating to self-hosted on EKS. We’ve seen teams default to Astronomer because everyone else did, then build a business case to leave when the bill crossed $20k/month. The pattern is consistent: managed services are a great starting point and a constrained endpoint, and the teams that win long-term end up on self-hosted Airflow regardless of where they started.

The cheapest migration is the one you don’t have to do. If your time horizon is more than a year and a half, start where you’ll end.

What’s next: Airflow 3.x, asset scheduling, and the Microsoft migration

A few 2026 trends that will shape this decision in the next 12 months:

• Airflow 3.x adoption is accelerating. MWAA shipped 3.2 support in April 2026. Cloud Composer Gen 3 is on 3.x. Astronomer was first to market. If you’re still on Airflow 2.x, you’re running out of runway on end-of-support and should be planning the move. The Airflow 3.x asset-based scheduling model is genuinely a step change worth migrating for.
• The Microsoft Fabric migration. ADF Managed Airflow customers have a forced move ahead of them. If you’re one of them, don’t wait until December.
• The managed-by-partner category is growing. As the hyperscaler offerings get more restrictive and Astronomer gets pricier, the middle ground (someone runs your Airflow on your cloud, on Kubernetes, with their SLA) is the fastest-growing slice of the market we see.

If you want a comparison of how Airflow stacks up against other orchestrators in the same space, we wrote about Apache NiFi vs Airflow for data integration workloads, which goes deeper on when Airflow isn’t the right tool for the job.

---

Want self-hosted Airflow without owning the operations?

If you’ve read this far, you’ve probably landed on the same conclusion we have: self-hosted Airflow on Kubernetes (or on-prem if you’re regulated) is the right long-term answer for most serious teams. The catch is that “self-hosted” only pays off if someone actually runs it well. Most teams underestimate the FTE cost, and the migration off a hyperscaler-managed service once you’ve committed is painful.

Our managed Airflow services for Apache Airflow are built for exactly this gap. We deploy and operate self-hosted Airflow on your cloud (AWS, Azure, GCP) or on-premise, on Kubernetes, with full executor flexibility and custom Docker images. You get the architecture of a properly run self-hosted Airflow, without staffing a dedicated platform team for it:

• Architecture and selection: honest assessment of whether self-hosted Kubernetes is right for you, which executor (Celery, KubernetesExecutor, hybrid), which cloud, and which deployment topology. If MWAA or Composer is genuinely the right call for your situation, we’ll tell you.
• Migration off the hyperscalers: ADF Managed Airflow to self-hosted on AKS (urgent, given the deprecation), MWAA to self-hosted on EKS when you’ve outgrown Celery, Cloud Composer to self-hosted on GKE for cost or flexibility. Also Airflow 2 to 3 migrations and legacy Cron, Luigi, or Oozie cutovers.
• Production operations on your infrastructure: 24/7 monitoring with Prometheus and Grafana, scheduler tuning, DAG parsing performance, security hardening with RBAC and secrets backends, automated backups, and zero-downtime upgrades. Your DAGs run on your cloud account, in your VPC, with our SLA on the operations layer.
• Cost optimization: right-sizing, worker scaling rules, and executor selection that often cut the bill by 30 to 60% versus a poorly tuned MWAA or Composer setup.

We’ve run Airflow in every configuration listed in this post. If self-hosted is the right call for you (it usually is), we’ll run it for you. If a hyperscaler-managed service is actually better for your situation, we’ll tell you that too.

Talk to our Airflow team about self-hosted managed Airflow on your cloud →