Dagster 1.13.9 Release Adds Hierarchical Asset Groups

The Dagster project released version 1.13.9 on June 11, 2026, bringing a significant structural update to the asset graph and selection logic. This release introduces hierarchical asset groups, new filtering capabilities for asset types, and scaling improvements for deployments running on Kubernetes through Helm.

The full release notes and downloads are on the GitHub release page.

The most visible change in this release is the support for hierarchical asset groups. Previously, asset group names were flat strings. Now, developers can use the forward slash character to define a nested structure. For example, naming a group marketing/ads allows for logical organization that mirrors directory structures or business domains.

This change is not just cosmetic for the user interface. The asset selection syntax has been updated to support wildcards for these groups. A selection string such as group:"marketing/*" will now resolve all assets within that hierarchy. In the asset graph view, these groups are rendered as nested containers, which provides much better clarity for large scale data platforms managing hundreds or thousands of assets.

Complementing the group changes is a new is: filter for asset selection. This allows engineers to filter assets by their fundamental properties rather than just their names or groups. Use cases include selecting only external assets with is:external or focusing on assets that can be materialized with is:materializable. These filters are available both in the programmatic selection API and within the search inputs in the web interface.

For teams running Dagster on Kubernetes, the Helm charts now support multiple replicas for user code deployments. By setting the replicaCount parameter, operators can scale the gRPC servers that host their job definitions and asset logic. A critical part of this update is the implementation of a consistent gRPC server ID across all replicas. This ensures that the Dagster webserver and daemon do not perceive every load balanced request as a new code location, which previously triggered unnecessary and disruptive code reloads.

In the Dagster Cloud environment, the platform has improved the reliability of data uploads using S3 presigned URLs. This impacts several core functions including code location snapshots, serverless I/O manager objects, compute logs, and PEX files. The client now includes automated retry logic for transient HTTP 500 errors from S3. This reduces the frequency of deployment failures or log collection gaps during periods of S3 instability or transient network issues.

The dagster-dlt library also received an update to its DltLoadCollectionComponent. It now supports the definition of partitions and backfill policies. This improvement allows for more granular control when loading data from the dlt library into the asset graph, making it easier to manage incremental loads and historical data reprocessing.

Several important fixes address edge cases in configuration and scheduling. One notable fix involves the handling of date like strings in YAML configuration files. In previous versions, strings that looked like dates, such as "2021-10-30", were sometimes automatically converted to datetime objects by the underlying parser. This could break logic expecting a raw string. The project now ensures these values are passed through as strings when appropriate.

The scheduler has been refined to fix a bug where cron strings constrained to specific hours or days were handled incorrectly. For example, a schedule defined as */15 9-16 * * 1-5 might have been treated as if it ticked uniformly throughout the entire day. This led to over counted partition counts and oversized backfills. The new logic correctly respects the time constraints of the cron expression when calculating partitions.

A deadlock issue was also resolved in the storage layer. This deadlock could occur when shutting down event log watchers on Postgres or MySQL storage while a callback was simultaneously unsubscribing. This fix improves the stability of long running Dagster instances, especially in environments with high volumes of event logs and frequent sensor or schedule activity.

The dagster-dbt library documentation now includes a new section on blue green deployments. This guide covers the clone then swap pattern, which is a best practice for updating dbt models without downtime or exposing partially built tables to downstream consumers.

Additionally, the TemplatedSqlComponent now generates a unique default operation name based on its template. This prevents name collisions when multiple components are used without an explicit execution name. This change simplifies the configuration for teams using many SQL based components in a single project.

For developers using the dg command line tool, the parsing of the DG_PROJECT_PYTHON_EXECUTABLE environment variable in the project dot env file has been improved. It now uses the python-dotenv library, which means exported keys, quoted values, and trailing comments are handled correctly.

The Dagster 1.13.9 release is available through the standard distribution channels. Users should verify compatibility with their existing libraries, particularly the dagster-cloud and dagster-dbt packages.

• Release notes: https://github.com/dagster-io/dagster/releases/tag/1.13.9
• GitHub repository: https://github.com/dagster-io/dagster
• Version tag: 1.13.9

The library updates are also available on PyPI under the version 0.29.9.