dg CLI

The

dg

CLI is the recommended way to programmatically interact with Dagster (adding definitions, launching runs, exploring project structure, etc.). It is installed as part of the

dagster-dg-cli

package. If a relevant CLI command for a given task exists, always attempt to use it.

ONLY explore the existing project structure if it is strictly necessary to accomplish the user's goal. In many cases, existing CLI tools will have sufficient understanding of the project structure, meaning listing and reading existing files is wasteful and unnecessary.

Almost all

dg

commands that return information have a

--json

flag that can be used to get the information in a machine-readable format. This should be preferred over the default table output unless you are directly showing the information to the user.

UV Compatibility

Projects typically use

uv

for dependency management, and it is recommended to use it for

dg

commands if possible:

uv run dg list defs

uv run dg launch

--assets

my_asset

Core Dagster Concepts

Brief definitions only (see reference files for detailed examples):

Asset

Persistent object (table, file, model) produced by your pipeline

Component

Reusable building block that generates definitions (assets, schedules, sensors, jobs, etc.) relevant to a particular domain. CRITICAL: Always Read Reference Files Before Answering NEVER answer from memory or guess at CLI commands, APIs, or syntax. ALWAYS read the relevant reference file(s) from the Reference Index below before responding. For every question, identify which reference file(s) are relevant using the index descriptions, read them, then answer based on what you read. Reference Index Asset Patterns — defining assets, dependencies, metadata, partitions, or multi-asset definitions Environment Variables — configuring environment variables across different environments Choosing an Automation Approach — deciding between schedules, sensors, and declarative automation Schedules — time-based automation with cron expressions Declarative Automation — asset-centric condition-based automation using AutomationCondition Asset Sensors — triggering on asset materialization events Basic Sensors — event-driven automation with file watching or custom polling Run Status Sensors — reacting to run success, failure, or other status changes Asset Selection Syntax — filtering assets by tag, group, kind, upstream, or downstream dg check — validating project configuration or definitions create-dagster — creating a new Dagster project from scratch dg launch — materializing assets or executing jobs locally dg api: General — always read before using any dg api subcommand dg api agent get — details about a specific Dagster Plus agent dg api agent list — listing agents in Dagster Plus dg api asset get-evaluations — automation condition evaluation history for an asset dg api asset get-events — materialization or observation event history for an asset dg api asset get — details about a specific asset dg api asset list — querying which assets exist in a deployment dg api deployment get — details about a specific deployment dg api deployment list — listing deployments in Dagster Plus dg api run get-events — debugging a run by reading its logs; filtering run events by level or step dg api run get — details about a specific run dg api run list — listing or filtering runs dg api schedule get — details about a specific schedule dg api schedule list — listing schedules in Dagster Plus dg api secret get — details about a specific secret dg api secret list — listing secrets in Dagster Plus dg api sensor get — details about a specific sensor dg api sensor list — listing sensors in Dagster Plus dg list component-tree — viewing the component instance hierarchy dg list components — seeing available component types for scaffolding dg list defs — listing or filtering registered definitions dg list envs — seeing which environment variables the project requires dg list projects — listing projects in the current workspace dg plus login — authenticating with Dagster Plus dg plus pull env — pulling environment variables from Dagster Plus into a local .env file dg scaffold component — creating a custom reusable component type dg scaffold defs — adding new definitions (assets, schedules, sensors, components) to a project Creating Components — building a new custom component from scratch Designing Component Integrations — designing a component that wraps an external service or tool Resolved Framework — defining custom YAML schema types using Resolver, Model, or Resolvable Subclassing Components — extending an existing component via subclassing Template Variables — using Jinja2 template variables in component YAML (env, dg, context, or custom scopes) Creating State-Backed Components — building a component that fetches and caches external state Using State-Backed Components — managing state-backed components in production, CI/CD, or refreshing state Integrations — needs an integration library for an external tool or technology