Ways to install and run Airflow in your own infrastructure: container images, PyPI with constraints, Kubernetes, OpenShift, virtual machines and air-gapped networks, plus DAG delivery, logs and the metadata database.
Why the official docker-compose file is for learning, not production: missing security guarantees, memory needs, what a production container deployment adds, and when a single-host Compose install is still acceptable.
Extending the official image with providers, Python packages and system libraries: pinning with constraints, baking DAGs or not, image tags that keep history, scanning and rebuilding on every Airflow patch.
Installing Airflow and providers reproducibly with pip: constraint URLs per release and Python version, separate provider installs, freezing your own constraints, and OS packages some providers need.
Running Airflow with no internet access: mirroring images and PyPI packages, hosting constraint files internally, DAG delivery from an internal Git server, provider updates through a staging zone and secrets backends reachable inside the enclave.
Choosing how DAG code reaches a Kubernetes deployment: baked images, git-sync with or without persistence, external PVCs, SSH known hosts, the single-repository limit and how each option affects release speed and rollback.
Keeping task logs after pods and workers disappear: remote_logging settings, blob versus streaming handlers, deleting local copies, live log serving ports and the shared secret key, and who may read logs that can contain secrets.
Picking PostgreSQL or MySQL for the metadata database: supported versions, why MariaDB and SQLite are out, managed versus self-run databases, connection limits, growth from run history and cleanup.
Using PgBouncer between Airflow components and PostgreSQL: why connection counts grow with workers and schedulers, the Helm chart PgBouncer settings, secrets for pooled connections and metrics to watch.
Deploying the official Helm chart on OpenShift: security context constraints, running as non-root, routes or ingress for the API server, external databases and image registries, and supported Kubernetes versions.
A production Airflow on VMs: LocalExecutor or CeleryExecutor, separate API server, scheduler, DAG processor and triggerer services, an external PostgreSQL, log serving ports and when the setup should move to Kubernetes.
Managing the Airflow Helm release through GitOps: the hook settings Argo CD and Flux need for migrations and user creation, secrets outside values files, promoting chart and image versions, and drift on upgrades.
Keeping passwords and keys out of values.yaml: Kubernetes Secrets for the metadata connection, Fernet key and API secret key, _CMD and _SECRET variants, disabling built-in secret variables, and rotating values safely.
Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.