Skip to main content
If you adopted your Airflow Deployments into Astro Private Cloud (APC) but still install and upgrade the Astro Runtime Operator yourself, you can hand the operator over to APC. After that, the platform installs and upgrades it with the rest of APC, and you stop maintaining it separately.
Astro Private Cloud 2.1This feature was introduced in Astro Private Cloud 2.1. To access this feature, upgrade your Astro Private Cloud installation to 2.1 or later.
PreviewMoving the operator is in Preview. APC does not yet manage everything the Astro Runtime Operator can express, and operator mode is still missing some Helm-mode features. See Feature support for what it does not cover yet.
This is a different change from adopting Deployments. Adoption brings your Airflow Deployments under APC management and leaves the operator alone. See Adopt operator Deployments.

​
Before you begin

You need:
  • Your self-installed operator upgraded to version 1.6.1 or above before you start. This is required so that Helm marks the Airflow CRDs to be kept and does not delete them during this procedure. Deleting a CRD deletes every Airflow Deployment on the cluster.
  • Airflow Deployments running under an operator you installed yourself, on a cluster registered as an APC data plane.
  • Permission to run helm against both the operator’s release and the APC platform release, and cluster-level permission to annotate CRDs.
  • A maintenance window. This is a cutover rather than a gradual migration, and it includes a period during which changes to Airflow Deployments are not applied.
Collect these values before you start, because every step uses them: Airflow keeps running throughout. The operator reconciles your Airflow custom resources into Kubernetes workloads, and those workloads are ordinary Deployments and StatefulSets that Kubernetes keeps running without it.

​
Step 1: Confirm your Airflow CRDs are protected

The keep resource policy is required so that no helm command can delete the Airflow CRDs during this procedure. Deleting a CRD deletes every custom resource of that kind, which is every Airflow Deployment on the cluster. Operator 1.6.1 and above sets this policy for you. Confirm all 13 CRDs carry the keep annotation:
Every row should end in keep. Helm honors the annotation both when an upgrade would remove a resource and when an uninstall would delete it. The annotation is metadata only: it does not restart anything and does not change how the operator behaves. If any row is missing keep, stop and contact Astronomer support before going further.

​
Step 2: Record what you have

You need this to verify the result, and to spot immediately if anything is lost:
Keep the output. The Deployment list and the CRD count must be identical at the end.

​
Step 3: Remove your operator installation

Confirm the CRDs and your Deployments survived, using the output you kept in Step 2:

​
Step 4: Enable APC’s operator and transfer CRD ownership

Turn APC’s operator on and let the platform release take ownership of the Airflow CRDs in a single upgrade. The APC platform chart also ships these CRDs, and Helm does not take ownership of objects that belong to another release, so pass --take-ownership to have the platform release adopt them. CRD updates then arrive with the platform chart, like every other APC resource. For the configuration that enables operator support, see Enable operator support. Apply that configuration and upgrade the platform release with --take-ownership:
Use the platform release name, namespace, and chart you collected in Before you begin. See Apply platform configuration for how to apply the upgrade.

​
Step 5: Verify

Exactly one operator is running:
One mutating and one validating webhook configuration are registered:
Your Deployments and CRDs are all still present, matching Step 2:

​
Step 6: Adopt Deployments and confirm a change applies

Adopt the Deployments, then confirm a change reaches the running Airflow. That proves the new operator is reconciling.

​
If something goes wrong

  • The platform upgrade fails with an ownership error on the CRDs. The upgrade ran without --take-ownership. Re-run Step 4 with the flag, checking that the release name and namespace match the platform release exactly.
  • Changes to Airflow Deployments are rejected. A webhook configuration is registered with no operator behind it. Confirm Step 4 completed and the operator pod is running.
  • No operator is running and the upgrade failed. Airflow keeps running. Fix the upgrade and re-run it. Nothing reconciles in the meantime, so avoid making changes to Airflow Deployments until it succeeds.
  • An Airflow Deployment is missing. Stop and contact Astronomer support. Do not run further helm commands.

​
Limitations

  • It is a cutover, not a phased migration. Every Airflow Deployment on the cluster changes operator at the same time. There is no supported way to move one namespace at a time.
  • There is a window with no operator. Between Step 3 and Step 4, nothing reconciles your Airflow custom resources. Running Airflow is unaffected, but changes are not applied.
  • Moving back is not supported. Once CRD ownership sits with the platform release, returning to a self-managed operator is not a documented path.