After a pipeline is defined as a DAG, its runs need somewhere to be viewed and monitored. The Airflow API server serves the user interface for visualizing DAGs, checking run status and results, and taking actions such as triggering a DAG. It also provides the interface through which other Airflow components read and write metastore information. section 1.2.3 section 15.1
The API server is one part of the execution path, not the process that runs pipeline tasks:
- The DAG processor parses DAG files and stores serialized DAG information in the metastore through the API server. section 1.2.3
- The scheduler decides when tasks are ready and queues them; workers perform the work. The triggerer handles deferred tasks waiting on external conditions. section 1.2.3 section 15.1
In Airflow 3, the API server is the intermediary for component communication with the metastore. Direct metastore access from a DAG was possible in the past, but could cause problems for the whole Airflow instance. Keep database interaction behind the API server rather than treating the metastore as a pipeline integration point. section 15.1 section 1.2.3
Open a local UI
In an activated Python environment, install `apache-airflow` rather than the similarly named `airflow` package, then run `airflow standalone`. Standalone initializes the metastore, creates a user, and starts the API server alongside the scheduler, DAG processor, and triggerer. Open `http://localhost:8080` and use the generated admin password printed in the startup output. section 2.3.1
Keep request and error logs
The API server serves endpoints used by the UI; an access log might record `GET /api/v2/version` with a `200 OK` response. Access and error logs normally go to stdout or stderr. To retain them after shutdown, start the server with `--log_config` pointing to a Gunicorn configuration file that sets `accesslog` and `errorlog` paths. section 15.6.1
Protect or expose the endpoint
For HTTPS, make a certificate and private key available to Airflow and set `AIRFLOW__API__SSL_CERT` and `AIRFLOW__API__SSL_KEY` to their paths. This encrypts browser-to-server traffic; keep the private key secret. In a Kubernetes deployment, the official Helm Chart can expose the API server outside the cluster by setting `apiServer.service.type=LoadBalancer`. section 16.4.2 section 17.2.3
Listing 17.4 Deploying default Airflow with helm
helm repo add apache-airflow https://airflow.apache.org helm upgrade --install airflow apache-airflow/airflow \ --create-namespace \ --namespace airflow \ --set apiServer.service.type=LoadBalancer --set postgresql.image.repository=postgres --set postgresql.image.tag=16
The Helm installation listing shows the `apiServer.service.type=LoadBalancer` setting in the command that deploys Airflow. section 17.2.3
