Apache-2.0 data orchestration platform for building, testing, deploying, observing, and automating data assets, jobs, schedules, sensors, and pipelines.
Open the source and read safety notes before installing.
Source-backed facts for citing this resource, derived directly from the registry — also available as plain text for AI assistants.
Decision playbook
Signals are present but mixed. Use the checklist below to confirm the source and operational safety for your environment.
0
78
—
No baseline selected
No major trust-signal divergence detected in the current selection.
Confirm ownership and provenance before trusting install instructions.
Source link availableRequired
Open the canonical repository and verify ownership.
Source provenance statusRequired
Marked as source-backed.
Metadata reviewed
Registry metadata indicates a reviewed listing.
Validate risk disclosures before installation or API wiring.
Safety notes presentRequired
Review the listed safety guidance before running commands.
Privacy notes presentRequired
Review data handling notes before connecting accounts or secrets.
Trust level risk gateRequired
Trust level does not block evaluation.
Check package metadata and artifact integrity signals.
Install payload available
Install or copy payload is available for review.
Package verification flag
No package verification flag provided.
Checksum metadata
No checksum provided for downloaded artifact.
Use compare context to validate trade-offs before adoption.
Compare tray has multiple entries
Add at least one more entry to compare trust differences.
Baseline comparison available
No baseline peer selected yet.
Diverging trust signals identified
No major trust-signal divergence found.
Setup at a glance
Copy-ready — paste the snippet to get started.
Adoption plan
Current risk score 16/100. Use staged verification before broader rollout.
Validate source and review signals before any execution.
Confirm source provenanceRequired
Source URL/provenance metadata is present.
Confirm metadata review state
Listing has review metadata.
Verify install payload
Install/config payload exists and can be inspected.
Confirm safety, privacy, and package integrity signals.
Review safety notesRequired
Safety notes are present.
Review privacy notesRequired
Privacy notes are present.
Verify package integrity metadata
No package verification/checksum metadata.
Adopt in controlled steps based on the selected plan.
Run in isolated sandbox firstRequired
Use a constrained sandbox and observe behavior across multiple tasks.
Roll out graduallyRequired
Roll out to a small cohort before wider usage.
Set monitoring and fallback
Define rollback path and monitor errors after adoption.
Evidence readiness
Required evidence gates are covered (5/6 signals complete).
Source repository/provenance is listed.
Required in this preset
Review metadata is present.
Required in this preset
Safety notes are present.
Required in this preset
Privacy notes are present.
Optional in this preset
Package integrity metadata is missing.
Optional in this preset
Install payload is available.
Required in this preset
Required evidence gates are covered for this preset.
Decision timeline
5/6 steps complete with no blocking gaps for this preset.
triage
Source/provenance metadata is available.
triage
Review metadata is available.
verify
Safety notes are available.
verify
Privacy notes are available.
verify
Package integrity metadata is missing.
rollout
Install payload is available.
No required blockers for this timeline preset.
Prerequisite readiness
5 prerequisites to line up before setup. Includes a review or approval gate.
Safety & privacy surface
6 safety and 5 privacy notes across 5 risk areas. Review closely: credentials & tokens, permissions & scopes.
Disclosure: editorial
## Editorial notes
Dagster is useful when Claude-adjacent teams need a production-grade way to turn data and AI workflows into observable assets, scheduled jobs, data-quality checks, lineage graphs, backfills, and repeatable deployment units. It is a good fit for model-evaluation pipelines, embedding refreshes, warehouse transformations, report generation, analytics assets, and ML-adjacent data products that need testing, visibility, and operational discipline.
This is distinct from Ray. Ray is a distributed AI compute engine for scaling Python tasks, actors, training, data processing, and serving across compute clusters. Dagster is the orchestration and control-plane layer for data assets, schedules, sensors, checks, metadata, lineage, run history, and production workflow operations. It is also distinct from Dagster's own docs AI-skill material; this entry lists the Dagster platform itself.
## Source notes
- The official repository describes Dagster as an orchestration platform for the development, production, and observation of data assets.
- The official README describes Dagster as a cloud-native data pipeline orchestrator for the whole development lifecycle with integrated lineage, observability, a declarative programming model, and testability.
- The README says Dagster is designed for developing and maintaining data assets such as tables, datasets, machine learning models, and reports.
- The README shows assets declared as Python functions and says Dagster helps run those functions at the right time and keep assets up to date.
- The README says Dagster is built for local development, unit tests, integration tests, staging environments, and production.
- The README says Dagster is available on PyPI, officially supports Python 3.9 through Python 3.14, and shows `uv add dagster dagster-webserver dagster-dg-cli`.
- The official docs describe Dagster as a data orchestrator built for data engineers with lineage, observability, declarative programming, and testability.
- The deployment docs distinguish Dagster+ managed deployments from self-hosted Dagster OSS deployments.
- The telemetry docs describe frontend and backend usage-stat collection, state that pipeline data and identifiable definition names are not collected, and document the `telemetry.enabled: false` opt-out.
- The Dagster+ Serverless security docs say serverless deployments require direct access to data, secrets, and source code, and warn about managed-storage behavior for sensitive data when using the default I/O manager.
- The repository is `dagster-io/dagster`, is Apache-2.0 licensed, and is active.
## Duplicate check
Checked current `content/tools/`, `content/mcp/`, agents, hooks, rules, skills, commands, guides, open pull requests, live issue state, and repository-wide content for `Dagster`, `dagster-io/dagster`, `docs.dagster.io`, `dagster.io`, `Dagster OSS`, `Dagster+`, `data assets`, and `asset lineage`. No dedicated Dagster tools entry, source URL duplicate, target file, issue duplicate, or open duplicate PR was found.
## Disclosure
Editorial listing. No paid placement or affiliate link is used. Dagster is Apache-2.0 open-source software; Dagster+, cloud infrastructure, databases, warehouses, storage systems, compute platforms, observability services, and downstream integrations may have separate licenses, billing, terms, privacy obligations, and access controls.Dagster is useful when Claude-adjacent teams need a production-grade way to turn data and AI workflows into observable assets, scheduled jobs, data-quality checks, lineage graphs, backfills, and repeatable deployment units. It is a good fit for model-evaluation pipelines, embedding refreshes, warehouse transformations, report generation, analytics assets, and ML-adjacent data products that need testing, visibility, and operational discipline.
This is distinct from Ray. Ray is a distributed AI compute engine for scaling Python tasks, actors, training, data processing, and serving across compute clusters. Dagster is the orchestration and control-plane layer for data assets, schedules, sensors, checks, metadata, lineage, run history, and production workflow operations. It is also distinct from Dagster's own docs AI-skill material; this entry lists the Dagster platform itself.
uv add dagster dagster-webserver dagster-dg-cli.telemetry.enabled: false opt-out.dagster-io/dagster, is Apache-2.0 licensed, and is active.Checked current content/tools/, content/mcp/, agents, hooks, rules, skills, commands, guides, open pull requests, live issue state, and repository-wide content for Dagster, dagster-io/dagster, docs.dagster.io, dagster.io, Dagster OSS, Dagster+, data assets, and asset lineage. No dedicated Dagster tools entry, source URL duplicate, target file, issue duplicate, or open duplicate PR was found.
Editorial listing. No paid placement or affiliate link is used. Dagster is Apache-2.0 open-source software; Dagster+, cloud infrastructure, databases, warehouses, storage systems, compute platforms, observability services, and downstream integrations may have separate licenses, billing, terms, privacy obligations, and access controls.
Show that Dagster is listed on HeyClaude. Paste this Markdown into your README — it renders the badge and links back to this page.
[](https://heyclau.de/entry/tools/dagster)Dagster side by side with 3 alternatives on trust, install, platform support, and disclosed safety notes — all from reviewed registry metadata.
| Field | Apache-2.0 data orchestration platform for building, testing, deploying, observing, and automating data assets, jobs, schedules, sensors, and pipelines. Open dossier | Apache-2.0 platform for programmatically authoring, scheduling, monitoring, and operating workflow DAGs across workers, executors, providers, and task logs. Open dossier | Open-source ML and LLM observability framework for evaluating, testing, and monitoring data quality, drift, model behavior, and AI application outputs. Open dossier | Apache-2.0 Python workflow orchestration framework for resilient data pipelines with flows, tasks, deployments, schedules, retries, caching, workers, work pools, and observability. Open dossier |
|---|---|---|---|---|
| Next steps | ||||
| Trust | ||||
| Review status | ReviewedMaintainer reviewed | ReviewedMaintainer reviewed | ReviewedMaintainer reviewed | ReviewedMaintainer reviewed |
| Package trust | Package not verified | Package not verified | Package not verified | Package not verified |
| Source provenance | Source-backed | Source-backed | Source-backed | Source-backed |
| Submitter | oktofeesh1 | oktofeesh1 | oktofeesh1 | oktofeesh1 |
| Install risk | Review first | Review first | Review first | Review first |
| Notes | Safety ✓ Privacy ✓ | Safety ✓ Privacy ✓ | Safety ✓ Privacy ✓ | Safety ✓ Privacy ✓ |
| Brand | ||||
| Category | tools | tools | tools | tools |
| Source | Source-backed | Source-backed | Source-backed | Source-backed |
| Author | Dagster Labs | Apache Software Foundation | Evidently AI | Prefect |
| Added | 2026-06-04 | 2026-06-04 | 2026-06-03 | 2026-06-04 |
| Platforms | ||||
| Harness | ||||
| Source repo | — | — | — | — |
| Safety notes | ✓Dagster runs user-defined Python code and can orchestrate writes to databases, warehouses, object stores, ML systems, and external APIs, so resources and credentials should be scoped before production runs. Schedules, sensors, automation policies, backfills, retries, and run queues can trigger repeated or large-scale work; teams should test concurrency, idempotency, cancellation, and rollback behavior. Asset checks and lineage improve visibility but do not replace data-quality review, access controls, schema contracts, incident response, or manual approval for high-risk production changes. Self-hosted Dagster OSS deployments need explicit network, auth, TLS, database, object storage, secret-management, backup, upgrade, and log-retention controls. Dagster+ Serverless documentation says serverless deployments require direct access to data, secrets, and source code; teams should review whether that deployment model fits their compliance needs. Dagster+ Serverless documentation warns that the default I/O manager can store sensitive data in Dagster+ managed storage for PII, PHI, BAA, GDPR, or similar regulated workloads unless another I/O manager or code pattern is used. | ✓Airflow executes DAG author Python code on workers, the DAG processor, and the triggerer, and the official security model says that code is not verified or sandboxed by Airflow. DAG authors, admins, connection-configuration users, and deployment managers can have powerful access to workers, credentials, metadata, API actions, and external systems, so roles should be granted conservatively. Schedules, sensors, backfills, retries, and manually triggered DAG runs can repeat destructive work; production DAGs should be idempotent, tested, observable, and easy to pause or roll back. The production docs say SQLite is for testing only and can cause production data loss; production Airflow needs an external database such as PostgreSQL or MySQL with backups and migration controls. The README warns that a plain `pip install apache-airflow` can produce an unusable installation and recommends the official constraint-file workflow for repeatable installs. Multi-node deployments need careful separation of DAG files, configuration, JWT signing keys, database credentials, Fernet keys, worker permissions, and task-log serving between components. | ✓Evidently metrics and tests are decision support, not proof that a model, dataset, prompt, or LLM application is correct, fair, safe, or production-ready. Drift, data quality, and LLM judge results can be noisy or context-dependent, so thresholds should be calibrated on representative data before blocking releases or triggering alerts. Reports, test suites, and dashboards can influence deployment and incident workflows, so review generated conditions before wiring them into CI, monitoring, or agent-managed remediation. Synthetic data generation, prompt optimization, LLM-as-judge evaluations, and provider-backed metrics can call configured model services and should be scoped for cost and data handling. Self-hosted dashboards, local reports, and exported artifacts need normal access controls because they can become a shared source of operational decisions. | ✓Prefect flows and tasks run arbitrary Python code and can query databases, mutate files, call APIs, launch subprocesses, provision infrastructure, and trigger downstream jobs, so workflows should be treated as trusted production code. Retries, schedules, event triggers, deployment runs, backfills, and automations can repeat side effects unless tasks are idempotent and external writes are guarded. Work pools and workers can start subprocesses, containers, Kubernetes jobs, or cloud jobs; base job templates, queue limits, worker permissions, and infrastructure credentials should be scoped tightly. Flow and task timeouts help prevent unintentional long-running work, but teams still need resource limits, cancellation behavior, and cleanup policies for jobs that touch external systems. Blocks can store credentials and typed configuration for external services; SecretStr fields are encrypted and hidden by default in the UI, but credentials still need rotation, least privilege, and environment separation. Logging can capture custom logs, print statements, subprocess output, thread output, task parameters, and exception details; secrets and sensitive rows should not be printed or attached to artifacts. Self-hosted Prefect servers should use authentication, reverse proxy controls, CSRF protection, CORS policy, and secure custom-header handling before being exposed beyond a trusted network. Prefect Cloud, webhooks, automations, notifications, and external integrations can trigger or observe workflow activity and should be reviewed for permissions, rate limits, and incident response behavior. |
| Privacy notes | ✓Dagster workflows can process asset names, job names, resource config, run config, schedules, sensors, partitions, logs, errors, materialization metadata, checks, lineage, secrets, and external-system identifiers. Compute logs, event logs, metadata databases, object stores, I/O manager outputs, code locations, deployment images, and Dagster+ services may retain sensitive operational or data-product information depending on configuration. The official telemetry docs say Dagster collects frontend and backend usage statistics, does not collect pipeline data, and does not collect identifiable information about definition names such as assets, ops, or jobs. Backend telemetry collection is logged under `$DAGSTER_HOME/logs/` when configured, or `~/.dagster/logs/` otherwise, and can be disabled in `dagster.yaml` by setting `telemetry.enabled` to false. Dagster+ Serverless can involve Dagster-managed storage, per-customer registries, container images, secrets, source code, logs, and managed services; deployment teams should review product terms and data-handling requirements. | ✓Airflow can process DAG code, task parameters, run history, schedules, connections, variables, XCom values, rendered templates, logs, audit events, metadata database rows, and external-system identifiers. XComs are stored for task communication and are intended for small values; large values or sensitive payloads should use an appropriate backend or external storage rather than the default metadata database path. Task logs are stored locally under the configured Airflow home by default or in remote services such as S3, GCS, WASB, HDFS, Elasticsearch, CloudWatch, or other configured logging backends. Airflow masks accessed connection passwords, sensitive variables, and selected extra fields in logs and UI views, but values passed through side channels such as XComs or environment variables may not be masked automatically. The Airflow privacy notice says the website follows the Apache Software Foundation public privacy policy; deployed Airflow environments remain the operator's responsibility for data handling, retention, and access control. | ✓Evidently can process dataset columns, feature values, predictions, labels, model metadata, prompts, retrieved context, responses, traces, evaluation scores, and custom metric outputs. HTML, JSON, and Python dictionary reports can contain samples, column names, feature distributions, prompt text, generated answers, labels, or other sensitive operational data. Evidently Platform and Cloud workflows add hosted storage, dashboards, dataset management, tracing, user management, and alerting that should be reviewed against team data-retention and access-control policies. LLM-based evaluations may send prompts, responses, references, or scoring context to configured model providers unless a local evaluation path is used. Local report files and dashboard exports should be kept out of public repositories and shared workspaces unless reviewed for sensitive data. | ✓Prefect workflows can process flow parameters, task inputs and outputs, cached results, state history, run metadata, logs, artifacts, events, schedules, deployments, work-pool data, block documents, and infrastructure job variables. Logs and captured print statements can disclose SQL queries, file paths, data samples, credentials, API responses, exception traces, and environment details if workflow code does not redact them. Blocks, variables, settings, profiles, and environment variables can contain cloud credentials, database credentials, Docker registry credentials, Git credentials, Slack webhooks, Snowflake credentials, and other integration secrets. Prefect server or Prefect Cloud stores orchestration metadata used for monitoring, retries, states, automations, alerts, and dashboards; teams should review retention, access controls, workspace boundaries, and export requirements. Workers running in local, Docker, Kubernetes, serverless, or managed infrastructure may expose environment variables, mounted files, network metadata, container images, and cloud identity details to the execution environment. Automations, webhooks, notifications, and integrations can forward run metadata, event payloads, failure details, and parameters to chat tools, incident systems, APIs, or downstream services. |
| Prerequisites |
|
|
|
|
| Install | — | — | — | — |
| Config | — | — | — | — |
| Citations | ||||
| Claim | Unclaimed | Unclaimed | Unclaimed | Unclaimed |
Author, schedule, monitor, and operate workflow DAGs as code.
Evaluate, test, and monitor ML models, LLM apps, data quality, and drift.
Source-backed guides for putting this to work.
Build Workers AI agents with durable session and workflow state.
Loading live community signals…
A short, calm digest of reviewed Claude resources. Unsubscribe any time.