This reference describes the settings that can be configured for full deployments in Dagster+.
Refer to the Managing deployments in Dagster+ guide for info about configuring settings in the Dagster+ interface or using the dagster-cloud CLI.
Settings are formatted using YAML. For example:
run_queue: max_concurrent_runs: 10 tag_concurrency_limits: - key: "database" value: "redshift" limit: 5 run_monitoring: start_timeout_seconds: 1200 cancel_timeout_seconds: 1200 max_runtime_seconds: 7200 run_retries: max_retries: 0 sso_default_role: EDITOR
For each deployment, you can configure settings for:
The run_queue settings allow you to specify how many runs can execute concurrently in the deployment.
run_queue: max_concurrent_runs: 10 tag_concurrency_limits: - key: "database" value: "redshift" limit: 5
| Property | Description |
|---|---|
| run_queue.max_concurrent_runs | The maximum number of runs that are allowed to be in progress at once. Set to 0 to stop any runs from launching. Negative values aren't permitted.
|
| run_queue.tag_concurrency_limits | A list of limits applied to runs with particular tags.
|
The run_monitoring settings allow you to define how long Dagster+ should wait for runs to start before making them as failed, or to terminate before marking them as canceled.
run_monitoring: start_timeout_seconds: 1200 cancel_timeout_seconds: 1200 max_runtime_seconds: 7200
| Property | Description |
|---|---|
| run_monitoring.start_timeout_seconds | The number of seconds that Dagster+ will wait after a run is launched for the process or container to start executing. After the timeout, the run will fail. This prevents runs from hanging in STARTING indefinitely when the process or container doesn't start.
|
| run_monitoring.cancel_timeout_seconds | The number of seconds that Dagster+ will wait after a run termination is initiated for the process or container to terminate. After the timeout, the run will move into a CANCELED state. This prevents runs from hanging in CANCELING indefinitely when the process or container doesn't terminate cleanly.
|
| run_monitoring.max_runtime_seconds | The number of seconds that Dagster+ will wait after a run is moved into a STARTED state for the run to complete. After the timeout, the run will be terminated and moved into a FAILURE state. This prevents runs from hanging in STARTED indefinitely if the process is hanging.
|
The run_retries settings allow you to define how Dagster+ handles retrying failed runs in the deployment.
run_retries: max_retries: 0
| Property | Description |
|---|---|
| run_retries.max_retries | The maximum number of times Dagster+ should attempt to retry a failed run. Dagster+ will use the default if this setting is undefined.
|
| run_retries.retry_on_asset_or_op_failure | Whether to retry runs that failed due to assets or ops in the run failing. Set this to false if you only want to retry failures that occur due to the run worker crashing or unexpectedly terminating, and instead rely on op or asset-level retry policies to retry assert or op failures. Setting this field to false will only change retry behavior for runs on dagster version 1.6.7 or greater.
|
The sso_default_role setting lets you configure the default role on the deployment which is granted to new users that log in via SSO. For more information on available roles, see the Dagster+ permissions reference.
sso_default_role: EDITOR
| Property | Description |
|---|---|
| sso_default_role | If SAML SSO is enabled, this is the default role that will be assigned to Dagster+ users for this deployment. If SAML SSO is not enabled, this setting is ignored.
|
Configure non-isolated runs on your deployment.
non_isolated_runs: enabled: True max_concurrent_non_isolated_runs: 1
| Property | Description |
|---|---|
| enabled | If enabled, the `Isolate run environment` checkbox will appear in the Launchpad.
|
| max_concurrent_non_isolated_runs | A limit for how many non-isolated runs to launch at once. Once this limit is reached, the checkbox will be greyed out and all runs will be isolated. This helps to avoid running out of RAM on the code location server.
|