Dagster Cheat Sheet

1Install & first asset@asset

pip install dagster dagster-webserver★
dagster is the library; dagster-webserver serves the UI. Python 3.9+. Scaffold a project with dg (card 10).
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.
dagster dev # UI at http://127.0.0.1:3000★
Launches the webserver + daemon. 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.load_assets_from_modules([my_pkg.assets])
Auto-collect every asset in a module/package instead of listing them by hand.

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 gate downstreams.
@dg.asset(check_specs=[dg.AssetCheckSpec("rowcount", asset="t")])
Emit checks from inside the asset function too (yield AssetCheckResults).

4Resources & 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.
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.

5IO 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.

6Definitionsthe entry point

defs = dg.Definitions( assets=[raw_users, clean_users], asset_checks=[no_nulls], resources={"api": Api(...)}, schedules=[daily], sensors=[on_file])★
Definitions is the single object that ties assets, checks, resources, schedules, sensors & jobs together — it's what Dagster loads.
# pyproject.toml points Dagster at your module [tool.dagster] module_name = "my_project.definitions"★
Dagster finds your Definitions via pyproject.toml (or -m module / -f file.py).
dg.materialize([raw_users, clean_users]) # run in-process, e.g. in a test
materialize() executes assets directly in Python — handy for tests & scripts.

7Schedules & 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.
@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.
@dg.asset(automation_condition=dg.AutomationCondition.eager())★declarative
Declarative Automation: assets rematerialize automatically when upstreams update or on a schedule — e.g. eager(), on_cron(...). Replaces most hand-written sensors.
@dg.asset(freshness_policy=...) # SLA on how stale an asset may be
Freshness policies/checks flag assets that fall behind their SLA.

8Partitions & 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.
# 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.
dg.MultiPartitionsDefinition({"date": ..., "region": ...})
Combine dimensions (date × region) for multi-partitioned assets.

9Ops & 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.

10Dev, test & the dg CLIworkflow

pip install dg-cli · dg scaffold project my_proj★current
The dg CLI scaffolds and manages Dagster projects & components. dg scaffold defs dagster.asset ... to generate boilerplate.
dagster dev · dg dev★
Local UI + daemon (schedules/sensors/auto-materialize). Hot-reloads your code as you edit.
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.
dagster asset materialize --select clean_users -m my_proj.definitions
Materialize from the CLI without the UI.

11Integrationsthe toolbox

pip install dagster-dbt dagster-duckdb dagster-aws dagster-k8s dagster-dlt★
Integration packages add resources/IO managers/asset factories for dbt (models become assets), 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.
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+ (cloud) adds hosting, branch deployments, insights, alerts
Self-host the open-source Dagster, or use Dagster+ for managed hosting, CI branch deployments & observability.

12vs 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.
# 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

Ops, dev & ecosystem

Assets

Resources & IO

Automation

Ops, Dev & Ecosystem

Worth memorizing