--- title: >- Airflow in Action: Ontario Teachers Gives Every Team Autonomy With Astro Remote Execution description: >- Ontario Teachers’ Pension Plan replaced a shared Airflow monolith with Astro Remote Execution: team autonomy, in-cloud data and one control plane. date: 2026-10-21T00:00:00.000Z authors: - author: src/content/people/matthew-keep.md tags: [] categories: - customers canonical_url: 'https://www.astronomer.io/airflow/airflow-in-action-otpp/' --- Ontario Teachers’ Pension Plan runs Apache Airflow® so that each team ships on its own schedule, task data stays inside the organization’s own Azure environment, and the platform team still sees every workload from one control plane. At Airflow Summit 2026, Ontario Teachers [explained how it got there](https://airflowsummit.org/sessions/2026/breaking-the-monolith-implementing-airflow-3-x-remote-execution-for-multi-team-environments/): it replaced a shared Airflow environment that had become a bottleneck with Airflow 3 and Astro Remote Execution. This recap also draws on an earlier episode of [The Data Flowcast, Astronomer’s Airflow podcast](/podcast/running-airflow-3-in-a-regulated-environment-at-otpp/), and marks those details where they appear. ## Pension Data Stays Home Ontario Teachers invests across a broad range of asset classes on behalf of close to 350,000 working and retired Ontario teachers. Kowsy Narayan, Senior Solution Architect, presented the session and put one requirement above the rest: data cannot leave the organization's cloud. On The Data Flowcast, she explained what those pipelines deliver. Airflow sits between Snowflake and dbt in the cloud stack, orchestrating market data, and vendor feeds, along with order management and book-of-record data that drive the organization's daily trading and investment decisions. ## Buy the Platform, Build the Pipelines In 2024, Ontario Teachers began a multi-year move from on-premises systems to the cloud. After multiple proofs of concept, it selected Apache Airflow® for its active open source community and feature set. It then chose a managed service so the team could move fast without absorbing infrastructure overhead. Narayan told The Data Flowcast why that service was [Astro](/product/): * Astronomer is one of the strongest contributors to the Airflow project, so the platform is built by the people building Airflow. * [Astro Runtime](/docs/runtime/overview) releases follow new Airflow versions right away, so the team adopts new capabilities without waiting on its vendor. * Monitoring, observability and RBAC are native to the platform, so the team does not build or maintain them. Each of those removed work the team would otherwise own, enabling it to keep its focus on business value. ## The Monolith Bites Back Ontario Teachers could not size the platform up front, because some teams had only a handful of jobs to migrate and others had not started. Rather than build for a scale it could not predict, the team began with one shared Astro environment and one Git repository, putting fast onboarding ahead of isolation. The model started to break down as teams joined, and the platform team became the queue for every change. Separate Azure Key Vaults per team forced a custom multi-vault library, heavy workloads starved light ones, and CI/CD had to be split to manage bespoke Airflow-only and Airflow-plus-dbt pipelines. Release coordination became a standing tax on team leads. ## Centralize Control, Distribute Execution To fix those problems without giving up the single view of every pipeline that the shared model provided, the team defined four design goals for the next version of the platform: * A **single control plane** lets the platform team define, run and observe every workload in one place. * **Team autonomy** lets each team ship and deploy on its own schedule, without queuing behind the platform team. * **Execution isolation** runs every task in its own sandbox, so one team’s failure or heavy workload cannot affect another’s. * **Scalable governance** applies policy and controls consistently as more teams onboard. Airflow 2.9 offered no way to meet all four. Airflow 3 changed that by separating orchestration from execution, which is the foundation for [Astro Remote Execution](/docs/astro/remote-execution/remote-execution-overview): lightweight remote execution agents run in the customer’s own Kubernetes clusters and connect to Astro over outbound-only connections. Narayan cited four use cases that justify the model: secure access to sensitive data, bring-your-own compute, execution isolation and a simpler network. The last one let Ontario Teachers retire the VPNs, tunnels and firewall rules its hosted model required. The Data Flowcast interview provides more detail on the timeline. Remote execution was a requirement from day one, but Ontario Teachers had to go live on Airflow 2.9 before the capability existed. Because the team stayed close to the latest release, the upgrade to [Airflow 3](/airflow/3/) was straightforward, with upgrading utilities like the Astro CLI and linters catching deprecated libraries automatically. Narayan also noted that retiring the VPN tunnels removed latency they had added to data flows. On the podcast, Narayan described how the team de-risked the move. It turned its known pain points into success criteria. It then ran a four-to-six-week proof of value in a sandbox, with dedicated Astronomer product engineers helping configure the setup and validate real workloads. Because the capability was new, Ontario Teachers fed its findings back to Astronomer, and those changes shipped in subsequent releases. After executive sign-off, the team moved to production. By the time of the interview, it had sunset its last hosted deployment and was running fully on remote execution. ## One Control Plane, Many Clusters Back in the Summit session, Narayan walked through the target architecture. Astro remains the control plane, providing centralized observability, RBAC and one view of cross-team dependencies across shared DIT, SIT, UAT and production deployments. Each team runs its own namespace on Azure Kubernetes Service clusters that can span regions. A Helm chart deploys worker, triggerer and Dag processor pods, plus an optional Sentinel monitor. Teams now own their DAG bundles, repositories and CI/CD pipelines. ![](/images/airflow-in-action-otpp-body-image.png) **Figure 1:** *Ontario Teachers’ target architecture: centralized orchestration, distributed remote execution.* [Image source](https://airflowsummit.org/sessions/2026/breaking-the-monolith-implementing-airflow-3-x-remote-execution-for-multi-team-environments/). ## Four Versions, One Upgrade Remote Execution changes the operating model, not just the architecture. Every upgrade must keep four components in sync across teams: the Airflow runtime image, the remote execution agent image, the Sentinel image and the Helm chart. Ontario Teachers standardized all of them: * A central base image bundles version-pinned Snowflake, Databricks and internal libraries, and is published with both pinned and latest tags. * Helm charts are aligned to the organization's security standards. * Onboarding and CI/CD policies are defined once, and teams inherit them. Teams on the latest tag receive upgrades automatically. ## Stop Turning Engineers into Platform Experts With the infrastructure bottleneck gone, knowledge became the constraint. Ontario Teachers packages its standard integrations as Airflow skills, so an engineer can prompt an AI assistant to scaffold a Snowflake Dag with authentication, logging and CI/CD standards built in. For new teams, an AI workflow generates Helm values from configuration inputs, opens a pull request and pre-wires GitHub Actions deployments. As Narayan's closing slide in her Summit session puts it, "The platform scales when our knowledge scales with it." ## Lessons for Your Platform * A shared environment gets teams onto Airflow fast but becomes the bottleneck as teams and workloads diversify. * Staying close to the latest Airflow release makes major upgrades routine, which lets you adopt capabilities as soon as they ship. * A time-boxed proof of value with defined success criteria, run alongside the vendor's engineers, turns a new capability into a production decision within weeks. * Remote Execution on Astro delivers data residency, isolation and team autonomy together, because compute stays with each team while orchestration stays central. * Federated execution stays manageable only when images, Helm charts and CI/CD are standardized, and AI scaffolding turns those standards into self-service. ## Watch the Replay [Watch the Airflow Summit session replay](https://www.youtube.com/watch?v=-oIz_yQft9Y) to see how Ontario Teachers made the move and apply the blueprint to your own platform. Learn more about Remote Execution by downloading our whitepaper: [Remote Execution with Airflow 3 — Powering Hybrid Orchestration Without Compromise](/white-papers/remote-execution-astro/)