Use this guide to deploy an Astro Private Cloud (APC) unified cluster, where control plane and data plane components run together in a single Kubernetes cluster. Unified mode combines management services, such as Astro UI, the APC API, and NATS, with runtime services like the deployment orchestrator, Config Syncer, and data plane ingress so that platform operators can evaluate APC without maintaining separate clusters.
If you prefer to keep control plane and data plane Helm releases separate but run them in the same Kubernetes cluster, follow the dedicated control plane and data plane install guides sequentially. That approach consumes slightly more resources than unified mode but keeps responsibilities isolated.
At some points in this installation procedure, your particular environment configurations might require you to take additional steps, or, enable you to skip certain steps.
When you see a callout like this, read it carefully and follow the instructions if they apply to your installation.
Many sections in this document reuse the control plane installation workflow. Integrate the data plane-specific configuration from Install data plane where called out to ensure unified clusters contain all runtime functionality.
eksctl for creating and managing your Astronomer cluster on EKS.Astro Private Cloud requires a Kubernetes Ingress controller to function and provides an integrated Ingress controller by default. Before installing, decide whether to use a third-party ingress controller or use the integrated ingress controller.
Astronomer generally recommends you use the integrated Ingress controller, but Astro Private Cloud also supports certain third-party ingress-controllers.
Ingress controllers typically need elevated permissions, including a ClusterRole, to function. Specifically, the Astro Private Cloud Ingress controller requires the ability to:
If you have complex regulatory requirements, you might need to use an Ingress controller that’s approved by your organization and disable the integrated controller. You configure the Ingress controller during the installation.
Before installing APC, consider how many instances of the platform you want to host because you install each of these instances on separate Kubernetes clusters, following the instructions in this document.
Each instance of APC can host multiple Airflow environments, or Deployments. Some common types of APC instances you might consider hosting are:
Plan each environment as a pairing of one control plane with one or more data planes. Create a project folder for every environment you plan to host to contain its configuration files. For example, if you want to install a development environment, create a folder named ~/astronomer-dev/unified.
In addition to the default cluster in unified mode, additional data plane clusters can be registered by following the Install a Data Plane guide.
values.yaml from a templateAPC uses Helm to apply platform-level configurations. Choose your cloud provider tab below to copy a ready-to-use values.yaml. Then, in the following steps, update image tags, domains, and secrets before deploying.
As you work with the template configuration, use the following guidelines to avoid installation issues:
values.yaml file until instructed to do.helm upgrade or upgrade.sh until instructed to do so.helm upgrade from other Astronomer documentation until after you complete this unified mode installation procedure.The apc-values.yaml examples leave astronomer.houston.config.publicSignups: true, so you can create the initial administrator account. You can control account creation in Disable anonymous account creation.
When you install APC it creates a variety of services that your users access to manage, monitor, and run Airflow.
Choose a base domain such as astronomer.example.com, astro-sandbox.example.com, or astro-prod.example.internal for which:
app.<base-domain>deployments.<base-domain>houston.<base-domain>alertmanager.<base-domain>prometheus.<base-domain>registry.<base-domain>The base domain itself doesn’t need to be available and can point to another service not associated with Astronomer or Airflow. If the base domain is available, you can choose to establish a vanity redirect from <base-domain> to app.<base-domain> later in the installation process.
When choosing a base domain, consider the following:
app.<base-domain>), so ensure you can create DNS records and issue TLS certificates for those subdomains.*.example.com can provide service for app.example.com but not app.astronomer-dev.example.com.app, registry, or prometheus, are fixed and can’t be changed.The base domain is visible to end users. They can view the base domain in the following scenarios:
https://app.sandbox-astro.example.com.https://deployments.sandbox-astro.example.com/deployment-release-name/airflow.astro login sandbox-astro.example.com.app.apps.<OpenShift-domain>. Doing this requires permission to reconfigure the route admission policy for the standard ingress controller to InterNamespaceAllowed. See Third Party Ingress Controller - Configuration notes for OpenShift for additional information and options.Locate the global.baseDomain in your values.yaml file and change it to your base domain as shown in the following example:
In your Kubernetes cluster, create a Kubernetes namespace to contain the APC platform. The following example uses apc as the namespace.
APC uses the contents of this namespace to provision and manage Airflow instances running in other namespaces. Each Airflow instance has its own isolated namespace.
To install APC you need a TLS certificate that is valid for several domains. One of the domains is the primary name on the certificate, also known as the common name (CN). The additional domains are equally valid, supplementary domains known as Subject Alternative Names (SANs).
Astronomer requires a private certificate in the APC platform namespace, even if you use a third-party ingress controller that doesn’t otherwise require it.
Request a TLS certificate from your security team for APC. In your request, include the following:
app.<base-domain> as the CN instead.*.<base-domain> (plus an explicit SAN for <base-domain>) or list each hostname individually:
app.<base-domain> (omit if already used as the Common Name)deployments.<base-domain> (required for Airflow UIs and APIs)houston.<base-domain>prometheus.<base-domain>registry.<base-domain> (required if you keep the integrated container registry enabled)alertmanager.<base-domain> (required if you keep the integrated Alertmanager enabled)key.pem containing the private key in pem formatfull-chain.pem (containing the public certificate and additional certificates required to validate it, in pem format) or a bare cert.pem and explicit affirmation that there are no intermediate certificates and that the public certificate is the full chain.private-root-ca.pem in pem format of the private Certificate Authority used to create your certificate or a statement that the certificate is signed by a public Certificate Authority.--key-type rsa when requesting certificates. Most other solutions generate RSA keys by default.Ensure that you received each of the following three items:
key.pem containing the private key in pem format.full-chain.pem, in pem format, that contains the public certificate and additional certificates required to validate it or a bare cert.pem and explicit affirmation that there are no intermediate certificates and that the public certificate is the full chain.private-root-ca.pem in pem format of the private Certificate Authority used to create your certificate or a statement that the certificate is signed by public Certificate Authority.To validate that your security team generated the correct certificate, run the following command using the openssl CLI:
This command generates a report. If the X509v3 Subject Alternative Name section of this report includes either a single *.<base-domain> wildcard domain or all subdomains, then the certificate creation was successful.
Confirm that your full-chain certificate chain is ordered correctly. To determine your certificate chain order, run the following command using the openssl CLI:
The command generates a report of all certificates. Verify that the certificates are in the following order:
The APC integrated container registry requires that your private key signs traffic originating from the APC platform using the RSA encryption method. Confirm that the key is signing traffic correctly before proceeding.
Run the following command to extract the bare public cert, if it wasn’t already included in the files provided by your certificate authority, from the full-chain certificate file:
Examine the public certificate and ensure all Signature Algorithms are listed as sha1WithRSAEncryption.
If your key isn’t compatible with the APC integrated container registry, ask your Certificate Authority to re-issue the credentials and emphasize the need for an RSA cert, or plan to use an external container registry instead.
Determine whether or not your certificate was issued by an intermediate certificate-authority. If you don’t know, assume you use an intermediate certificate and attempt to obtain a full-chain.pem bundle from your certificate authority.
Certificates issued by operators of root certificate authorities, including but not limited to LetsEncrypt, are frequently issued from intermediate certificate authorities associated with a trusted root CA.
If, and only if, your certificate was issued directly by the root Certificate Authority of a universally trusted certificate authority, and not from one of their intermediaries, then the server.crt is also the full-chain certificate bundle.
Identify your full-chain public certificate .pem file and use it while storing and configuring the ingress controller TLS certificate.
--cert parameter must reference your full-chain.pem, which includes the server certificate and any intermediate certificates, if any. Using the server cert directly causes Dag and image deploys to fail.Run the following command to store the public full-chain certificate in the APC Platform Namespace in a tls-type Kubernetes secret. You can create a custom name for this secret. The following example uses the name astronomer-tls.
However, if your security team has instructed you that there are no intermediate certificates, run the following command.
Astronomer recommends naming the secret astronomer-tls when using a third-party ingress controller.
If you use APC’s integrated ingress controller, you can skip this step.
Complete the full setup as described in Third-party Ingress-Controllers, which includes steps to configure ingress controllers in specific environment types. When you’re done, return to this page and continue to the next step.
Skip this step if you don’t use a private Certificate Authority (private CA) to sign the certificate used by your ingress-controller. Or, if you don’t use a private CA for any of the following services that the APC platform interacts with.
APC trusts public Certificate Authorities automatically.
APC must be configured to trust any private Certificate Authorities issuing certificates for systems APC interacts with, including, but not limited to the following:
Perform the procedure described in Configuring private CAs for each certificate authority used to sign TLS certificates. After creating the trust secret (for example astronomer-ca), add it to global.privateCaCerts in values.yaml so platform components trust the issuer.
If at least one of the following circumstances apply to your installation, you must complete this step:
Kubernetes must be able to pull images from one or more container registries for APC to function. By default, Kubernetes only trusts publicly signed certificates. This means that by default, Kubernetes doesn’t honor the list of certificates trusted by the APC platform.
Many enterprises configure Kubernetes to trust additional certificate authorities as part of their standard cluster creation procedure. Contact your Kubernetes Administrator to find out what, if any, private certificates are currently trusted by your Kubernetes cluster. Then, consult your Kubernetes administrator and Kubernetes provider’s documentation for instructions on configuring Kubernetes to trust additional CAs.
Follow procedures for your Kubernetes provider to configure Kubernetes to trust each CA associated with your container registries, including the integrated container registry, if applicable.
Certain clusters don’t provide a mechanism to configure the list of certificates trusted by Kubernetes.
While configuring the Kubernetes list of cluster certificates is a customer responsibility, APC includes an optional component that can, for certain Kubernetes cluster configurations, add certificates defined in global.privateCaCerts to the list of certificates trusted by Kubernetes. This can be enabled by setting global.privateCaCertsAddToHost.enabled and global.privateCaCertsAddToHost.addToContainerd to true in your values.yaml file and setting global.privateCaCertsAddToHost.containerdConfigToml to:
For example, if your base domain is astro-sandbox.example.com and the CA public-certificate is stored in the platform namespace in a secret named my-private-ca, the global.privateCaCertsAddToHost section would be:
APC requires the ability to send email to:
APC sends all outbound email using SMTP.
Do Not Reply <donotreply@example.com>./ or any other escape character in your username or password, you might need to URL encode those characters.Ensure that your Kubernetes cluster has permissions configured to send outbound email to the SMTP server.
Change the configuration in values.yaml from noreply@my.email.internal to an email address that is valid to use with your SMTP credentials.
Construct an email connection string and store it in a secret in the Astronomer platform namespace. The following example shows how to store the connection in a secret called astronomer-smtp. Make sure to url-encode the username and password if they contain special characters.
In general, an SMTP URI is formatted as smtps://USERNAME:PASSWORD@HOST/?pool=true. The following table contains examples of the URI for some of the most popular SMTP services:
If your SMTP provider isn’t listed, refer to the provider’s documentation for information on creating an SMTP URI.
/ or any other escape character in your username or password, you might need to URL encode those characters.Skip this step if your cluster defines a volume storage class, and you want to use it for all volumes associated with APC and its Airflow Deployments.
Astronomer strongly recommends that you don’t back any volumes used for APC with mechanical hard drives.
Create storage-class-config.yaml in your project directory and update the configuration to match your environment:
Merge these values into values.yaml manually or by using a YAML merge tool of your choosing.
Astronomer requires a central Postgres database that acts as the backend for the APC API and hosts individual metadata databases for all Deployments created on the platform.
If, while evaluating APC you need to create a temporary environment where Postgres isn’t available, locate the global.postgresql.enabled option already present in your values.yaml and set it to true, then skip the remainder of this step.
Note that global.postgresql.enabled to true is an unsupported configuration, and should never be used on any development, staging, or production environment.
If you use Azure Database for either PostgreSQL or another Postgres instance that doesn’t enable the pg_trgm by default, you must enable the pg_trgm extension prior to installing APC. If pg_trgm isn’t enabled, the install will fail. pg_trgm is enabled by default on Amazon RDS and Google Cloud SQL for PostgreSQL.
For instructions on enabling the pg_trgm extension for Azure Flexible Server, see PostgreSQL extensions in Azure Database for PostgreSQL - Flexible Server.
Additional requirements apply to the following databases:
pg_trgm extension as per the advisory earlier in this section.global.ssl.modeto prefer in your values.yaml file.Create a Kubernetes Secret named astronomer-bootstrap that points to your database. You must URL encode any special characters in your Postgres password.
global.postgresql.enabled: true) is deprecated and should only be used for short-lived testing. Always rely on an external Postgres instance for any persistent environment.To create this secret, run the following command replacing the Astronomer platform namespace, username, password, database hostname, and database port with their respective values. Remember that username and password must be URL-encoded if they contain special-characters:
For example, for a username named bob with password abc@abc at hostname some.host.internal, you would run:
Skip this step if you are installing APC onto a Kubernetes cluster that can pull container images from public image repositories and you don’t want to mirror these images locally.
If you can retrieve images from a registry that can be reached without credentials, ensure the endpoint hosting the registry is restricted to trusted networks, for example, private subnets or VPN access. Avoid exposing the platform image registry directly to the public internet. No additional Astronomer configuration is required beyond setting the repository locations later in this step.
For additional examples (including per-Deployment registry settings and air-gapped workflows), see Configure a custom registry for Deployment images.
Astronomer recommends new APC installations use the most recent version available in either the Stable or Long Term Support (LTS) release channel. Keep this version number available for the following steps.
See APC’s lifecycle policy and version compatibility reference for more information.
If you have internet access to https://helm.astronomer.io, run the following command on the machine where you want to install APC:
If you don’t have internet access to https://helm.astronomer.io, download the APC Platform Helm chart file corresponding to the version of APC you are installing or upgrading to from https://helm.astronomer.io/astronomer-<version number>.tgz. For example, for APC v1.0.0 you would download https://helm.astronomer.io/astronomer-1.0.0.tgz. This file doesn’t need to be uploaded to an internal chart repository.
Create a file named upgrade.sh in your platform deployment project directory containing the following script. Specify the following values at the beginning of the script:
CHART_VERSION: Your APC version, including patch and a v prefix. For example, v1.0.0.RELEASE_NAME: Your Helm release name. astronomer is strongly recommended.NAMESPACE: The namespace to install platform components into. astronomer is strongly recommended.CHART_NAME: Set to astronomer/astronomer if fetching platform images from the internet. Otherwise, specify the filename if you’re installing from a file (for example astronomer-1.0.0.tgz).Mac and Linux users with jq installed can set CHART_VERSION in the following snippet and run it to produce a list of images.
If you are installing APC into an egress-controlled or air-gapped environment, perform the following steps.
By default, APC checks for Airflow updates, which are included in the Astro Runtime, once per day at midnight, by querying https://updates.astronomer.io/astronomer-runtime. This returns a JSON file with details about the latest available Astro Runtime versions.
In an egress-controlled or air-gapped environment, you need to store the JSON file in the cluster itself, avoiding the external check. To store the JSON file in the cluster, complete the following steps:
astro-runtime-base-images to your APC API configuration using the runtimeReleasesConfigMapName configuration:If you’re not installing APC into an OpenShift Kubernetes cluster, skip this step.
Add the following values into values.yaml. You can do this manually or by using a YAML merge tool of your choosing.
Only Ingress objects with the annotation route.openshift.io/termination: "edge" are supported for generating routes in OpenShift 4.11 and later. Other termination types are no longer supported for automatic route generation.
If you’re on an older version of OpenShift, route creation should be done manually.
APC on OpenShift is only supported when using a third-party ingress-controller and using the logging sidecar feature of APC. The above configuration enables both of these items.
By default, APC automatically creates namespaces for each new Airflow Deployment.
You can restrict the Airflow management components of APC to a list of predefined namespaces and configure it to operate without a ClusterRole by following the instructions in Configure a Kubernetes namespace pool for APC. If you want to disable creation of role and rolebindings for the deployment orchestrator, config-syncer, and kubestate metrics, you can set global.features.namespacePools.createRbac to false.
When global.rbacEnabled is set to false, the platform no longer creates any role, rolebindings, or service accounts. The user must define default roles to the k8s default service account to continue with the platform install. See Bring your own Kubernetes service accounts for setup steps.
Running a logging sidecar to export Airflow task logs is essential for running APC in a multi-tenant cluster.
By default, APC creates a privileged DaemonSet to aggregate logs from Airflow components for viewing from within Airflow and the APC UI.
You can replace this privileged Daemonset with unprivileged logging sidecars by following instructions in Export logs using container sidecars.
APC includes integrations for several of the most popular OAUTH2 identity providers (IdPs), such as Okta and Microsoft Entra ID. Configuring an external IdP allows you to automatically provision and manage users in accordance with your organization’s security requirements. See Integrate an auth system to configure the identity provider of your choice in your values.yaml file.
Deploy the control plane using the upgrade.sh script you created earlier. Confirm RELEASE_NAME, NAMESPACE, and CHART_VERSION reflect your environment, then execute:
To review manifests before applying them, run ./upgrade.sh --dry-run or use helm template with the same flags defined in the script.
Whether you use Astronomer’s integrated ingress controller or a third-party controller, publish the same set of DNS records so users can reach control plane services.
If you use the integrated controller, get the load balancer address directly:
If you use a third-party controller, ask your ingress administrator for the hostname or IP address that should front the Astronomer routes (refer back to Configure a third-party ingress controller).
Create either a wildcard record such as *.sandbox-astro.example.com or individual CNAME records for the following hostnames so that traffic routes through the chosen load balancer:
app.<base-domain> (required)deployments.<base-domain> (required for Airflow UIs and APIs)houston.<base-domain> (required)prometheus.<base-domain> (required)registry.<base-domain> (required if you keep the integrated container registry enabled)alertmanager.<base-domain> (required if you keep the integrated Alertmanager enabled)<base-domain> (optional but recommended, provides a vanity redirect to app.<base-domain>)Astronomer generally recommends pointing the zone apex (@) directly to the load balancer address and mapping the remaining hostnames as CNAMEs to that apex. In lower environments, you can safely use a low TTL (for example 60 seconds) to speed up troubleshooting during the initial rollout.
After your DNS provider propagates the records, verify them with tools like dig <hostname> or getent hosts <hostname>. You can complete this DNS work after verifying the platform pods—Astronomer services stay healthy without external DNS, but end users need these records to sign in.
Visit https://app.<base-domain> in your web-browser to view APC’s web interface. If any components aren’t ready, consult the debugging guide or contact Astronomer support with the relevant logs and events.
Congratulations, you have configured and installed an APC platform instance — your new Airflow control plane.
From the UI, you can invite and manage users and create and monitor Airflow Deployments on the platform.
Leave astronomer.houston.config.publicSignups: true only until you create your first administrator. Afterwards, secure the platform using the following steps:
astronomer.houston.config.email.enabled: true), specify a trusted domain list under astronomer.houston.config.allowedSystemLevelDomains, and verify that users can only join through an approved identity provider.astronomer.houston.config.publicSignups: false so new accounts require an invitation.helm upgrade targeting the control plane release.The following topics include optional information about one or multiple topics in the installation guide:
Start adding users, workspaces, and deployments in your newly installed or upgraded APC environment at https://app.<base-domain>.