Trigger a Dagster Job

Run your Dagster jobs on Kestra's schedule and inside Kestra's dependency graph. This blueprint calls the Dagster GraphQL API to launch a named job, blocks until that run reaches a terminal state, and writes Kestra execution metadata back onto the Dagster run as tags. It closes the gap between a data orchestrator that owns asset materialization (Dagster) and a platform orchestrator that owns cross-tool scheduling, event triggers, and lineage (Kestra), so a Dagster job can become one governed step in a larger pipeline instead of a siloed, separately scheduled task.

How it works

• The flow exposes a job_name input (default example_job) so you can point the same flow at any Dagster job at execution time.
• The single trigger_job task (io.kestra.plugin.dagster.TriggerRun) launches the run against the Dagster GraphQL endpoint from baseUrl, targeting the given jobName, repository, and location.
• wait: true makes the task block until the run finishes, polling every PT5S (pollFrequency) up to a PT30M ceiling (maxDuration).
• The body.tags map stamps each Dagster run with source: kestra, plus the Kestra namespace, flow, and execution id, giving you bidirectional traceability.
• Authentication is passed through options.headers as a Bearer token.

What you get

• One Dagster job launched and monitored to completion from a Kestra execution.
• Run metadata you can branch on downstream: {{ outputs.trigger_job.runId }}, {{ outputs.trigger_job.jobName }}, and {{ outputs.trigger_job.status }} (SUCCESS, FAILURE, CANCELED).
• Dagster runs tagged with their originating Kestra namespace, flow, and execution for audit and debugging.

Who it's for

• Data engineers who build assets in Dagster but need a central scheduler and trigger layer.
• Platform teams unifying Dagster with ingestion, transformation, and notification steps owned by other tools.
• Analytics engineers who want a Dagster job to run only after upstream Kestra tasks succeed.

Why orchestrate this with Kestra

Dagster's own scheduler runs Dagster jobs on time-based or sensor triggers, but it cannot natively orchestrate the steps that surround them. With Kestra you add event triggers (a file landing, a webhook, an upstream flow), automatic retries on the trigger task, and run-level lineage tags that tie each Dagster run to a Kestra execution. Everything stays declarative YAML you can version in Git, and the Dagster job becomes one node in a cross-platform DAG that can fan out to dbt, warehouses, alerting, and more.

Prerequisites

• A running Dagster instance with its GraphQL API reachable from Kestra.
• A Dagster job (the job_name input) plus its repository and code location.

Secrets

• DAGSTER_BASE_URL: Dagster GraphQL endpoint (for example http://dagster:3000/graphql).
• DAGSTER_TOKEN: bearer token used in the Authorization header for Dagster API authentication.
• DAGSTER_LOCATION: the Dagster code location name passed to location.

Quick start

1. Add the DAGSTER_BASE_URL, DAGSTER_TOKEN, and DAGSTER_LOCATION secrets to your Kestra namespace.
2. Set the repository value on the trigger_job task to your Dagster repository name.
3. Run the flow, entering your target Dagster job_name.
4. Watch the execution poll until the Dagster run reaches a terminal state, then inspect the outputs.

How to extend

• Add a trigger (schedule, webhook, or flow trigger) so Dagster jobs fire on real events instead of a manual run.
• Chain a downstream task that branches on {{ outputs.trigger_job.status }} to send a Slack or email alert on FAILURE.
• Loop the trigger task over a list of jobName values to fan out across multiple Dagster jobs.
• Tune pollFrequency and maxDuration for long-running materializations, and add retry on the task for transient API errors.

Links

• Plugin docs: https://kestra.io/plugins/plugin-dagster