This is an automated email from the ASF dual-hosted git repository.
jedcunningham pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/airflow.git
The following commit(s) were added to refs/heads/main by this push:
new 87fc4697f74 Reduce default API server workers to 1 (#55707)
87fc4697f74 is described below
commit 87fc4697f742a792b5560fbb408ce8046e860e08
Author: Jed Cunningham <[email protected]>
AuthorDate: Tue Sep 16 08:03:27 2025 -0600
Reduce default API server workers to 1 (#55707)
Change the default number of API server workers from 4 to 1 and add
guidance to deploy multiple API servers for scaling instead of
increasing workers per server.
With FastAPI, sync code runs in an external thread pool, making
multiple workers within a single api server less necessary than it was in
our flask days. And with uvicorns new spawn behavior instead of fork,
it means no shared copy-on-write memory between workers, so it's better
to scale horizontally now.
---
airflow-core/newsfragments/55707.significant.rst | 23 ++++++++++++++++++++++
.../src/airflow/config_templates/config.yml | 6 ++++--
2 files changed, 27 insertions(+), 2 deletions(-)
diff --git a/airflow-core/newsfragments/55707.significant.rst
b/airflow-core/newsfragments/55707.significant.rst
new file mode 100644
index 00000000000..07a42ba3b93
--- /dev/null
+++ b/airflow-core/newsfragments/55707.significant.rst
@@ -0,0 +1,23 @@
+Reduce default API server workers to 1
+
+The default number of API server workers (``[api] workers``) has been reduced
from 4 to 1.
+
+With FastAPI, sync code runs in external thread pools, making multiple workers
within a single
+process less necessary. Additionally, with uvicorn's spawn behavior instead of
fork, there is
+no shared copy-on-write memory between workers, so horizontal scaling with
multiple API server
+instances is now the recommended approach for better resource utilization and
fault isolation.
+
+A good starting point for the number of workers is to set it to the number of
CPU cores available.
+If you do have multiple CPU cores available for the API server, consider
deploying multiple API
+server instances instead of increasing the number of workers.
+
+* Types of change
+
+ * [ ] Dag changes
+ * [x] Config changes
+ * [ ] API changes
+ * [ ] CLI changes
+ * [ ] Behaviour changes
+ * [ ] Plugin changes
+ * [ ] Dependency changes
+ * [ ] Code interface changes
diff --git a/airflow-core/src/airflow/config_templates/config.yml
b/airflow-core/src/airflow/config_templates/config.yml
index a2ab8aef90e..99c5476736a 100644
--- a/airflow-core/src/airflow/config_templates/config.yml
+++ b/airflow-core/src/airflow/config_templates/config.yml
@@ -1389,11 +1389,13 @@ api:
default: "8080"
workers:
description: |
- Number of workers to run on the API server
+ Number of workers to run on the API server. Should be roughly equal to
the number of
+ cpu cores available. If you need to scale the API server, consider
deploying multiple API
+ servers instead of increasing the number of workers.
version_added: ~
type: integer
example: ~
- default: "4"
+ default: "1"
worker_timeout:
description: |
Number of seconds the API server waits before timing out on a worker
