dagster-webserver

dagster-webserver is the CLI tool and Starlette/uvicorn-based web server that serves Dagster’s web UI. Running dagster-webserver starts a local (or production) instance of the Dagster UI, exposing a GraphQL API alongside the React dashboard used to browse asset graphs, launch and monitor runs, inspect logs, and manage schedules and sensors.

It is a thin orchestration layer over the core dagster and dagster-graphql packages: the webserver process loads a Dagster code location, resolves its definitions through the GraphQL schema, and serves the compiled frontend assets that ship inside the package. It is the entry point most Dagster users interact with directly, whether running locally during development or deployed behind a reverse proxy in production.

What You Get

• A dagster-webserver CLI command that starts the Dagster UI on a configurable host/port
• A GraphQL API (backed by dagster-graphql) that the UI and external tooling query for run/asset state
• The compiled Dagster UI frontend bundled and served directly from the Python package
• A dagster-webserver-debug entry point for capturing debug snapshots of a Dagster instance

Common Use Cases

• Running a local Dagster UI during development to iterate on pipelines and assets
• Deploying the Dagster UI in production behind a reverse proxy for a data team
• Querying Dagster’s GraphQL API directly for custom tooling or dashboards
• Capturing debug snapshots of instance state for troubleshooting with dagster-webserver-debug

Under The Hood

Architecture The package’s entry point is cli.py, which parses host/port/workspace arguments and hands off to app.py, which assembles a Starlette application wiring together the GraphQL endpoint (graphql.py, built on the schema/ package generated from dagster-graphql), static asset serving for the compiled frontend, and an external_assets.py module for reporting materializations from outside a Dagster run. webserver.py ties the ASGI app to uvicorn for serving over HTTP.

Tech Stack Python 3.10-3.14, built on Starlette (ASGI framework) and uvicorn (ASGI server), with click for the CLI layer. It depends directly on the exact-pinned dagster and dagster-graphql packages from the same monorepo release, and bundles a separately-built React/TypeScript frontend (dagster_webserver/webapp/build/) as package artifacts via Hatchling.

Code Quality Tests in dagster_webserver_tests/ exercise the GraphQL endpoint and CLI startup using Starlette’s TestClient, following the same pytest conventions as the rest of the Dagster monorepo. As a thin serving layer over dagster-graphql, most business-logic testing lives upstream in the core packages; this package’s tests focus on wiring, routing, and CLI argument handling.

API Design The CLI surface is minimal and Click-based (dagster-webserver -p 3333 -h 0.0.0.0), matching the ergonomics of other Dagster CLI entry points, while the underlying GraphQL API gives programmatic consumers a stable, typed schema instead of ad hoc REST endpoints. Because the frontend is bundled into the package, there is no separate frontend build step required to get the full UI running locally.