--- title: >- Introducing Blueprint in Astro: Self-Service Dag Authoring For Your Entire Organization description: >- With Blueprint, creating Airflow pipelines is now possible for anyone in your organization. Data engineers define templates, and others can create pipelines though a drag-and-drop no-code interface in Astro. No python or Airflow knowledge required. date: 2026-04-16T12:22:58.634Z authors: - author: src/content/people/ashley-kuhlwilm.md canonical_url: >- https://www.astronomer.io/blog/introducing-blueprint-in-astro-self-service-dag-authoring-for-your-entire-organization/ --- Every data platform team has a version of this story. A data analyst comes to you with a pipeline request. It's not complex: a daily Snowflake export, a dbt run, a Slack notification when a threshold gets crossed. They understand the logic. They built the query. They just can't write Python, and they definitely can't configure Airflow operators. The ticket lands in the backlog. The analyst waits. A few days later, the engineer who finally picks it up recognizes the pattern immediately. They've built this exact Dag three times in the last quarter. This bottleneck is the norm on teams that rely on Airflow, because Airflow is a code-first tool. That's a feature, not a bug, for the engineers who own it. But it creates a hard boundary between the people who understand the data and the people who can build the pipelines, and shadow pipelines fill that gap. Today, we're announcing [Blueprint in Astro](https://www.astronomer.io/docs/astro/ide-blueprint), now in public preview, to help teams break that boundary without breaking their governance model. ## How Blueprint works Blueprint is built around two distinct roles: the platform and data engineers who define how pipelines should be built, and the analysts and teams who need to build them. #### **Platform and data engineers define templates using the Blueprint open source framework.** A Blueprint template is a Python class that encodes a reusable task group pattern: your standard daily ETL shape, your incremental load structure, your dbt run with retries and SLA monitoring baked in. Each template defines a Pydantic config model, which means every parameter is typed and validated before any Dag gets deployed. Platform teams aren't writing documentation and hoping people follow it. They're encoding standards directly into the template structure, so every Dag generated from that template inherits the same error handling, connection patterns, and observability setup automatically. Templates commit to your repository through standard Git workflows. The `blueprint lint `command validates configurations locally so your team can catch problems before they hit deployment, not after. And if you're building templates for the first time, the Blueprint template skill in Astronomer's agents tooling repo can generate them for you — describe the template you want and it'll produce the Python class, config model, and all. Once templates are defined, Dags are composed in YAML. A pipeline that extracts from two source tables and loads to a target looks like this: ```yaml dag_id: customer_pipeline schedule: "@daily" steps: extract_customers: blueprint: extract source_table: raw.customers batch_size: 500 extract_orders: blueprint: extract source_table: raw.orders load: blueprint: load depends_on: [extract_customers, extract_orders] target_table: analytics.customer_orders mode: overwrite ``` No operator imports, no Python boilerplate, no task dependency wiring. The template handles all of that. This YAML is what gets generated when an analyst configures a pipeline through the no-code interface in Astro. #### **Analysts and other teams build pipelines using those templates in Astro.** Once templates are available in your Astro environment, anyone can open Astro IDE and start building. The Blueprint interface presents your organization's approved templates as a library of building blocks. Users drag them onto a canvas, connect them in dependency order, and fill out a configuration form, specifying things like report names, metrics, lookback windows, and output formats. No Python. No YAML to write. No understanding of how Airflow operators work under the hood. If something doesn't look right, the built-in AI assistant is available to help troubleshoot, and built-in Dag testing lets users validate their pipeline before it ever hits production. ![Blueprint Dag](/images/BLUEPRINTDAG.jpg) The Dag gets committed through the same Git workflow as any hand-authored pipeline. Same audit trail. Same governance. The only difference is who created it. ## What's new in Blueprint v0.2.0 Alongside the new no-code interface in Astro, the Blueprint open source framework released [v0.2.0](https://github.com/astronomer/blueprint/releases/tag/v0.2.0) with several improvements that make templates more flexible and easier to maintain at scale. Runtime parameter overrides let template authors mark specific config fields as overridable at Dag trigger time. Those fields surface automatically in the Airflow trigger form, complete with [validation constraints](https://github.com/astronomer/blueprint?tab=readme-ov-file#validation-behavior) and descriptions pulled from the Pydantic model. Teams that need to run the same pipeline against different parameters no longer need a separate Dag for each variant. `BlueprintDagArgs` **templates** give platform engineers full, validated control over Dag-level configuration — schedules, tags, `default_args`, `catchup`, and more — through the same Pydantic-based model as task-level config, rather than hardcoded YAML fields. **A context proxy for Jinja2** enables dynamic config in Dag YAML files using Airflow runtime macros and execution context, so templates can reference things like `Dag_run.conf` values without custom Python. **Improved validation error messages** surface Pydantic errors as Airflow import errors with actionable guidance instead of silent failures. Invalid Dag YAML now shows up in the Airflow UI with detail on what's wrong and how to fix it — a meaningful quality of life improvement for anyone debugging template configuration issues. The full changelog and migration guide for v0.2.0 is available in the [Blueprint GitHub repository](https://github.com/astronomer/blueprint/releases/tag/v0.2.0). ## Getting started Blueprint in Astro is now available in public preview. If your platform team has already defined Blueprint templates, you can start using the [no-code interface in Astro IDE](https://www.astronomer.io/docs/astro/ide-blueprint) today. If you're starting from scratch, the path is: 1. Install the Blueprint framework and define your organization's reusable templates in Python. The [Blueprint repository](https://github.com/astronomer/blueprint) includes a quick-start guide and examples to get your first template running. The Blueprint template skill in Astronomer's [agents tooling repo](https://github.com/astronomer/agents) and [Astro IDE](https://www.astronomer.io/docs/astro/ide-overview) can also generate templates for you if you'd rather describe what you want than write it from scratch. 2. Generate the schema via the Blueprint CLI, with output to `blueprint/generated-schemas` in your Astro project. Your templates will then appear in the Astro IDE. 3. Open Blueprint in Astro IDE and start building Dags. **Ready to try it yourself? Check out this [getting started guide](https://www.astronomer.io/docs/learn/blueprint-user-tutorial).**