FerroAir - Self-Managed Apache Airflow 3.x Orchestrator for Amazon EC2

FerroAir is a self-managed workflow orchestrator that runs Apache Airflow 3.x workloads on your own Amazon EC2 instances. It is a single static Rust binary that implements an Apache Airflow 3.x scheduler, webserver, REST API v2, triggerer, and DAG processor. Task bodies keep executing on CPython through the upstream airflow.sdk over the Apache Airflow AIP-72 task-execution interface, while FerroAir owns the scheduler tick loop, DAG-folder watcher, REST API, metadata access, leader election, and executor dispatch in Rust. Apache Airflow is an open-source project (it is not an AWS service); FerroAir is wire-compatible with the Apache Airflow 3.0, 3.1, and 3.2 REST API v2 surface and the Apache Airflow AIP-72 task-execution interface.

A real, served interface. FerroAir serves a genuine web UI (a Leptos single-page application, no Node runtime) on port 8080 with the DAG list, graph, grid, gantt, calendar, and task-log views. A dedicated metrics and admin port 9080 exposes Prometheus metrics and the health, live, and ready probes, kept separate from the user-facing UI port. The Apache Airflow AIP-72 task-execution interface is served on port 8081 for the Python worker. The Apache Airflow REST API v2 surface is implemented so existing Apache Airflow REST API v2 clients are supported; see the product documentation for the compatibility matrix.

Operationally lean. The scheduler, webserver, triggerer, and DAG processor run unified in one static binary under a hardened systemd unit, instead of a multi-process Python deployment. For resource-footprint and latency figures (scheduler resident memory, scheduler tick, and DAG parse), see the product documentation for benchmark methodology and figures; those are local developer-workstation measurements, not a performance guarantee for any instance type, and Graviton (arm64) numbers are being re-measured.

State and storage. DAG files sync from an Amazon S3 bucket (or local disk). Metadata is stored in PostgreSQL or SQLite using an Apache Airflow 3 Alembic-compatible schema, so the metadata mount mode stays viable for import. The HA scheduler uses scheduler failover via leader election (openraft); for higher availability run several instances and let leader election promote a standby (see the product documentation for benchmark methodology and figures). Executors include the in-process local executor, a Kubernetes executor (kube-rs), and a Celery executor (Redis or RabbitMQ broker).

Bring your existing workflows across. FerroAir can import connections, variables, and pools from an existing managed Apache Airflow deployment and sync your DAG folder, so teams already running Apache Airflow elsewhere can move their orchestration layer. The post-purchase documentation on the AMI walks through the import tool, the runbook, the compatibility matrix, and validation.

Secrets and integration. Secrets resolve from environment, AWS Secrets Manager, GCP Secret Manager, Azure Key Vault, or Vault. Connections and variables are encrypted (Fernet). Task logs can be written to local disk, Amazon S3, GCS, Azure, or Amazon CloudWatch Logs. Authentication supports FAB auth, OAuth, OIDC, SAML, and LDAP.

No lock-in and no phone-home. FerroAir is a normal Amazon Linux 2023 AMI you run in your own VPC. There is no separate control plane, no telemetry home-call, and no license-key check - billing is AMI hourly plus an annual contract option through your AWS bill. Deploy with the included CloudFormation template and point your DAG bucket and metadata database at the instance.