Astronomer vs self-hosted Apache Airflow: Cost and control

When a managed Airflow service fits and when self-hosting fits

If your team still runs Airflow 2 workloads, the hosting decision has a deadline attached: Airflow 2 reached end of life on April 22, 2026, so it gets no fixes, and the upgrade path to Airflow 3 is the first thing to plan. Astro fits teams that want Astronomer to run the scheduler, the metadata database and the upgrade calendar, and that have no hard requirement to keep the control plane inside their own network. It matters most when your data engineers are the constraint, not your platform team, because the cost of the operations work moves to a vendor invoice. Ask Astronomer which Airflow versions and upgrade windows apply to your plan, and whether the per-hour deployment and worker rates on the Astronomer pricing page cover your expected pipeline hours.

Self-hosting fits teams that must keep Airflow inside their own accounts, data centers or air-gapped networks, that want to choose and tune executors such as CeleryExecutor or KubernetesExecutor, or that need to set their own upgrade calendar. The trade is operational: you own the PostgreSQL or MySQL metadata database (SQLite is for testing only), the schedulers, the executor workers and every Airflow major and minor upgrade. Multiple schedulers are supported for resiliency through database row-level locks, but you must size and monitor them yourself. Confirm that your platform team can staff this on-call load before you commit.

Astronomer Private Cloud is the middle path. It runs Airflow as a service inside your own environment and supports air-gapped deployment, so it can address data location requirements without your team building every component from scratch. It does not remove the cost question: the pricing page lists Private Cloud at quoted pricing, so the license, support and infrastructure costs must come from a written quote. Ask what Astronomer operates versus what your team operates, how upgrades are delivered into a disconnected site, and which Airflow versions the product supports.

How Astro and self-hosted Airflow compare on the factors that decide the choice

This table compares Astronomer's published Astro rates and tiers with running Apache Airflow yourself across cost, licensing, database support, executors and upgrades. Read each row as a question to put to both options, and note where a cell says the figure must come from a quote.

Factor	Astronomer (Astro)	Self-hosted Apache Airflow
Published rates	Developer deployments from $0.35 per hour and Team deployments from $0.42 per hour (Astronomer pricing page). Workers from $0.13 per hour and dedicated clusters from $2.40 per hour on Team and above.	No vendor rate card. You pay for the compute, storage, database and staff that run the scheduler, webserver, workers and metadata database in your own environment.
Top tiers and private deployment	Business, Enterprise and Enterprise Business Critical are priced on request under annual agreements. Astro Private Cloud runs Airflow in your environment, with air-gapped support, at quoted pricing.	Your own infrastructure, including air-gapped sites, with no subscription fee to Astronomer. Ask your team what the platform engineering hours to run it would cost.
License	Astro is a commercial service built on Airflow. Confirm with Astronomer which terms govern the managed and Private Cloud offerings.	Apache Airflow is Apache-2.0 licensed. The Apache Software Foundation project has no paid edition.
Metadata database	Managed by Astronomer as part of the service. Confirm the database engine, version and backup terms in the contract.	You choose PostgreSQL 14 to 18 or MySQL 8.0, 8.4 or Innovation releases for Airflow 3.3.2. MariaDB and SQLite are not supported for production.
Executors	Confirm which executors and worker types are offered on each tier, including remote execution agents under Enterprise.	You select from LocalExecutor, CeleryExecutor, KubernetesExecutor and others. Since Airflow 2.10.0, several executors can run in one deployment.
Scheduler high availability	Scheduler operation is handled by the service. Ask how scheduler restarts and failover are handled in your tier.	Airflow supports more than one scheduler at once, using database row-level locks. You configure, size and monitor them.
Upgrade ownership	Astronomer handles platform upgrades as part of the service. Confirm the Airflow version schedule and your change window in writing.	Your team owns every upgrade. Airflow 2 reached end of life on April 22, 2026, so any estate still on it needs a migration to Airflow 3.
Data location	Data stays in the cloud environment Astronomer operates for you, or in your own environment under Private Cloud. Confirm where task logs and metadata live.	Everything stays in infrastructure you control, which suits teams with strict residency or air-gap rules.
Who you pay and what recurs	Hourly deployment, worker and cluster charges recur for as long as the environments run. Annual agreements apply to the higher tiers.	Recurring infrastructure and staff time, with no vendor fee. The main one-time cost is the initial build, configuration and integration work.

Which hosting model suits which environment

Astro public cloud suits teams with no regulatory requirement to keep Airflow in a specific location and that want Astronomer to run the managed service. Astronomer's pricing page lists Astro Developer deployments from $0.35 per hour and Team deployments from $0.42 per hour, with Business, Enterprise and Enterprise Business Critical priced on request under annual agreements. You gain managed operation and no scheduler or database to size yourself, but your DAG code, logs and metadata run on infrastructure Astronomer operates, so data location becomes a contract question.

Published starting rates: Deployments start at $0.35 per hour (Developer) and $0.42 per hour (Team), according to the pricing page. Your actual rate depends on the tier and deployment size you need.
Worker and cluster charges: Workers start at $0.13 per hour, and dedicated clusters start at $2.40 per hour on Team and above. Ask which combination your workload requires.
Storage charges: Extra ephemeral storage is priced at $0.0002 per GiB per hour, so large temporary datasets raise the monthly total.
Shared responsibility: Astronomer runs the managed platform, while your team still owns DAG quality, connections and secrets handling.

Before you commit, confirm the hosting regions, data residency terms and support commitments in the written agreement, because the public pricing page does not describe them.

Where your data and access sit under each model

Buying Airflow as a service or running it yourself changes where task metadata, logs and credentials live, who can change the platform, and what evidence you can hand to an auditor. The cards below cover the questions to settle before you sign, and each one names what to confirm in writing with Astronomer or check in your own environment.

Task metadata and logs

Airflow stores DAG run state, task history and connection references in its metadata database, and task logs go wherever your logging configuration sends them. Under Astro you need to confirm in writing which region, account and storage hold the metadata database, the logs and any remote execution artifacts. Under self-hosting, the location is whatever your own database and log store are. Ask for the exact list of data classes that leave your network.

Administrative access

With a managed service, Astronomer staff operate the control plane, so the question is which of their roles can reach your deployments and under what approval. With self-hosting, every administrator on the Kubernetes cluster, database host and Airflow deployment is your staff or your contractor. Document who holds cluster-admin, database superuser and Airflow admin rights, and how each grant is reviewed.

Identity and SSO integration

Confirm which identity provider and protocol the managed control plane accepts, and whether role mappings to Airflow permissions are configurable by you. Self-hosted Airflow uses the auth manager you configure, so SSO, group mapping and offboarding depend on your own integration work. Test deprovisioning end to end, because a removed user should lose access to the UI, API and any service tokens at the same time.

Audit evidence you produce

Auditors will ask who changed a DAG, a connection or a deployment setting and when. Under a managed service, request the audit log scope and retention period in writing and confirm whether you can export it. Under self-hosting, you collect evidence from Git history, the Airflow audit log, Kubernetes events and database logs, and you own their retention and integrity. Decide early where this evidence is forwarded.

Data location and residency terms

Compliance frameworks often ask where regulated data is processed and stored, and which subprocessors touch it. Ask Astronomer for its data residency terms, subprocessor list and current attestation reports, and check that they cover the regions you need. Independent auditors decide what assurance those reports give you. Self-hosting keeps location decisions in your own hands but makes you document every component that stores data.

Air-gapped and private options

Astronomer's pricing page lists Astro Private Cloud, which runs Airflow in your own environment with air-gapped deployment support, at quoted pricing. Confirm which components phone home for licensing, updates or telemetry, and whether they work with no outbound connectivity. If you self-host in an air-gapped network, you must mirror container images, Python packages and Airflow releases internally and maintain that mirror yourself.

What you keep when you self-host the scheduler, database and executors

When you self-host Airflow, the scheduler, metadata database and executor are yours to run, and the choices you make there determine how much of the operating load you carry. Running more than one scheduler at the same time, which Airflow supports for performance and resiliency, depends on database row-level locks. That makes the metadata database the foundation of the setup. Airflow 3.3.2 lists PostgreSQL 14 to 18 and MySQL 8.0, 8.4 and Innovation releases as supported backends, while MariaDB is not supported as a metadata database. SQLite should not be used in production, and the production guide warns that the default SQLite backend can lead to data loss. Confirm which database major version your team will standardize on, check it against the prerequisites page, and plan for at least 4 GB of RAM for the components recommended by the Airflow project.

Executor choice is the second decision, and it is one Astro's managed workers and dedicated clusters abstract away. Airflow ships LocalExecutor, CeleryExecutor, KubernetesExecutor, EdgeExecutor, and AWS Batch and ECS executors. Since Airflow 2.10.0, several executors can run in one deployment, so you can route different tasks to different execution environments. The hybrid CeleryKubernetesExecutor and LocalKubernetesExecutor are no longer supported as of Airflow 3.0.0. If an existing Airflow 2 estate depends on either hybrid, that configuration must be redesigned before the upgrade, and the redesign belongs in your migration plan. Ask Astronomer, or your own platform team, which executor model they would run for your task profile and what that means for worker capacity and queue handling.

What your team runs in each model

This table lists the recurring operating tasks for Airflow and shows who carries each one under Astro tiers versus self-hosting. Read each row as a question to ask Astronomer: which tier, if any, moves that task off your team, and what remains in your contract or runbook.

Ongoing task	Astro (Developer, Team, Business, Enterprise)	Self-hosted Apache Airflow
Scheduler and webserver availability	Astronomer operates the hosted deployment components; confirm per tier which availability commitments and support hours appear in your agreement	Your team designs, monitors and restarts scheduler and API server processes, and decides how many schedulers run at once
Metadata database backups and failover	Astronomer manages the metadata database for hosted deployments; confirm backup frequency, restore testing and recovery objectives in writing	Your team owns backups, restore tests, failover design and any database upgrades for PostgreSQL or MySQL
Executor scaling and worker images	Workers and dedicated clusters are billed by the hour (Astronomer's pricing page); scaling choices are made within Astro's platform options	Your team chooses the executor, sizes workers or Kubernetes pods, and builds and patches the worker images
Security patching	Astronomer patches the hosted platform; you still own DAG code, connections and dependencies in your own repository	Your team patches the OS, Kubernetes nodes, database, Python runtime and Airflow packages on your own schedule
Airflow 3.3.2 upgrades	Astronomer handles platform-side upgrades; confirm the upgrade windows and how DAG compatibility testing is supported	Your team plans and tests each Airflow minor or patch release, including the Airflow 3 migration work from Airflow 2
Python 3.10 to 3.14 and Kubernetes 1.30 to 1.35 compatibility	Astronomer selects the runtime images it supports; confirm which Python and Kubernetes versions your deployment runs	Your team matches Python and Kubernetes versions against the Airflow 3.3.2 prerequisites and retests dependencies
Monitoring and alerting	Astronomer provides platform monitoring; confirm which metrics, log exports and alert routes you can reach from your own tools	Your team builds the monitoring stack, scheduler health alerts, database metrics and task failure routing
Data location and network controls	Hosted Astro keeps the platform in Astronomer's environment; Astro Private Cloud runs Airflow in your own environment, including air-gapped sites (quoted pricing)	Your team controls where the metadata database, workers and logs sit, including air-gapped networks

Moving between self-hosted Airflow and Astro without a rewrite spike

This sequence lets a team move DAGs, connections and schedules between self-hosted Airflow and Astro in stages, so each step can be checked against a running copy before the old environment is retired.

Confirm the Airflow version and executor
The platform engineering lead records the Airflow version, the executor in use and any executor configuration the DAGs depend on. Airflow 2 reached end of life on April 22, 2026, so an Airflow 2 estate needs a DAG review against the Airflow 3 upgrade guide before any move. Hybrid CeleryKubernetesExecutor and LocalKubernetesExecutor setups are no longer supported as of Airflow 3.0.0 and must be redesigned first. Done when the team has a written inventory of version, executors, custom operators and plugins.
Choose the target tier and deployment model
The team and its finance owner decide between Astro's hosted tiers and Astro Private Cloud, which runs in the customer's own environment and supports air-gapped deployment. Astronomer's public pricing lists per-hour rates for deployments, workers and dedicated clusters, while Private Cloud is quoted, so the decision needs a written quote for the chosen model. Confirm with Astronomer which features each tier includes, such as remote execution agents under Enterprise. Done when the target tier and a quote are approved.
Export DAGs, connections and variables
The engineering team exports DAG source files from version control, then exports connections, variables and pools from the existing Airflow metadata database or its CLI. Exported connection secrets must be handled as sensitive material and kept out of shared repositories. Custom operators, hooks and plugins are inventoried separately because their compatibility determines the rewrite effort. Done when every DAG, connection and variable is listed in a repository the target can read.
Rebuild secrets and connections in the target
The security and platform teams recreate connections and secret backends in the target environment, using the target's own secrets store rather than copying values by hand into new configuration. Access rules for each connection are reviewed, since the auth manager and user roles may differ between the two environments. Confirm the target's auth manager and audit capabilities with Astronomer before relying on them. Done when each connection passes a test run in the target and access reviewers have signed off.
Run DAGs in parallel
The team deploys the same DAGs to the target while the self-hosted scheduler keeps its schedules active, and pauses the target schedules so that only one environment writes to downstream systems. Outputs from both environments are compared for each DAG over several scheduled runs, including failure and retry paths. Any operator that behaves differently is fixed before cutover. Done when every DAG has matching outputs and a recorded test result.
Cut over schedules to the target
The team disables schedules in the self-hosted environment and enables them in the target during a planned change window agreed with data consumers. Alerting and on-call routes are switched at the same time, and a rollback path back to the self-hosted schedules is written down before the switch. Done when the target runs the production schedules and the first scheduled runs complete without manual intervention.
Retire the old metadata database
After a retention period agreed with the data owners, the team exports a final backup of the self-hosted metadata database and its logs, then decommissions the scheduler, workers and database. The backup is stored under the organization's retention policy, and access to it is limited. Done when the backup restore has been tested and the old environment is removed from the inventory.

How the Astro bill and self-hosting costs add up

Astro bills recurring hourly rates for each thing it runs, so your invoice moves with how many deployments you keep alive, how many workers they draw and how much dedicated cluster capacity you reserve. Astronomer's pricing page lists Astro Developer deployments from $0.35 per hour, Team deployments from $0.42 per hour, workers from $0.13 per hour, dedicated clusters from $2.40 per hour on Team and above, and extra ephemeral storage at $0.0002 per GiB per hour. Before you multiply anything, list every deployment (dev, test, prod, per-team), estimate the worker hours each one needs at peak and idle, and decide whether any workload justifies a dedicated cluster. Those three inputs drive the bill far more than the list price does. Self-hosting replaces that metered line with costs you carry yourself: the compute and storage in your own cloud or data center, a PostgreSQL or MySQL metadata database that you size, back up and patch, the staff hours to run the scheduler, executors and upgrades, and any paid support contract you add. Airflow itself carries no license fee, since the Apache Software Foundation offers no paid edition. Ask your team to cost the Airflow 2 to Airflow 3 migration as well, because that effort lands on whichever path you choose. Private Cloud and the Enterprise tiers are priced on request, and Astronomer's page does not publish those numbers. Request a written quote that states the support scope and response commitments, the SLA terms, who performs upgrades and on what cadence, who patches the underlying Kubernetes and database layers, whether air-gapped deployment support is included, and what happens to pricing if your deployment count or worker hours grow. Compare those line items with your own staff time, not just the per-hour rates.

Questions buyers ask before choosing Astro or self-hosting

Can a small team self-host Airflow without a dedicated platform engineer?

Yes, a small team can run Airflow itself, but someone has to own the scheduler, the metadata database, the executor and the upgrade path. Airflow's prerequisites recommend at least 4 GB of RAM, and its production guide says the default SQLite backend is for testing only and that PostgreSQL or MySQL is recommended. Airflow 3.3.2 supports PostgreSQL 14 to 18, MySQL 8.0, 8.4 and Innovation releases, and Kubernetes 1.30 to 1.35, so the team must pick versions, back up the database and keep the stack patched. The real question is whether the people who will carry that work have time for it alongside pipeline delivery. If nobody does, a managed option or an outside operations partner deserves a fair comparison.

How long does moving from self-hosted Airflow to Astro take?

The duration depends on how many DAGs exist, how much custom code and provider configuration they depend on, how connections and secrets are handled, and how many environments must be matched. No migration duration is set by the researched facts, so ask Astronomer for a written plan based on your DAG count and dependencies. Plan the work as a parallel run, not a cutover: deploy the same DAGs to both environments, compare task results and schedules, then move ownership of each team's pipelines. Ask for the migration checklist, the list of Airflow features in use, and any executor or database changes the target environment requires.

What do Astro's published per-hour rates leave out?

Astronomer's pricing page lists Astro Developer deployments from $0.35 per hour and Team deployments from $0.42 per hour, workers from $0.13 per hour, dedicated clusters from $2.40 per hour on Team and above, and extra ephemeral storage at $0.0002 per GiB per hour. Those figures cover the listed components only. Business, Enterprise and Enterprise Business Critical are priced on request under annual agreements, and Private Cloud is quoted. Ask which items are billed per deployment, per worker-hour and per cluster-hour, how idle deployments are charged, what support tier is included, and what your own cloud egress, logging and data storage will cost outside Astronomer's bill.

Does Astro Private Cloud work in an air-gapped network?

Astronomer's pricing page states that Astro Private Cloud runs Airflow as a service in the customer's own environment and supports air-gapped deployment. Confirm the specifics in writing before you rely on it: which Kubernetes distribution and registry arrangement are supported, how images and updates reach a disconnected network, how licence and usage reporting works without outbound access, and who performs upgrades inside the enclosure. Remote execution agents are listed under Enterprise, so check whether your air-gapped design needs them. Your security team should also review where logs, metadata and secrets are kept inside the enclosure.

What does Airflow 2 end of life mean for an existing estate?

Airflow 2 reached end of life on April 22, 2026, so it receives no fixes or support from the project. Before that date it entered limited maintenance on October 22, 2025, when only security and critical bug fixes were provided. Any estate still on Airflow 2 is now running without upstream patches, which affects security posture and audit evidence. Airflow 3 was first released on April 22, 2025, and the upgrade guide covers breaking changes you must plan for, such as removed hybrid executors. Whether you move to Astro or self-host, the upgrade work and its testing remain your scope unless a contract says otherwise.

What work must our own team supply in either model?

Either model needs internal people who understand the business pipelines, data sources, connections, access rules and ownership of each DAG. In a managed service, the provider handles much of the infrastructure, but your team still writes and tests DAGs, manages secrets and access, reviews provider upgrades and signs off on changes that affect data. Self-hosting adds the scheduler, metadata database, executor, networking, backups, monitoring and Airflow version upgrades. Make a RACI table before comparing quotes so each task has a named owner, and ask every vendor to confirm which items sit inside their scope.

Can an outside partner run Airflow upgrades for us?

Yes, DeployOpen can support self-hosted platforms inside your own infrastructure, including upgrades, backups, hardening and documentation, usually under a fixed-scope agreement or a retainer for ongoing support and upgrades. Scope, deliverables and timelines are agreed in writing before work starts, and DeployOpen does not publish a price list, so a quote follows from that written scope. Ask any partner to state the Airflow versions covered, the upgrade test plan, the rollback method, the evidence produced for your auditors, and who is responsible if an upgrade fails in production.

Which vendor and Airflow pages to read before you decide

Start with the Astronomer pricing page and the Airflow version life cycle before you compare anything else, because the hourly rates only mean something once you know which Airflow major version you will run. Astronomer lists Astro Developer deployments from $0.35 per hour and Team deployments from $0.42 per hour, with workers from $0.13 per hour and dedicated clusters from $2.40 per hour on Team and above. Business, Enterprise and Enterprise Business Critical are priced on request under annual agreements. On the Airflow side, Airflow 2 reached end of life on April 22, 2026 and gets no fixes, while Airflow 3.3.2 is the current release. If your estate still runs Airflow 2, confirm with Astronomer which versions its managed deployments accept, and price the migration as part of the decision.

Next, read the Airflow prerequisites, production deployment, scheduler, executor and upgrading pages, because they describe the work you keep if you self-host. The 3.3.2 prerequisites name PostgreSQL 14 to 18 and MySQL 8.0, 8.4 and Innovation releases as supported metadata databases, exclude MariaDB, and advise against SQLite in production with at least 4 GB of RAM recommended. The scheduler documentation says you can run several schedulers against one database using row-level locks, and the executor documentation confirms that several executors can share one deployment since 2.10.0, while the hybrid CeleryKubernetesExecutor and LocalKubernetesExecutor are no longer supported as of 3.0.0. The upgrading to Airflow 3 guide sets out the code changes your DAGs may need. Your team owns the metadata database, executors and upgrades unless a managed tier takes them on.

Finally, put written questions to Astronomer, because the public pages do not answer the questions that matter most for regulated sites. Astro Private Cloud runs Airflow in your own environment with air-gapped deployment support, but its pricing is quoted, so ask for the fee structure and what is billed recurring versus one time. Ask exactly which air-gapped configurations are supported, which Airflow versions ship, and how upgrades and security patches reach a disconnected site. Confirm whether remote execution agents, which sit under Enterprise, are needed on your network. Request the data handling terms in writing: where task logs, connections and metadata are stored, who can access them, and how data is returned or deleted at exit. Use the written answers as the baseline for your quote comparison.

How DeployOpen scopes and runs self-hosted Airflow

DeployOpen plans, implements, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Airflow, that means we start from your environment and your team's skills, then write down exactly what you would run yourself before any work begins.

How we scope

Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
The written scope lists which Airflow components you run: scheduler, metadata database, executors, workers and the upgrade path.
We record where your DAGs, logs and connections would live, and which hosting and network boundaries apply to them.

How we build

We install Airflow on your chosen platform using a supported PostgreSQL or MySQL metadata database, not the SQLite default.
We configure the executor you select and document how tasks reach workers, including any multi-executor setup.
We test scheduler failover, task retries and DAG deployment in your environment before handing anything over.

How we hand over

You receive documentation of the deployed architecture, configuration decisions and the operational runbook for your team.
We walk your platform and operations staff through routine tasks such as upgrades, backups and version checks.
Written handover records show which responsibilities moved to your team and which remain under any ongoing agreement.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the build.
Retainer scope should name the Airflow versions covered, since limited-maintenance and end-of-life lines change what is safe to run.
Ask us to confirm the support window, response expectations and upgrade responsibilities in writing before you sign.

Astronomer (Astro) vs self-hosted Apache Airflow