Providers Overview and Installation

Purpose and Scope

Airflow providers are separately packaged integration distributions that let an Airflow environment talk to external systems without putting every integration directly into the core runtime. A provider can contain operators, hooks, sensors, transfer operators, connection metadata, logging integrations, secret backends, auth-related extensions, extra operator links, and other provider-specific features. This page orients maintainers and platform operators to the provider model, then shows how installation decisions map back to the checked-in provider source layout represented by the Asana and Neo4j provider directories. Sources: providers/asana/src/airflow/providers/asana/README.md, providers/neo4j/src/airflow/providers/neo4j/README.md

The most important practical idea is that providers are installed like normal Python packages. The official provider documentation describes installation from PyPI and from sources, and the package reference presents provider distributions with names such as apache-airflow-providers-asana. In the repository, each provider has its own source subtree under providers/<provider>/src/airflow/providers/<provider>/. That organization lets Airflow keep the core orchestration engine separate from integration-specific code while still publishing integration packages through familiar Python packaging workflows. Sources: providers/asana/src/airflow/providers/asana/README.md, providers/neo4j/src/airflow/providers/neo4j/README.md

Relevant Source Files

• providers/asana/src/airflow/providers/asana/README.md — marks the Asana provider package area in the repository and carries the Apache Software Foundation license header for that provider source tree.
• providers/neo4j/src/airflow/providers/neo4j/README.md — marks the Neo4j provider package area in the repository and carries the Apache Software Foundation license header for that provider source tree.

These two paths are useful examples because they show the repeated provider layout rather than a one-off integration. The provider name appears both in the repository directory and in the Python import namespace under airflow.providers. That consistency is what lets developers reason from a package name, to an import path, to source files. For example, an installed Asana provider is expected to expose Airflow integration code under the Asana provider namespace, while the Neo4j provider follows the same repository convention for graph database integration work. Sources: providers/asana/src/airflow/providers/asana/README.md, providers/neo4j/src/airflow/providers/neo4j/README.md

Provider Distribution Model

A provider distribution is the unit you install when you need a specific integration. Core Airflow supplies the scheduler, API server, DAG processing, and task execution model, but provider packages supply integration-specific behavior that DAG authors use in tasks. That split keeps a base Airflow installation smaller and makes upgrade planning more explicit: you can select the provider packages required by your DAGs rather than assuming every external service library is part of the core apache-airflow package.

The official provider documentation also treats custom providers as first-class packages. A custom provider is built as a Python package with metadata and entry points, and it can use the same mechanisms as Apache-maintained providers. This matters operationally because an organization can package internal operators, hooks, sensors, transfer operators, custom connections, secret backends, logging behavior, auth extensions, and extra links in the same style as public providers. The repository examples here are Apache-maintained provider trees, but the packaging idea is intentionally reusable for private integrations. Sources: providers/asana/src/airflow/providers/asana/README.md, providers/neo4j/src/airflow/providers/neo4j/README.md

Installation Options

For most users, the normal installation path is PyPI. Install Airflow itself using the version and constraints guidance from the Airflow installation documentation, then add the provider distributions needed by your DAGs. The common naming convention is apache-airflow-providers-<provider>, so a deployment that uses Asana tasks would install apache-airflow-providers-asana, and a deployment that uses Neo4j tasks would install apache-airflow-providers-neo4j. The exact set should be derived from the operators, hooks, sensors, or connection types your DAGs import.

pip install apache-airflow-providers-asana
pip install apache-airflow-providers-neo4j

Source installs are useful for contributors, release validation, and environments that need provider changes before a release is available on PyPI. In that mode, treat the checked-in provider directory as the source of the provider package and build or install it through the repository’s development workflow. The official documentation separates installing providers from PyPI and installing from sources because those tasks serve different readers: operators usually want released packages, while contributors and platform teams may need local source changes during integration development. Sources: providers/asana/src/airflow/providers/asana/README.md, providers/neo4j/src/airflow/providers/neo4j/README.md

System-to-Code Mapping

The mapping is intentionally regular. When a DAG import refers to an integration in airflow.providers, you can usually infer the provider package that must be present in the environment. Conversely, when troubleshooting an installed package list, you can map apache-airflow-providers-asana or apache-airflow-providers-neo4j back to the source-tree convention shown by these paths. That regularity is valuable for image builds, dependency audits, and support handoffs because it avoids treating each integration as a special case. Sources: providers/asana/src/airflow/providers/asana/README.md, providers/neo4j/src/airflow/providers/neo4j/README.md

Operational Guidance

Install providers deliberately, not as a blanket catalog. Each provider may bring provider-specific dependencies, connection configuration, authentication requirements, and transitive package updates. A production image should include the providers required by deployed DAGs, pin compatible versions, and follow Airflow’s constraints guidance for the Airflow release in use. When a provider adds or changes behavior that affects operators, hooks, or connection fields, test representative DAGs before promoting the image to shared environments.

Provider installation is also a deployment boundary. If a DAG imports an operator or hook from a provider that is not installed on all components that parse or execute DAGs, the deployment can fail during DAG parsing or task execution. Keep the scheduler, DAG processor, workers, and any other task-executing images aligned. This is especially important when providers are added for only one team’s DAGs, because Airflow still needs a consistent runtime environment for the components that import and schedule those DAG files.

Compact Reference

• Install provider from PyPI: pip install apache-airflow-providers-asana or pip install apache-airflow-providers-neo4j.
• Source-tree convention: providers/<provider>/src/airflow/providers/<provider>/.
• Python import convention: airflow.providers.<provider>.
• Provider capabilities described by the official docs: operators, hooks, sensors, transfer operators, custom connections, logging, secret backends, auth-related extensions, and extra operator links.
• Custom provider model: build a Python package with the required provider metadata and entry points, then install it through the same package mechanisms used for other providers.

Next Steps

Start by listing the provider namespaces imported by your DAGs, then install the matching apache-airflow-providers-* packages in every Airflow runtime image. For deeper authoring details, continue to the operators and hooks reference to understand public integration APIs, then read the custom providers guide if you need to package organization-specific integrations. If the provider adds a connection type or secret behavior, review the connections and secrets pages before rolling it into production.