When Amazon MWAA or self-hosted Airflow fits your team
Choose Amazon MWAA when you want AWS to run the Airflow environment and you can accept its supported versions and configuration limits. Choose self-hosted Airflow when you need control over executors, the metadata database, upgrade timing, and where your data and DAG code live. The managed option trades operating work for fewer choices, and the self-hosted option trades fewer choices for more operating work. Your decision is mostly about which of those trades your team can carry. MWAA Serverless is a separate product with its own billing model: it is billed per AWS Managed Task hour at one-second resolution with a one-minute minimum per task, so do not compare its cost with the instance-based environment rates on the same basis.
The managed route matters most when your data platform team is small, your workloads run inside AWS, and no one needs to choose executors or tune the scheduler. It also suits teams whose data residency rules are already satisfied by an AWS account they control. Self-hosting matters when you need the metadata database and executor choices to stay in your hands, when you run workloads across clouds or on-premises, or when you must control the timing of Airflow upgrades. Airflow 3 runs on PostgreSQL 14 to 18 or MySQL 8.0, 8.4 and Innovation releases, so confirm the managed environment's supported database and Airflow versions before you commit to a migration date.
Before choosing, check three things with AWS and in your own environment: which Airflow 3 patch versions MWAA currently offers, whether the executors and plugins your DAGs need are available in the managed configuration, and how your security team will review the Amazon MWAA pricing page line items for environments, workers, schedulers and metadata storage. Self-hosting shifts the upgrade, backup, scheduler resilience and patching work to your team, so decide who owns that rota before you pick it. Also confirm which Airflow 2 DAGs will need changes, since Airflow 2 reached end of life on April 22, 2026.
How the two hosting models compare on the factors that matter
This table compares Amazon MWAA and self-hosted Apache Airflow factor by factor, from who runs each component to where DAG code and data live. Read each row as a question to answer for your own team, then use the confirmation notes to check MWAA-specific limits with AWS before you decide.
| Factor | Amazon MWAA | Self-hosted Apache Airflow |
|---|---|---|
| Who operates the scheduler, web server, workers and metadata database | AWS provisions and runs the environment components. Your team manages DAGs, plugins, requirements and environment settings. Confirm with AWS which upgrades and failure recovery actions remain yours. | Your team provisions, patches, scales and recovers every component, including the scheduler, API server, workers and metadata database. |
| Billing model | Published US East (N. Virginia) rates cover environment hours, additional workers and schedulers per instance-hour at one-second resolution, and metadata database storage at $0.10 per GB-month (AWS MWAA pricing page). The pricing page's examples put a small environment at $0.49 per hour and a large environment at $0.99 per hour. | No Airflow license fee. You pay directly for compute, storage, networking and the staff time to run them. Costs are recurring infrastructure plus one-time build and handover work. |
| Executor options | Executor choice is set through the MWAA environment configuration. Confirm with AWS which executors and multi-executor setups each MWAA version offers before you design around one. | Choose among LocalExecutor, CeleryExecutor, KubernetesExecutor, EdgeExecutor, and AWS Batch and ECS executors. Since Airflow 2.10.0, several executors can run in one deployment. |
| Supported Airflow versions | AWS sets the Airflow versions offered in each environment. Confirm which Airflow 3 release is available and how fast AWS adds new patch releases. | You pick the version. Airflow 3.3.2 is current, and Airflow 2 reached end of life on April 22, 2026, so it receives no fixes. |
| Python and PostgreSQL prerequisites | Managed by AWS for each environment. Confirm the Python and metadata database versions your chosen MWAA release supports. | Airflow 3.3.2 supports Python 3.10 to 3.14 and PostgreSQL 14 to 18. MySQL 8.0, 8.4 and Innovation releases are also supported, but MariaDB is not. |
| Where DAG code and data reside | DAG code, plugins and requirements are stored in an S3 bucket in your AWS account. Task data processing happens wherever your tasks connect, and metadata is held in the managed database. Confirm the exact storage locations with AWS. | DAG code, the metadata database and logs sit wherever you deploy them, including your own data centers, air-gapped networks or any cloud account you control. |
| Version control and deployment path | DAGs are uploaded to the environment's storage location. Confirm with AWS the supported ways to sync from a Git repository and how rollbacks are handled. | DAGs ship through your own CI/CD and Git workflow, with full control over branch strategy, review gates and rollback. |
What Amazon MWAA charges for and what recurs
Amazon MWAA bills a recurring hourly rate for every environment that runs, whether or not any DAG executes. The Amazon MWAA pricing page gives its examples in US East (N. Virginia): a small environment at $0.49 per hour with small workers at $0.055 per hour, and a large environment at $0.99 per hour with large workers and additional schedulers at $0.22 per hour. Additional workers and schedulers are billed per instance-hour at one-second resolution, and metadata database storage is billed at $0.10 per GB-month. None of these charges is one-time. They accrue for as long as the environment exists, so an environment left running over a quiet period still costs money.
Environment size, worker count, scheduler count and metadata storage are the levers that move the bill. Adding workers or schedulers to absorb peak load adds instance-hours for as long as they stay up, and a larger environment class raises the base rate. Build your estimate from your own task volume, peak concurrency and how long each run holds a worker, then multiply through the published rates. Ask AWS to confirm current rates in your region, since the figures above are the pricing page examples and may change.
MWAA Serverless is a different model. It bills per AWS Managed Task hour at one-second resolution with a one-minute minimum per task, so cost follows the number of tasks you run rather than an environment that stays on. That suits bursty or infrequent workloads, but many short tasks can cost more than their runtime suggests because of the one-minute floor. Confirm how AWS counts a task and whether your DAG structure creates many short tasks before choosing between the two billing models.
Where your data and control sit in each model
Both models keep the workflow engine and its metadata inside infrastructure you can name, but the boundary of responsibility moves. The cards below cover where data lives, who controls access, how compliance evidence is produced and where DAG code and the metadata database sit, so you can check each one against your own requirements.
Data location and network boundary
With Amazon MWAA, the environment runs inside your AWS account, so task logs, metadata and DAG bundles stay in regions and VPCs you select. Self-hosted Airflow runs in your cloud account, your data center or an air-gapped network, and you define every egress path. Confirm which AWS region your environment uses, whether your workers need outbound access to external data sources, and how private networking is configured in each model.
Access and identity integration
MWAA uses AWS Identity and Access Management for control plane permissions, while the Airflow web interface and its roles are configured within the environment. A self-hosted deployment lets you attach your own identity provider and auth manager, which suits organizations with an existing SSO and role model. Check how each option maps your group memberships to Airflow roles and how you revoke access for departing staff.
Compliance evidence and certification
In either model, the controls and evidence for an assessment are your responsibility to prepare, including access reviews, change records and backup logs. Certifications and attestation reports come from independent auditors, not from the platform or from DeployOpen. Ask AWS which compliance programs its MWAA service is in scope for, and confirm how your auditor will accept evidence from a managed service versus one you operate.
Metadata database ownership
Airflow stores DAG runs, task states and connections in a metadata database. Self-hosting means you choose and back up PostgreSQL or MySQL, and the Airflow prerequisites note that MariaDB is not supported and SQLite should not be used in production. In MWAA, the metadata database is provisioned and billed as storage, so confirm backup, restore and retention behavior with AWS before you rely on it.
DAG code and deployment artifacts
In a managed environment, DAG files are uploaded to an Amazon S3 location that you manage, and changes flow through that bucket. In a self-hosted setup, DAGs usually live in a Git repository and reach the scheduler through your own CI/CD pipeline, which gives you review history and rollback. Decide which model matches your change control process, and confirm how your reviewers will trace a production DAG back to an approved commit.
What self-hosting Airflow asks your team to run
Self-hosting puts the scheduler, web server, workers and metadata database on your side of the fence, and each one needs an owner. The database is the first decision. The Airflow production deployment guide warns that the default SQLite backend is for testing only and can lead to data loss, so PostgreSQL or MySQL is the baseline for production. For Airflow 3.3.2, the prerequisites accept PostgreSQL 14 to 18 and MySQL 8.0, 8.4 or Innovation releases. MariaDB is not supported as a metadata database. Confirm the exact versions against the Airflow prerequisites page before you pick images, and size the database for your DAG and task volume with your own load tests.
Plan the runtime around the same prerequisites. The prerequisites list Python 3.10 to 3.14 and Kubernetes 1.30 to 1.35 for Airflow 3.3.2, and recommend at least 4 GB of RAM. Those figures are a floor for a single component, not a sizing plan. Check the scheduler's memory and CPU under your largest DAG set, and decide whether you will run more than one scheduler. Airflow supports multiple schedulers at once for performance and resiliency, coordinating through database row-level locks, so the database connection pool and lock behavior become part of your capacity review. Also decide who answers when a scheduler stalls, a worker pool backs up or a migration fails at 2 a.m.
Upgrades are recurring work that the managed service absorbs and self-hosting does not. Airflow 2 reached end of life on April 22, 2026, and gets no fixes, so any estate still on it is already carrying unpatched risk. Budget for planned upgrades, test DAGs against the new release in a staging environment, and check the upgrade guide for Airflow 3 changes before you move production. Your team pays for this in engineer time and in the staging infrastructure needed to test it. Ask your implementation partner or internal platform team to write down the upgrade cadence, the rollback path and the owner for each component before you commit to self-hosting.
What your team runs in each model
This table lists the day-to-day operating tasks and shows who carries each one under Amazon MWAA and under self-hosted Apache Airflow. Read each row as a question to put to AWS and to your own platform team, since the split depends on which MWAA environment class and Airflow version you choose.
| Operating task | Amazon MWAA | Self-hosted Apache Airflow |
|---|---|---|
| Environment provisioning | AWS creates and runs the environment. You choose environment size, networking and region, and confirm the setup with AWS. | Your team provisions hosts or Kubernetes resources, networking, and the scheduler, webserver and worker components. |
| Scaling workers and schedulers | You set worker and scheduler counts within MWAA limits. Extra instances bill per instance-hour at one-second resolution. | Your team sizes and autoscales workers and schedulers, and tunes executor capacity to match demand. |
| Metadata database operation and backups | AWS operates the metadata database. Storage bills at $0.10 per GB-month. Confirm backup, restore and retention behavior with AWS. | Your team runs PostgreSQL or MySQL, including high availability, backups, restores and storage growth. SQLite is not for production. |
| Airflow version upgrades | AWS offers a set of Airflow versions and sets their availability. Confirm which versions MWAA supports now and when each one reaches end of life. | Your team chooses the version, plans the upgrade path and tests DAGs against it. Airflow 2 reached end of life on April 22, 2026. |
| Executor configuration | Executor choice is limited to what MWAA exposes. Confirm which executors and any Kubernetes or ECS options are available in your environment. | Your team selects and configures executors, including CeleryExecutor, KubernetesExecutor or AWS Batch and ECS executors, and runs multiple executors when needed. |
| DAG deployment and version control | You upload DAGs and dependencies to the environment's S3 bucket. Confirm the supported CI/CD pattern and dependency handling with AWS. | Your team controls the deployment pipeline, Git workflow, image builds and rollback, and can pin exact dependency versions. |
| Monitoring and logging | CloudWatch integration is provided by the service. Confirm which metrics and logs you can export and retain. | Your team selects, configures and operates monitoring, log shipping and alerting for each component. |
| Security patching | AWS applies patches to the managed service. Confirm the patch windows, the Airflow versions covered, and your responsibility for DAG code and dependencies. | Your team patches the operating system, container images, database and Airflow itself, and tracks Airflow security advisories. |
Which executor and Airflow version path each model gives you
Teams that want each task to run in its own isolated container usually look at KubernetesExecutor, which starts a pod per task. This suits workloads with very different resource needs, where one heavy task should not share a worker with light ones, and where platform teams already run Kubernetes. Self-hosting gives you direct control over the cluster, node pools, images and resource requests for each task.
- Isolation: Each task gets its own pod, so dependencies and memory limits stay separate.
- Startup latency: A new pod is created for each task, so short tasks wait for scheduling and image pulls.
- Cluster ownership: You operate the Kubernetes cluster, its upgrades and its autoscaling when self-hosted.
- Version support: Airflow 3.3.2 lists Kubernetes 1.30 to 1.35 as prerequisites, so check your cluster version against that range.
- Managed options: Confirm whether MWAA exposes KubernetesExecutor for your chosen Airflow version before you plan around it.
Confirm with AWS which executor types MWAA offers today, since the Airflow executor documentation is the reference for what open-source Airflow supports.",
CeleryExecutor sends tasks to a queue and runs them on long-lived workers that share a broker. This model suits teams with many short tasks, a steady workload and existing expertise in running worker fleets. Startup is faster than pod-per-task because workers are already running, but tasks share the worker environment, so dependency conflicts and noisy neighbors need attention.
- Queue control: You can route tasks to named queues and size worker pools for each queue.
- Shared environment: Tasks on the same worker share installed packages and resources.
- Broker and workers: You operate the message broker and the worker processes yourself when self-hosted.
- Scaling model: Worker counts are your decision, which gives control over cost but also responsibility for capacity.
- Hybrid options: CeleryKubernetesExecutor is no longer supported as of Airflow 3.0.0, so plan a single executor per deployment path.
Ask the managed provider how worker sizes, queue configuration and the broker are exposed before assuming your Celery setup can be reproduced exactly.",
Airflow ships AWS Batch and Amazon ECS executors, which send each task to AWS-managed compute. These fit teams already standardized on AWS container services who want task execution in those services rather than in a Kubernetes cluster or Celery workers. The question is less about the executor itself and more about whether your managed environment exposes the same executor and version combination you need.
- Native AWS placement: Tasks run on Batch or ECS capacity in your AWS account.
- Task definitions: Each task needs a container definition and the IAM permissions it uses, which you maintain.
- Multiple executors: Since Airflow 2.10.0, several executors can run in one deployment, so a team can route some tasks to ECS and others elsewhere.
- Self-hosted control: Self-hosting lets you choose the executor configuration directly, including the ones MWAA may not expose.
- Version dependency: Executor availability depends on the Airflow version, so pair the choice with the version path below.
Confirm with AWS which Batch or ECS executor settings MWAA supports on your target version before you design task images around them.",
Airflow 2 entered limited maintenance on October 22, 2025 and reached end of life on April 22, 2026. Limited maintenance covered security and critical bug fixes only, and end-of-life versions get no fixes or support. If your estate still runs Airflow 2, the version path, not the executor, is the first decision, because a move to Airflow 3 changes how DAGs, executors and configuration behave.
- Current status: Airflow 2 is past end of life, so any remaining deployment carries unpatched risk.
- Major version change: Airflow 3 is a major upgrade, and the upgrade guide lists the changes to review before you move.
- Executor removals: CeleryKubernetesExecutor and LocalKubernetesExecutor are no longer supported as of 3.0.0, so hybrid setups need a new design.
- Managed version timing: Ask MWAA which Airflow versions it offers and when it moves environments off older lines.
- Self-hosted timing: You choose when to upgrade, but you also own the planning, testing and rollback work.
Confirm your current Airflow version, your executor configuration and the managed service's supported version list before you set an upgrade date.
How to move between MWAA and self-hosted Airflow
This sequence moves a working DAG estate from one Airflow deployment to the other without losing run history or connections. Each step ends with a check you can record, so the cutover decision rests on evidence instead of memory.
Inventory DAGs, plugins and Python dependencies
The platform or data engineering lead lists every DAG file, custom plugin, operator package and pinned Python requirement in the current MWAA environment, along with the Airflow version it runs. Export the requirements file and plugins archive from the environment's S3 bucket, then tag each DAG with its owner and its upstream and downstream systems. Done means you have a single inventory that maps each DAG to the packages and plugins it needs, and every DAG has a named owner who has confirmed the list.
Check Airflow 3 changes in the upgrade guide
Before building anything, the engineers who own DAG code read the official upgrading guide for Airflow 3 and flag every construct the inventory uses that changed. Pay particular attention to the removed hybrid executors, since CeleryKubernetesExecutor and LocalKubernetesExecutor are no longer supported as of Airflow 3.0.0, and to any direct database access or deprecated imports in DAG code. Done means each DAG is marked as unchanged, needs a code edit, or needs a redesign, and the team agrees on the list.
Rebuild the environment in the target model
The platform team stands up the self-hosted Airflow target on the chosen infrastructure, using a PostgreSQL or MySQL metadata database, since SQLite is not for production and MariaDB is not supported. Choose the executor deliberately, because MWAA's worker model and a Kubernetes or Celery executor behave differently, and rebuild the image with the pinned dependencies from step one. Done means a clean environment starts, the scheduler and webserver report healthy, and a trivial test DAG runs end to end.
Migrate connections, variables and secrets
Recreate connections, variables and secret values in the target, moving credentials through your own secrets store rather than copying plain text between systems. Rewrite any reference to MWAA-specific IAM roles, S3 DAG paths and environment variables, and replace them with the identities and storage locations of the target. Done means every connection passes a test against its real system, and the security team has reviewed how secrets reach the workers.
Run DAGs in parallel and compare outputs
Run the migrated DAGs on the target while the MWAA environment continues to run them, and keep write-side tasks pointed at a staging destination or disabled until the comparison is complete. Compare row counts, output files, task states and run durations between the two platforms for the same logical dates. Done means each DAG has a recorded comparison result, and every difference is either explained by a known change or fixed and rerun.
Cut over schedules and confirm ownership
Pause each DAG on MWAA only after its parallel run has passed, then enable it on the target so that a single scheduler owns every schedule at any moment. Confirm alerting, on-call routes and retry behavior with the people who receive the notifications. Done means the target runs production schedules, MWAA runs are paused, and the owners have signed off on the new alert paths.
Decommission MWAA and export the record
Once a retention period agreed with your compliance team has passed, export run logs and any metadata you are required to keep, then delete the MWAA environment and its associated S3 bucket contents and IAM roles. Ask AWS to confirm which charges continue after deletion and whether the metadata database storage is removed. Done means the environment is gone, the export is stored where your evidence process requires it, and the bill reflects the removal.
Questions buyers ask before choosing a hosting model
What drives Amazon MWAA cost up or down, and what should I request in a quote?
MWAA cost is driven by environment class, the number of additional workers and schedulers, and metadata database storage. The MWAA pricing page's examples price a small environment at $0.49 per hour and a large environment at $0.99 per hour, both in US East (N. Virginia), with small workers at $0.055 per hour and additional schedulers at $0.22 per hour for the large example. Additional workers and schedulers bill per instance-hour at one-second resolution, and metadata database storage bills at $0.10 per GB-month. Those are recurring charges, so peak worker counts and hours of operation matter more than the base rate. Ask AWS or your partner for a quote that models your average and peak worker counts, your storage growth, and whether MWAA Serverless, billed per AWS Managed Task hour, fits your task volume. Confirm the current rates in your region on the Amazon MWAA pricing page.
How much effort does self-hosting Apache Airflow take, and can we do it without outside help?
Self-hosting moves the work of running the scheduler, workers, metadata database, upgrades and monitoring onto your team. The Airflow 3.3.2 prerequisites list Python 3.10 to 3.14, PostgreSQL 14 to 18 or MySQL 8.0, 8.4 and Innovation releases, and Kubernetes 1.30 to 1.35 where applicable, and the production guide recommends PostgreSQL or MySQL instead of the SQLite default. Running more than one scheduler is supported through database row-level locks, but you must configure and monitor it. Whether your team can do this alone depends on existing Kubernetes or Linux operations skills, on-call coverage and how often you plan to upgrade. Teams without that depth often use a fixed-scope implementation engagement for the initial build and hardening, then keep operations in-house or move to a retainer. DeployOpen plans, implements, hardens, backs up, upgrades and supports self-hosted platforms in your own infrastructure, with most engagements fixed-scope and agreed in writing.
How long does a move between MWAA and self-hosted Airflow take?
The duration depends on the number of DAGs, the custom operators and plugins they rely on, the connections and secrets they use, the Airflow major version you start from, and how much testing your pipelines need before cutover. We do not give a fixed duration here because it changes with those inputs. Start by inventorying DAGs, providers and environment variables, then decide whether the target is Airflow 3 or another version. Ask any partner for a written scope with milestones, a test plan and a cutover approach, including how you will run both environments in parallel. Scope and timing should be agreed before work begins, which is how DeployOpen engagements are usually structured.
Does our data stay in our own AWS account with MWAA, and where does it live when we self-host?
With MWAA, the environment runs inside your AWS account, so workflow metadata and the managed metadata database sit in that account and you pay for its storage at $0.10 per GB-month. With self-hosted Airflow, the scheduler, workers, metadata database and logs sit wherever you deploy them, which can be your cloud accounts, your data centers or an air-gapped network. In both cases the pipelines' business data stays where your connections point, because Airflow orchestrates tasks rather than storing your tables. Confirm with the vendor which logs, task metadata and XCom values are written to the metadata database or to external storage, and where backups are kept. Those answers decide your data residency position more than the hosting label does.
Can we keep the same DAGs if we switch between MWAA and self-hosted Airflow?
In most cases, yes, provided both sides run the same Airflow major version and the same provider packages. DAG files are Python code, so they can move through your version control system unchanged when versions match. The differences show up in the surrounding setup: how DAG files are synced, how connections and variables are stored, which plugins and requirements are installed, and which executor runs your tasks. Self-hosting gives you direct control of executors, including CeleryExecutor, KubernetesExecutor and, since Airflow 2.10.0, several executors in one deployment, while managed environments constrain which of these you can change. Check your DAGs against the Airflow 3 upgrade notes before assuming portability, and keep your DAG repository as the source of truth.
Do our Airflow 2 DAGs need changes before we move to either hosting model?
Usually yes. Airflow 2 reached end of life on April 22, 2026, so it receives no fixes, and Airflow 3 was first released on April 22, 2025. Moving to Airflow 3 requires reviewing removed or changed features, such as the hybrid CeleryKubernetesExecutor and LocalKubernetesExecutor, which are no longer supported as of Airflow 3.0.0. Direct imports of deprecated modules, context variables and provider packages may also need updates. The Airflow upgrade guide for Airflow 3 lists these changes, and you should run your DAGs against a test environment before cutover. This applies to both paths, so the choice of hosting model does not remove the need for that review.
What should we check about upgrades and support windows in each model?
With either model, you own the decision to upgrade, but the support window is set by Airflow's version life cycle. Airflow versions in limited maintenance receive security and critical bug fixes only, and end-of-life versions receive no fixes, as Airflow 2 did after April 22, 2026. Under MWAA, ask AWS which Airflow versions it offers and how long each is supported, since upgrades on the managed side follow AWS's schedule. Under self-hosting, you choose the version and timing, which gives control but requires your own upgrade testing and rollback plan. Ask any implementation partner to define upgrade work and retainer coverage in writing so responsibilities are clear.
When outside help changes the self-hosting decision
Self-hosting Airflow is a decision about who carries the operating work, and outside help changes the answer when your team has the Airflow skills but not the spare hours. A fixed-scope engagement from DeployOpen starts with written scoping: which Airflow version you will run, where it lives (your cloud account, a data center or an air-gapped network), how many environments you need, and which executor fits your workloads. Deployment work then covers the scheduler, the DAG processor and API server, the metadata database, and the executors you select. Because Airflow 2 is past end of life, the scope should also state whether any existing Airflow 2 DAGs need migrating before go-live.
Several items belong in the written scope because they are the work that MWAA hides from you. Expect the statement of work to name the metadata database configuration (PostgreSQL or MySQL, since SQLite is for testing only), backup and restore procedures for that database, the upgrade path to future Airflow releases, and the documentation your operators will use on day two. Ongoing support, upgrades and continuous testing are available as retainers, so ask whether you need a one-time build, a recurring retainer, or both. Confirm with any provider which of these items sit inside the fixed scope and which are priced separately.
DeployOpen does not publish a price list. A quote follows from the written scope, so the cost depends on the environments, executors, data locations and support terms you specify. Ask for each cost component to be listed separately: the one-time build, the migration of any existing DAGs, the retainer and the infrastructure you will pay for directly. Also be clear about what DeployOpen does not do. It prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies do that work, so plan that engagement separately.
How DeployOpen scopes and runs self-hosted Airflow
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own cloud accounts, data centers or air-gapped networks. For the choice between Amazon MWAA and self-hosted Apache Airflow, that means the work starts from where your data, identity and network controls must sit, then sizes the Airflow footprint to match.
How we scope
- Scope covers your Airflow version, executor choice, metadata database and the network paths each one needs.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
- A quote follows from the written scope, so ask us to list every component and who operates it.
How we build
- We deploy Airflow in your own accounts or clusters, with the scheduler, workers and database configured for production.
- We integrate identity, secrets, logging and alerting with your existing tooling and document each connection.
- We test DAG behavior, failover and upgrade paths in a non-production environment before cutover.
How we hand over
- You receive architecture, runbooks, backup and restore procedures and an upgrade plan written for your team.
- We walk your operators through routine tasks such as scaling workers, rotating credentials and reviewing logs.
- Evidence for compliance assessments is prepared as documentation, while independent auditors issue any formal opinion.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainer scope, response expectations and included upgrades are confirmed in writing, so ask for them in the quote.
- Upgrade work follows the Airflow support policy for your version, which we review with you before each change.
