Dagster Cheat Sheet

1Install & first asset@asset

uvx create-dagster@latest project my_proj # scaffold (GA)★GA
Create a project with create-dagster (also pip install create-dagster). It lays out a defs/ folder (auto-loaded definitions) + pyproject.toml. The bare library is pip install dagster dagster-webserver.
import dagster as dg @dg.asset def raw_users() -> list[dict]: return fetch_users()★
An asset is a function that produces a persistent object (a table/file/model). The function name is the asset key; its return value is the data.
@dg.asset(group_name="ingest", kinds={"python", "s3"}, description="raw user records")
Organize the graph with group_name, tag technologies with kinds (icons in the UI), and document with description.
dg dev # or: dagster dev — UI at http://127.0.0.1:3000★
Launches the webserver + daemon (and schema-checks your defs.yaml first). Click an asset → Materialize to run it and see lineage, runs, and metadata.

2Dependencies & graphinferred lineage

@dg.asset def clean_users(raw_users): # arg name = upstream asset return [normalize(u) for u in raw_users]★
Depend on another asset by naming it as a parameter — Dagster passes the upstream's loaded value and draws the edge automatically. This is the core idea.
@dg.asset(deps=[raw_events]) # dependency without loading the value def report(): ...
Use deps= for an ordering dependency when you don't need the upstream's Python value (e.g. it wrote to a DB the SQL reads).
@dg.multi_asset(specs=[dg.AssetSpec("a"), dg.AssetSpec("b")]) def both(): ...
Produce several assets from one computation with @multi_asset. dg.AssetSpec also declares external/source assets you don't compute.
dg.load_assets_from_modules([my_pkg.assets])
Auto-collect every asset in a module/package instead of listing them — or let the defs/ folder auto-load them (card 11).

3Metadata & asset checksquality

return dg.MaterializeResult(metadata={ "rows": len(df), "preview": dg.MetadataValue.md(df.head().to_markdown())})★
Attach run metadata (row counts, previews, plots, links) to a materialization — it shows on the asset in the UI over time.
@dg.asset_check(asset=clean_users) def no_nulls(clean_users): return dg.AssetCheckResult(passed=all(u["id"] for u in clean_users))★
Asset checks are data-quality tests bound to an asset (nulls, ranges, freshness, row counts) — they run with the asset and can block downstreams.
@dg.asset_check(asset=events, partitions_def=daily) # per-partition★1.13
Partitioned asset checks: @asset_check and AssetCheckSpec now take partitions_def, so a check runs against a specific partition of its upstream rather than the whole asset.
@dg.asset(check_specs=[dg.AssetCheckSpec("rowcount", asset="t")])
Emit checks from inside the asset function too (yield AssetCheckResults alongside the data).

4Asset optionsownership · versioning · virtual

@dg.asset(owners=["team:data", "jane@co.com"], tags={"tier":"gold"})★
Owners & tags power the catalog: filter, search, and route alerts by team. kinds adds tech icons.
@dg.asset(code_version="v2") # stale-data detection when the code changes★
code_version lets Dagster mark downstreams stale when the logic (not just data) changes — pairs with declarative automation.
@dg.asset(retry_policy=dg.RetryPolicy(max_retries=3, delay=10), backfill_policy=dg.BackfillPolicy.single_run())
Per-asset retries; backfill_policy lets a partitioned asset backfill many partitions in one run instead of one-run-per-partition.
@dg.asset(is_virtual=True) # a view / derived table — not materializedpreview
Virtual assets (preview) model things like DB views or derived tables that appear in the graph & lineage but don't need materializing. Also on AssetSpec(is_virtual=True). ⚠️ Preview API — confirm before relying on it.

5Resources & configdependency injection

class Api(dg.ConfigurableResource): base_url: str token: str @dg.asset def data(api: Api): return httpx.get(api.base_url, headers={...}).json()★
Resources are injected external systems (DB clients, APIs, warehouses). Declare a typed ConfigurableResource, request it as a parameter — testable & swappable.
Api(base_url="...", token=dg.EnvVar("API_TOKEN"))★
Pull secrets from the environment with EnvVar — never hardcode credentials. Hide sensitive fields with json_schema_extra={"dagster__is_secret": True}.
class Cfg(dg.Config): batch_size: int = 500 @dg.asset def a(config: Cfg): ...
Per-run config via a Pydantic Config schema — set it at materialize time / in a schedule.

6IO managersread/write for you

# return a value; the IO manager persists it & loads it downstream @dg.asset def clean(raw): return transform(raw)★
An IO manager handles where/how an asset's return value is stored and reloaded — so your function just returns a DataFrame and Dagster does the persistence.
from dagster_aws.s3 import S3PickleIOManager defs = dg.Definitions(assets=[...], resources={"io_manager": S3PickleIOManager(...)})
Swap storage without touching asset code: local files (default), S3, GCS, a warehouse (dagster-duckdb, -snowflake, -gcp Parquet/BigQuery).
@dg.asset(io_manager_key="warehouse_io")
Per-asset IO manager selection — some assets to the warehouse, others to blob storage.
# huge asset? don't return it through an IO manager — write in-fn + deps=tip
For very large data or external side effects (SQL that materializes a table), skip the IO-manager round-trip: write inside the asset and use deps= for ordering.

7Definitionsthe entry point

defs = dg.Definitions( assets=[raw_users, clean_users], asset_checks=[no_nulls], resources={"api": Api(...)}, schedules=[daily], sensors=[on_file])★
Definitions ties assets, checks, resources, schedules, sensors & jobs together — it's what Dagster loads. Merge modules with dg.Definitions.merge(a, b).
# dg projects auto-load everything under defs/ — no import lists [tool.dagster] module_name = "my_proj.definitions"★
In a dg project the defs/ folder is discovered automatically (no manual imports). Dagster still finds the top-level module via pyproject.toml (or -m/-f).
dg.materialize([raw_users, clean_users]) # run in-process, e.g. in a test
materialize() executes assets directly in Python — handy for tests & scripts (card 14).

8Schedules & sensorswhen to run

daily = dg.ScheduleDefinition( target=dg.AssetSelection.assets("clean_users"), cron_schedule="0 * * * *")★
Schedules run a selection of assets (or a job) on a cron cadence. AssetSelection picks assets by name, group, or downstream/upstream (.downstream()).
@dg.sensor(target="clean_users") def on_file(context): if new_file(): yield dg.RunRequest()★
Sensors poll for external events (a new S3 file, an upstream run) and fire runs — event-driven pipelines. Use a cursor to track what you've seen.
@dg.asset_sensor(target="report", monitored_asset=dg.AssetKey("clean_users"))
Asset sensors trigger when a monitored asset materializes — cross-job/cross-code-location dependencies without a shared graph.

9Declarative automationconditions & freshness

@dg.asset(automation_condition=dg.AutomationCondition.eager())★declarative
Declarative Automation: the asset rematerializes automatically when its condition holds — eager() (upstream updated), on_cron("0 * * * *"), on_missing(). Replaces most hand-written sensors; the daemon evaluates it.
cond = dg.AutomationCondition.eager() & ~dg.AutomationCondition.in_progress()
Compose conditions with & / | / ~ to express precise rules (e.g. "eager, but not while a run is in progress").
dg.AutomationCondition.freshness_passed() · .freshness_warned() · .freshness_failed()★1.13
New freshness conditions gate automation on whether an asset meets its freshness policy — drive refreshes off staleness. Automation can now also be set at the job level.
@dg.asset(freshness_policy=dg.InternalFreshnessPolicy.time_window(fail_window=...))
Freshness policies define the SLA the conditions/checks measure against — flag assets that fall behind.

10Partitions & backfillsslice by time/key

@dg.asset(partitions_def=dg.DailyPartitionsDefinition(start_date="2026-01-01")) def daily_metrics(context): day = context.partition_key★
Partitions slice an asset (by day/hour/static keys). Each partition materializes independently — the basis for incremental pipelines. context.partition_key (or partition_time_window) gives the current slice.
# UI: select an asset -> Materialize -> pick a partition range = a backfill★
Backfills materialize many partitions at once (reprocess history) — launched from the UI/CLI, tracked as one operation. backfill_policy (card 4) can collapse them into a single run.
dg.MultiPartitionsDefinition({"date": ..., "region": ...})
Combine dimensions (date × region) for multi-partitioned assets. context.multi_partition_key reads the combined key.

11The dg CLIGA workflow

dg scaffold defs dagster.asset assets/customers.py★GA
dg scaffold generates assets, schedules, sensors, resources & components with zero boilerplate into the defs/ tree — which loads automatically, no import statements.
dg dev · dg list defs · dg list components★
dg dev runs the full instance + UI; dg list enumerates your definitions/components without launching the UI.
dg check defs · dg check yaml★
Validate before you run: dg check verifies all definitions (and defs.yaml schemas) and reports clean errors without framework stack traces — fast feedback in CI.
dg launch --assets clean_users · dg api asset list
dg launch kicks off assets/jobs ad-hoc from the terminal. dg api (assets, asset-checks, jobs, runs, schedules — list/get) gives scriptable JSON for programmatic inspection.

12Componentsreusable building blocks

# defs/my_dbt/defs.yaml — declare definitions from a component, no Python type: dagster_dbt.DbtProjectComponent attributes: project: "{{ project_root }}/dbt"★GA
Components turn a whole integration into a few lines of YAML (defs.yaml): pick a component type, set attributes, and it emits the assets/checks/schedules for you.
dg scaffold defs dagster_sling.SlingReplicationCollectionComponent ingest/
Scaffold a component instance with dg scaffold. Integration components exist for dbt, Sling, dlt, Fivetran, Airbyte, Tableau, Looker & more (state-backed ones default to local-filesystem state).
attributes: key: "{{ dg.env('TABLE') }}" # template vars: {{ dg.* }}, {{ project_root }}
YAML supports Jinja-style template variables ({{ dg.env(...) }}, run-context values) so one component is reusable across environments.
class MyComponent(dg.Component, dg.Model, dg.Resolvable): ...
Author your own component type in Python (subclass Component) to package a team pattern — then everyone consumes it via a small defs.yaml.

13Ops & jobsthe lower level

@dg.op def step(context, x): return x + 1 @dg.job def pipe(): step(step(start()))
Ops are computation units and jobs are graphs of ops — the imperative, non-asset layer. Use them for task-style work that doesn't produce a persistent asset.
job = dg.define_asset_job("nightly", selection="clean_users*")★
Most teams use asset jobs (a named selection of assets) rather than op jobs — schedule these.
# prefer assets; reach for ops only for pure task orchestration
Assets are the recommended default; ops/jobs remain for the minority of pure-task cases.

14Test & materializelocal runs

def test_clean(): result = clean_users(raw_users=[{"id":1}]) assert result[0]["id"] == 1★
Assets are just functions — unit-test them by calling directly. dg.build_asset_context() when a context/resources are needed.
result = dg.materialize([raw_users, clean_users], resources={...}) assert result.success
materialize() runs a set of assets in-process end-to-end — integration-test a slice of the graph, resources and all.
dagster asset materialize --select clean_users -m my_proj.definitions dg launch --assets clean_users
Materialize from the CLI without the UI — the classic dagster command, or the newer dg launch.

15Integrationsthe toolbox

pip install dagster-dbt dagster-duckdb dagster-aws dagster-k8s dagster-dlt★
Integration packages add resources/IO managers/asset factories (and now Components) for dbt, warehouses, clouds, Kubernetes, Spark, dlt, and more.
from dagster_dbt import dbt_assets, DbtCliResource
dbt integration turns every dbt model into a Dagster asset with lineage — a very common pairing (or use the DbtProjectComponent, card 12).
from dagster_pipes import ... # run external code (Spark/k8s) as assets
Dagster Pipes runs code in external environments (PySpark, Kubernetes, Databricks) while streaming logs/metadata back. dagster-io/skills ships AI-agent skills for Claude Code/Codex.
# Dagster+ (cloud) adds hosting, branch deployments, insights, alerts
Self-host the open-source Dagster, or use Dagster+ for managed hosting, CI branch deployments & observability.

16vs Airflow / Prefectchoosing

# Dagster: asset/data-centric, strong lineage, typed IO, testability★
Best when you think in data assets and want lineage, data-quality checks, and local testability first-class.
# Airflow: task/DAG-centric, huge operator ecosystem, the incumbent
Airflow 3 orchestrates tasks/DAGs — ubiquitous, operator-rich, ops-heavy. Prefect is imperative Python-first with minimal ceremony (and now has assets too).
# all three schedule pipelines; the difference is the mental model
Pick by how you model work: assets (Dagster), plain-Python flows (Prefect), or DAGs of tasks (Airflow).

Dagster cheat sheet

Outline

Assets

Resources & IO

Automation

dg CLI & Components

Ops, dev & ecosystem

Assets

Resources & IO

Automation & Partitions

dg CLI & Components

Ops, Dev & Ecosystem

Worth memorizing