Airflow plugin
Installs into the Airflow API server. Users sign in with Airflow, and Airflow roles decide what they may do. Adds Browse → DAG Builder and an AutoAir tab on each DAG.
pip install autoair
The whole DAG lifecycle in one editor
AutoAir covers authoring, validation, review, deployment and debugging, and leaves execution to Airflow.
Every installed operator
A static catalog of all providers, Airflow libraries and your own operators, with typed parameter forms, required markers and rendered docstrings.
Read more →Readable Python out
The canvas edits a versioned DagSpec; code generation goes through the Python AST and ruff. Switch to code mode and edits flow back into the graph.
Read more →Airflow 3 scheduling
Timezones, cron and multi-cron, asset expressions, event-driven assets, assets-and-time and a live "next runs" preview from Airflow’s own timetables.
Read more →Validated before deploy
Graph, catalog, Jinja, policy and version checks run as you type; a warm DagBag pool imports the generated file the way Airflow will.
Read more →Git, review and approvals
Deploy to a DAG folder, object storage or Git. Pull requests carry the author’s identity; four-eyes approval and direct-push rights come from IAM.
Read more →Runs and logs in context
Trigger, backfill and clear from the editor. Task states, logs and XComs appear on the canvas next to the node that produced them.
Read more →Live collaboration
Several authors edit the same DAG with presence, remote cursors and per-user undo, authorised by short-lived tickets.
Read more →AI with guardrails
Generate, edit and explain DAGs with your own LLM provider. Proposals arrive as diffs; guardrails, audit and IAM apply to every call.
Read more →MCP for agents
Claude Code, Claude Desktop and other MCP clients author and validate DAGs through the same API, under the caller’s permissions.
Read more →How it works
The canvas, the code editor, validation and code generation all read and write one model: the DagSpec. The Python file Airflow parses is derived from it, never the other way round.
Compose
Drag operators onto the canvas or start from a template. Fill typed parameter forms, map XComs, write inline functions and scripts.
Validate
Problems update live. Each finding links to the exact task and field; the server re-checks with Airflow’s DagBag and your policy rules.
Review
Inspect the generated Python and the visual diff against the last version. Open a pull request or request an approval.
Deploy and run
AutoAir writes where Airflow actually reads DAGs, then lets you unpause, trigger and debug the run without leaving the editor.
Deploy it the way your platform runs
One Python package, three ways to run it. Configuration, IAM and storage behave the same in each.
Standalone server
Runs next to Airflow as its own process or pod and forwards each caller’s Airflow token, so Airflow RBAC still applies to every call.
autoair serve --airflow-url https://airflow.example.com
Local mode
A single-user editor bound to loopback. Author, validate and export DAGs with no Airflow server; connect one later to run them.
uvx --from 'autoair[standalone,airflow]' autoair local --open
Production guides: Kubernetes reference architecture · Helm · GitDagBundle and git-sync · PostgreSQL · Air-gapped
Try it on your laptop in a minute
Local mode needs no Airflow server. Point it at a real Airflow when you want to run what you built.