Is Dagster free? Self-hosting Dagster vs Dagster+

Yes, Dagster is free. The open-source core is Apache 2.0, and you can run all of it on your own servers without paying Dagster Labs anything. That answers the licence question. It doesn't answer the budget question.

The budget question is whether you'd rather pay Dagster Labs or pay with your own hours. I self-host a production Dagster instance on a homelab Docker Swarm. It runs 112 assets, 57 schedules and 3 sensors for one person, me. Here is what the paid product costs today, what self-hosting has cost me in time, and a minimal setup you can start from.

Is Dagster free? What open source gives you

The open-source packages give you the whole orchestrator: assets, partitions, schedules, sensors, asset checks, the run queue and the web UI. Nothing in my pipeline needed a paid feature. The Dagster repository is licensed Apache-2.0.

What you take on is running it. A self-hosted Dagster has four parts:

1. Postgres for run history, event logs and schedule state. SQLite works on a laptop; I use it for local development only.
2. Code locations: containers that load your definitions and serve them over gRPC.
3. dagster-webserver: the UI and the GraphQL API.
4. dagster-daemon: schedules, sensors, the run queue, retries and run monitoring.

None of these is hard to start. Keeping them healthy for a year is the real work.

What Dagster+ costs

I checked dagster.io/pricing on 1 October 2026:

Plan	Price	Includes	Per credit
Solo	$10 / month	1 user, 1 code location, 1 deployment	$0.040
Starter	$100 / month	up to 3 users, 5 code locations, 1 deployment	$0.035
Pro	contact sales	unlimited seats, code locations and deployments	custom

Serverless compute was $0.010 a minute on Solo and Starter. Solo and Starter had a 30-day free trial. The page defines a credit as one asset materialization or one op execution, and says a Hybrid deployment, where your own infrastructure runs the code, has no compute charge. There is no free tier on the page, only the trial.

To see what credits mean for you, count materializations. My pipeline has 112 assets, 36 of them partitioned (34 daily). Every daily partition of every daily asset is a credit, every day, plus every retry. Do that sum for your own graph before you assume a plan fits. I haven't priced my pipeline on Dagster+, so I won't guess my number.

Dagster vs Dagster+

According to the Dagster+ docs, the managed product runs the webserver, metadata storage and daemon for you, and adds:

• Branch deployments: a staging copy of your Dagster code per branch.
• Alerts to Slack, PagerDuty and email. In open source you build these yourself, for example with a run-failure sensor.
• RBAC, audit logs and built-in authentication. In open source the UI has no login; you put it behind something.
• Insights for cost and performance trends, and a searchable asset catalog.

Two deployment types: Serverless, where Dagster runs your code, and Hybrid, where Dagster+ is the control plane and your code runs on your own infrastructure.

If you are a team of three with no one who wants to run Postgres and a reverse proxy, Dagster+ is likely cheaper than your time. If you already run servers, self-hosting is a reasonable choice. Here is what it looks like.

My self-hosted Dagster setup

The setup on my homelab Docker Swarm, from the pipeline repository and its deploy config:

• Storage: Postgres holds all run metadata. The data itself lives elsewhere: ClickHouse for tables, Parquet on network storage for the raw layer.
• Code location: one replica, limited to 4 CPUs and 16 GB of memory, with 1 CPU and 4 GB reserved.
• Run queue: QueuedRunCoordinator with max_concurrent_runs: 30. Backfills are limited to 10 concurrent runs through a tag limit, and ML training runs one at a time.
• Retries and timeouts: run_retries with max_retries: 2, and run_monitoring.max_runtime_seconds: 86400, a 24-hour ceiling on any run.
• Deploys: CI runs docker service update with the new image, then calls the reloadRepositoryLocation GraphQL mutation so the webserver picks up the new definitions.
• Access: the UI and GraphQL API sit behind Cloudflare Access. Scripts that call the API send a Cloudflare Access service token in their headers, or they get an HTML login page instead of JSON.

One lesson from the design docs: dagster.yaml is instance configuration, not code configuration. If several code locations share one instance, they share one set of concurrency limits. My pipeline therefore keeps API rate limiting in its own code, with a rate limiter in the application, and leaves the instance a high ceiling.

What self-hosting costs you in ops time

Self-hosting is free in money. These are the hours it has cost me.

The UI wasn't enough, so I wrote scripts. Over time the repository grew helper scripts for jobs the UI didn't do well for me:

• a sequential partition runner for ML training, one partition at a time;
• an ordered materialiser for the "full" history assets, written "to prevent overloading the server and ClickHouse";
• a backfill status report that reads straight from the Postgres run tables;
• a cleanup for failed runs whose partition later succeeded, so the failure list shows only real failures.

Each one is small. Together they are a maintenance surface Dagster+ wouldn't remove either, but it is time you should count.

Stored state beats code. I set default_status=STOPPED on sensors in code. Four kept running, because Dagster keeps a sensor's state in its database and stored state wins. One of them rewrote all NSE price data twice a night. Deleting the sensor was the only off switch I trusted. Managed or not, the instance database is part of your system, and you need to be able to look inside it.

The instance needs defaults you have to choose. In the Dagster source, run_monitoring.max_runtime_seconds defaults to 0, which means no ceiling, and run_retries is off. Mine are 86,400 seconds and two retries. Nobody sets these for you on a self-hosted instance; you find out you needed them from a run that never ended or a failure that never retried.

What I don't have to do is pay per materialization. With 36 partitioned assets and backfills of thousands of partitions, that matters for my shape of workload. For yours it may not.

A minimal Dagster Docker Compose setup

Dagster's docs include a Docker Compose example (files on GitHub). This is a trimmed sketch of the same shape, for one machine. Check the keys against the docs for your Dagster version.

# docker-compose.yml (sketch)
services:
  postgres:
    image: postgres:16
    environment:
      POSTGRES_USER: dagster
      POSTGRES_PASSWORD: ${DAGSTER_PG_PASSWORD}
      POSTGRES_DB: dagster
    volumes: [pgdata:/var/lib/postgresql/data]

  user_code:            # your image: dagster + your code
    image: my-pipeline:latest
    command: ["dagster", "api", "grpc", "-h", "0.0.0.0", "-p", "4000", "-f", "definitions.py"]
    environment: &pg
      DAGSTER_PG_URL: postgresql://dagster:${DAGSTER_PG_PASSWORD}@postgres:5432/dagster

  webserver:
    image: my-pipeline:latest
    command: ["dagster-webserver", "-h", "0.0.0.0", "-p", "3000", "-w", "workspace.yaml"]
    environment: *pg
    ports: ["127.0.0.1:3000:3000"]   # put auth in front before exposing it

  daemon:
    image: my-pipeline:latest
    command: ["dagster-daemon", "run"]
    environment: *pg
    restart: on-failure

volumes:
  pgdata:

# dagster.yaml (sketch), in $DAGSTER_HOME of webserver and daemon
storage:
  postgres:
    postgres_url:
      env: DAGSTER_PG_URL

run_coordinator:
  module: dagster.core.run_coordinator
  class: QueuedRunCoordinator
  config:
    max_concurrent_runs: 10
    tag_concurrency_limits:
      - key: "dagster/backfill"
        limit: 4

run_retries:
  enabled: true
  max_retries: 2

run_monitoring:
  enabled: true
  max_runtime_seconds: 86400

# workspace.yaml
load_from:
  - grpc_server:
      host: user_code
      port: 4000
      location_name: "my_pipeline"

Three notes. The official example uses the DockerRunLauncher, which starts each run in its own container and needs the Docker socket mounted. Without a run_launcher section, Dagster uses its default launcher, and runs execute inside the code-location container, which is why mine has a memory limit. And the webserver has no login: bind it to localhost or put an authenticating proxy in front, as I do with Cloudflare Access.

A short self-hosting checklist

Before you choose self-hosted Dagster, I'd want yes to these:

1. Someone on the team is happy to run Postgres, upgrades and backups.
2. You have somewhere safe to put the UI: a VPN, an access proxy, or localhost only.
3. You will set max_runtime_seconds, retries and concurrency limits on day one, not after the first stuck run.
4. You will build alerting yourself, for example a run-failure sensor that posts to Slack.
5. You have counted your monthly materializations and compared them with the Dagster+ credit price.

So: is Dagster free?

The software is free. Running it is not. For a solo engineer who already runs servers, self-hosting has been the right call for me: no per-materialization bill, full control, and a Postgres database I can query when the UI falls short. The price was a set of helper scripts and a few incidents that taught me which defaults to change.

For a small team without someone who likes operations, Dagster+ at $10 or $100 a month plus credits is likely cheaper than the hours. Count the credits first. If you are still choosing an orchestrator at all, read Dagster vs Airflow, and for the full cost picture of a pipeline, what a data pipeline actually costs.

Local-First Analytics covers running the analytical side on your own hardware: DuckDB, Parquet and Arrow. Chapter 1 is free to read, the rest is on Amazon. Related reading: running DuckDB on your own infrastructure, Dagster and dbt: do you need both?, and building a data platform solo.

If you want help deciding between self-hosting and a managed orchestrator for your team, a Data Platform Audit is a week and a written roadmap you keep. If your team is two people with no appetite for operations, buy Dagster+ and skip the audit.