When self-hosting Dagster OSS or buying Dagster+ fits your team
Self-hosting open-source Dagster suits a platform team that must keep orchestration inside its own network and already has engineers to run it. Dagster is Apache-2.0 licensed, and its self-managed deployment runs a webserver that can have multiple replicas, a single daemon for schedules, sensors and run queuing, and code location servers limited to one replica each. Run, event log and schedule storage default to SQLite and can move to PostgreSQL. This profile owns the upgrades, backups, network controls and identity layer in front of the UI, and it chooses among the Kubernetes with Helm, Docker and Amazon ECS options the documentation describes.
Buying Dagster+ suits a team that needs authentication, role-based access control, audit logs and alerts from the start and does not want to build or staff them. The Dagster+ docs add Insights, alerts to Slack, PagerDuty and email, an asset catalog with column lineage and branch deployments on top of open source. The deployment choice matters most. In Serverless, your code executes in Dagster's environment, which suits teams comfortable with a vendor-run execution plane. In Hybrid, you run the execution environment that connects to the Dagster+ control plane, which keeps code and data access on infrastructure you control. Confirm which controls your auditors expect to see, then check the Dagster+ deployment docs for how each deployment type handles them.
Cost differs in kind more than in size. Self-hosting has no Dagster subscription, but the team pays for infrastructure, database operations, on-call coverage and upgrade work, and those costs recur. Dagster's pricing page lists Solo at $10 per month for one user with credits at $0.040, Starter at $100 per month for up to three users with credits at $0.035, Serverless compute at $0.010 per minute, and Pro at custom pricing, where a credit is one asset materialization or op execution. Ask for a written quote that covers expected credit volume, the Hybrid infrastructure you would still run, and support terms, then compare it with the engineering hours your platform team would spend. Teams with few engineers and strict control requirements should weigh staffing first.
How self-hosted Dagster and Dagster+ compare factor by factor
This table sets self-hosted open-source Dagster against the paid Dagster+ service across license, added features, where the UI and metadata stores run, and published plan prices. Read it to see which costs and controls you take on yourself and which you buy from Dagster, then confirm current figures on the pricing page before deciding.
| Factor | Dagster OSS (self-hosted) | Dagster+ (managed) |
|---|---|---|
| License | Apache-2.0, free to use and modify under its terms | Commercial managed service built on the open-source engine |
| Access control and SSO | Not included in the open-source edition, so you add your own access layer | Role-based access control and SAML SSO listed as Dagster+ features |
| Audit logs | Not listed as part of open source, so confirm what your deployment records | Audit logs listed as a Dagster+ feature |
| Alerts | Alerting depends on what you configure yourself | Alerts to Slack, PagerDuty and email listed as Dagster+ features |
| Catalog, lineage and branches | Asset model is open source; catalog search, column lineage and branch deployments are not listed as open-source features | Catalog search, column lineage, branch deployments and Insights listed as Dagster+ features |
| Where the UI and metadata run | Your infrastructure: webserver, daemon and run, event log and schedule storage run where you deploy them | Dagster runs the web UI, metadata stores and backend services |
| Where your code runs | Your infrastructure, using your chosen run launcher and executor | Serverless runs code in Dagster's environment; Hybrid runs your execution environment on your infrastructure |
| Published entry prices | No subscription fee for the software itself; you pay for hosting and operations | Solo at $10 per month for one user with credits at $0.040; Starter at $100 per month for up to 3 users with credits at $0.035 (Dagster pricing page) |
| Higher tier | Not applicable | Pro is custom-priced; request a written quote from Dagster |
Where your code runs: Serverless or Hybrid on Dagster+
In Dagster+ Serverless, your Dagster code executes in Dagster's environment. Dagster runs the web UI, the metadata stores and the backend services as part of the managed platform, so your team does not operate a daemon, webserver or run storage for the control plane. This is the lowest-effort path to the Dagster+ features, but it means the code that transforms your data runs on infrastructure you do not own.
- Code location: Your pipeline code is deployed to and executed in Dagster's environment rather than in your cloud account.
- Operations: Dagster operates the webserver, daemon and run storage, so there are fewer components for your platform team to patch and back up.
- Data access: Any source system your assets read from must be reachable from Dagster's environment, which can require network allowlisting or credential exchange that your security team must approve.
- Compute billing: Serverless compute is priced per minute on the published pricing page, so run duration and frequency drive the recurring cost.
- Data residency: Confirm the region in which execution and stored metadata reside before you move regulated datasets through it.
Before you choose Serverless, ask Dagster which regions host execution, where run logs and asset metadata are stored, how long they are retained, and whether they are encrypted at rest.
In Dagster+ Hybrid, you run an execution environment in your own infrastructure that connects to the Dagster+ control plane. Your code runs where you host it, so source data and transformation logic can stay inside your cloud accounts or data center, while Dagster+ supplies the managed UI and the governance features. The trade-off is that your team takes on the execution environment, its networking and its upgrades.
- Code location: Your pipeline code runs on infrastructure you control, which keeps source data inside your network boundary during execution.
- Outbound connection: The execution environment connects out to the Dagster+ control plane, so confirm with your network team which endpoints and protocols must be permitted.
- Operations: Your platform team owns the execution environment, its scaling, patching and the credentials it holds.
- Metadata location: Asset metadata, run status and logs may still pass through the control plane, so the boundary for these items must be confirmed separately from the code boundary.
- Cost structure: Your own compute and staff time are added to the Dagster+ subscription, so the total differs from the Serverless figure.
Before you choose Hybrid, ask Dagster exactly which metadata, logs and event records leave your environment, where they are stored, and which parts of that data your auditors will need to see.
Both models split the platform into two layers: the execution layer that runs your code and the control plane that shows runs, schedules and lineage. Where your data sits depends on which layer touches it, and the control plane is the part that most often surprises security reviewers. Dagster's documentation describes the managed service as running the web UI, metadata stores and backend services, so treat that as the starting point for your data-flow review rather than assuming a fixed answer.
- Source data: Under either model, the data your assets read and write stays where your execution environment sends it, so map each source and sink explicitly.
- Run and event logs: Logs produced during execution may be transmitted to the control plane or retained in your environment, depending on the configuration you choose.
- Asset metadata: Column names, lineage and materialization records are metadata, and many compliance programs treat them as sensitive.
- Retention and deletion: Ask how long each record type is kept, how deletion requests are processed, and how an export works if you leave the platform.
- Audit evidence: Request written statements on the data flows so your compliance team can cite them in its own documentation.
Before you sign, ask Dagster for a written data-flow description covering every metadata and log type, its storage location, its retention period and its encryption.
How data location, access control and compliance change by model
Self-hosting open-source Dagster keeps code, run metadata and access decisions inside your environment, but you build and operate those controls yourself. Dagster+ moves parts of the control plane to Dagster and changes what evidence you can pull from each layer. DeployOpen prepares evidence for compliance assessments but does not issue audit reports or certifications, so confirm specific control coverage with Dagster and your assessor.
Where code and data execute
In Dagster+ Serverless, your Dagster code runs in Dagster's environment, so you must decide whether that location is acceptable for the data your assets touch. In Dagster+ Hybrid, you run the execution environment on your own infrastructure while the control plane stays with Dagster. With open-source Dagster, code location servers, the daemon and run storage all sit where you deploy them. Ask Dagster which metadata leaves your environment in each model, including logs and asset metadata.
Identity and role assignment
Open-source Dagster does not include role-based access control or SAML SSO, according to Dagster's pricing page, which lists both as Dagster+ features. Self-hosting means you place the webserver behind your own identity-aware proxy or access layer and manage who can trigger runs, edit schedules and view secrets. Dagster+ supplies these controls in the managed product. Confirm which roles map to your existing identity groups and whether your team can enforce least privilege on code locations.
Audit trails for run and config changes
Audit logs are listed by Dagster as a Dagster+ feature, so an open-source deployment has no built-in record of who changed a schedule or launched a run beyond what your own logging captures. Decide where webserver access logs, run event logs and deployment change records will be retained and who can read them. Check whether Dagster+ audit log export meets the retention and format your assessor expects before you rely on it as evidence.
Network boundaries and egress
Open-source Dagster runs entirely on networks you define, which suits air-gapped or tightly segmented environments if your container images and Python dependencies are mirrored internally. Dagster+ Hybrid still requires your execution environment to connect outbound to the Dagster+ control plane, so firewall rules and proxy policy must allow that path. Document each connection, its direction and the data it carries, and confirm the exact endpoints with Dagster before network approval.
Evidence for compliance assessments
Assessors ask for configuration, access reviews, change history and proof that controls operate. With self-hosted Dagster you produce that evidence from your own tooling, infrastructure-as-code and logs, and DeployOpen can help prepare the controls and documentation for review. Dagster+ may supply some of this evidence from its own features, but the scope of its attestations and control mappings should be confirmed in writing with Dagster and your assessor rather than assumed.
Vendor dependency and exit path
Dagster is Apache-2.0 licensed, so the open-source engine stays available to you regardless of your commercial choice. Moving from Dagster+ back to self-hosting means rebuilding RBAC, SSO, alerting and audit capture yourself, and reconnecting Hybrid agents to your own storage and launchers. Ask Dagster how asset definitions, run history and secrets can be exported, and plan the exit before you depend on Dagster+-only features for compliance evidence.
What your team runs in each model
This table shows who operates each part of a Dagster deployment under self-hosted open source, Dagster+ Serverless and Dagster+ Hybrid. Read each row as a question to answer for your own team: if the cell says Dagster Labs operates it, your team's work shifts to configuration and code, while a cell that says your team operates it is a recurring duty you should staff and budget for.
| Component or task | Self-hosted open source | Dagster+ Serverless | Dagster+ Hybrid |
|---|---|---|---|
| Web UI and GraphQL webserver | Your team deploys and scales the webserver, which can run with multiple replicas | Dagster Labs runs the web UI and backend services | Dagster Labs runs the web UI and control plane |
| Daemon for schedules, sensors and run queuing | Your team runs a single daemon and monitors it | Managed by Dagster+ | Managed by Dagster+ control plane, with your execution environment connected to it |
| Run, event log and schedule storage | Your team chooses SQLite (the default) or PostgreSQL and operates the database | Metadata stores are run by Dagster+ | Metadata stores are run by Dagster+ |
| Where your Dagster code executes | Your infrastructure, such as Kubernetes, Docker or Amazon ECS | Dagster's environment | Your infrastructure, through an execution environment you run |
| Code location servers | Your team runs them, each limited to one replica | Managed by Dagster+ | Your team runs the execution environment that serves them |
| Upgrades and version management | Your team plans and tests each Dagster release, using releases such as 1.13.26 as reference points | Dagster Labs performs platform upgrades | Dagster Labs upgrades the control plane; your team maintains the execution environment |
| Backups and recovery | Your team owns backups of run storage, event logs and schedules | Confirm the backup and recovery terms in your contract | Your team owns backups of the execution environment; confirm control plane terms |
| Network and data boundary | Everything stays inside your network | Code executes outside your network; confirm data residency requirements | Code and data processing stay in your infrastructure, with control plane connectivity |
| Deployment options Dagster documents | Kubernetes with Helm, Docker and Amazon ECS | Managed by Dagster+, no deployment target for you to run | Your execution environment runs on infrastructure you choose |
Moving between self-hosted Dagster and Dagster+ without rewriting assets
This sequence shows which parts of a move between open-source Dagster and Dagster+ carry over unchanged and which parts need planning, so the cutover is a deliberate change of deployment, identity and storage rather than a rewrite of pipelines.
Inventory code locations, run storage and schedules
Platform engineering lists every code location, the Python packages and environment each one needs, where run, event log and schedule storage live, and which schedules and sensors are active. Dagster's open-source documentation describes storage that defaults to SQLite and can use PostgreSQL, so confirm which backend you run today. The step is done when the team holds a written inventory that the cutover plan can be checked against.
Confirm asset definitions carry across as Python code
Data engineers review that asset definitions are Python functions in your repository, so the same code can be deployed to Dagster+ without redeclaring assets. What changes is the deployment layer, the identity provider and the storage that holds history. Record any code that depends on local file paths, self-hosted secrets or open-source-only settings, because those lines need changing. The step is done when the team can name every change that falls outside the asset code.
Decide Serverless or Hybrid placement
The data platform lead and security team choose where code runs. In Dagster+ Serverless, your Dagster code executes in Dagster's environment. In Dagster+ Hybrid, you run an execution environment on your own infrastructure that connects to the Dagster+ control plane. Check data residency, network paths to sources and the credentials each option requires before choosing. The step is done when a signed decision records the placement for each code location.
Move secrets, identity and access settings
Security engineering moves credentials out of open-source configuration into the secret handling that the chosen Dagster+ deployment supports, then maps existing users to Dagster+ roles. Dagster+ adds role-based access control, SAML SSO and audit logs, so confirm with Dagster how your identity provider and group mappings will be configured. The step is done when test users reach the intended workspaces with the roles they need, and no credential remains in plain configuration.
Validate sensors, run queuing and alerts
Orchestration engineers run sensors and queued runs in a non-production workspace and compare triggered runs, concurrency limits and retry behavior with the open-source system. Confirm that alert destinations for Slack, PagerDuty or email are configured and tested, since those are Dagster+ features. The step is done when a defined set of sensor-triggered and scheduled runs completes with the expected outcomes and alerts arrive at the right channels.
Migrate schedules and history with an agreed approach
The team decides whether to carry over run and event history or to start fresh in Dagster+, and confirms with Dagster what migration support covers for schedules and historical metadata. Keep the open-source storage intact until the decision is recorded, so audit and lineage history remain available for review. The step is done when the migration approach is written down and the schedules to be enabled are listed by name.
Plan the cutover and the fallback
Operations schedules a window in which schedules are paused in one environment and enabled in the other, with a named owner for each switch. The fallback plan states how to re-enable open-source schedules if Dagster+ runs fail. Record the rollback criteria in advance. The step is done when a cutover checklist is signed off and a post-cutover check confirms that expected runs, alerts and asset materializations appear in the new environment.
Questions buyers ask before choosing Dagster OSS or Dagster+
How much does Dagster+ cost compared with self-hosting open-source Dagster?
Dagster's pricing page lists Dagster+ Solo at $10 per month for one user, with credits at $0.040 each, and Starter at $100 per month for up to 3 users, with credits at $0.035 each. Pro is listed at custom pricing. A credit is one asset materialization or op execution. Serverless compute is listed at $0.010 per minute. The recurring Dagster+ bill therefore depends on seats, how many assets you materialize, and how many compute minutes Serverless uses. Open-source Dagster has no license fee, but you pay for the infrastructure that runs the webserver, daemon, storage and code locations, plus the engineering time to operate it. When you request a quote, ask for each recurring line separately, along with any one-time implementation cost. Confirm current figures on the Dagster pricing page, since published prices can change.
How long does a self-hosted Dagster rollout take?
No supplied duration applies to every team, so the honest answer is that the timeline depends on scope, and you should get it in writing before work starts. The main scope drivers are the number of code locations, the target platform (Kubernetes with Helm, Docker or Amazon ECS), whether run, event log and schedule storage moves from the SQLite default to PostgreSQL, the identity and audit requirements, the number of data sources to connect, and how much alerting and backup you need. A proof of concept on one code location is a very different project from a multi-team platform with single sign-on, tested backups and an upgrade runbook. DeployOpen works mainly on fixed-scope engagements, so scope, deliverables and timelines are agreed in writing before work begins.
What skills does our internal team need to run Dagster OSS?
Dagster OSS is Python-native, so your team must write, test and review the Python asset code that other teams depend on. Beyond that, operating a self-hosted deployment usually needs:
- Container platform skills for the target you choose: Docker, Kubernetes with Helm, or Amazon ECS.
- PostgreSQL administration if run, event log and schedule storage moves off the SQLite default.
- Operations ownership for the webserver, the single daemon that runs schedules, sensors and run queuing, and the code location servers, each limited to one replica.
- Release management that tests upgrades against your pipelines before production.
Name an owner for each area before the project starts. Confirm the exact headcount and skill mix against your own environment and on-call expectations, because those depend on how many pipelines and teams you run.
Can we self-host Dagster OSS without outside help?
Yes, if your team already runs containers, PostgreSQL and Python services. The Dagster documentation covers self-hosting open-source Dagster separately from the managed Dagster+ service, and it documents deployment options including Kubernetes with Helm, Docker and Amazon ECS. The first install is rarely the hard part. The harder decisions are how the single daemon stays healthy, how code locations are isolated and deployed, how run and event log storage is backed up, how upgrades are tested against your pipelines, and how access is controlled without the Dagster+ identity and audit features. A team with an established platform group can often carry this alone. A team short on platform capacity should weigh the ongoing upkeep, especially upgrades and backups, before deciding.
When is it worth hiring a partner for Dagster OSS?
A partner is worth considering when the work has a clear boundary and the cost of a mistake is high. Examples include a deployment that a security team or external auditor must review, a platform that must be running before a fixed date, or a team that lacks the spare hours to build backups, hardening and upgrade procedures. DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. Most engagements are fixed-scope, with scope and deliverables agreed in writing. Ongoing support, upgrades and continuous testing are available as retainers. DeployOpen does not publish a price list, so a quote follows from the written scope. A partner adds less value if you only need a short evaluation of Dagster+ Solo or Starter, where there is little to implement.
Which Dagster+ features do we need for SSO and audit requirements?
Dagster's pricing page lists SAML SSO, role-based access control and audit logs as Dagster+ features, separate from free open-source Dagster. The Dagster+ deployment documentation also lists authentication with role-based access control and audit logs among the features added over open source. Self-hosted open-source Dagster therefore does not provide these controls out of the box. Confirm which plan includes each feature on the current pricing page, because Solo and Starter differ in seats and credits. Then map each requirement to evidence: who can deploy, who can see which assets, and which events are logged and how long they are retained. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or attestations. Independent auditors and certification bodies do that.
Does Dagster+ Serverless or Hybrid change where our code runs?
Yes. In Dagster+ Serverless, your Dagster code executes in Dagster's environment. In Dagster+ Hybrid, you run an execution environment on your own infrastructure that connects to the Dagster+ control plane. If data residency or network policy requires your code to stay in your own accounts, Hybrid is the option to evaluate. Serverless compute is listed at $0.010 per minute on the pricing page, but Hybrid moves hosting and upkeep of the execution environment back to your team, so the subscription bill and the operations workload shift in different directions. Confirm the exact Hybrid setup, the network path between your environment and the control plane, and the supported environments with Dagster before you commit to either model.
What changes for your team after the choice is made
Choosing self-hosted Dagster OSS makes your team the operator of every control plane component. The webserver serves the UI and GraphQL and can run multiple replicas, but the daemon that runs schedules, sensors and run queuing is a single process, and each code location server is limited to one replica. Someone must watch those processes, restart them, and treat the daemon as the component whose failure stops scheduled work silently. Plan upgrades against Dagster's release line, which moved to 1.13.26 on October 9, 2026 after 1.13.25 on October 1 and 1.13.24 on September 21, 2026. Confirm with Dagster how long each minor line receives fixes before you commit to a cadence, because the supplied material does not state a support window for open-source releases.
Security patching falls to you as well. Dagster OSS does not bring its own identity layer, RBAC or audit logs, so the access controls you put in front of the webserver, and the database that holds runs, event logs and schedules, are your responsibility. If you run the default SQLite storage for anything beyond evaluation, the storage migration to PostgreSQL is part of the same operating work. Build a check that compares your deployed image or package versions against the release notes each time you upgrade.
With Dagster+, the vendor operates the web UI, metadata stores and backend services. Your remaining duties shift toward the execution side. In Serverless, your code runs in Dagster's environment, so the vendor also operates compute. In Hybrid, you keep operating the execution environment that connects to the Dagster+ control plane, including its patching, monitoring and capacity. Ask Dagster which upgrades and security fixes apply to the control plane automatically, what notice you receive, and what support window applies to the agent you run. Those answers, not the open-source release line, define your patching obligations under this path.
How DeployOpen scopes a self-hosted Dagster rollout
The sequence turns an open-source Dagster decision into a written scope that names the hosting model, the deployment target, the integrations and the handover before any build work starts. Each step ends with a document or check the client can review.
Confirm the hosting model first
DeployOpen and the client's architecture and security leads decide whether the team is self-hosting open-source Dagster or buying Dagster+, and if Dagster+, whether Serverless or Hybrid fits the data residency and network rules. The output is a short decision record that names who owns the control plane, where code runs and which Dagster+ features, if any, are in scope. The step is done when the record is signed off by the client's named owner.
Define the deployment target
The team maps the Dagster components to the client's environment, covering the webserver, the single daemon, code location servers and the supported open-source deployment options such as Kubernetes with Helm, Docker or Amazon ECS. DeployOpen documents the cloud account, cluster or network segment, and the replica and sizing assumptions to confirm with the platform team. The step closes with a target architecture diagram that the client approves in writing.
Agree on run and event log storage
Both sides decide where run, event log and schedule storage lives, since Dagster defaults to SQLite and can use PostgreSQL. The scope records the database version, backup and restore responsibilities, and any run launcher, run coordinator or executor choices. The check is a storage decision record that names the database owner and the recovery process the client's operations team has accepted.
Scope identity and access integration
The team lists the identity provider, group mapping and access model the client requires, and records which controls come from the client's own identity stack and which would otherwise depend on Dagster+ features such as role-based access control, SAML SSO and audit logs. Security and identity owners confirm each item in the scope document. Done means every access control has a named source and a named owner.
Agree alerting and observability integrations
The team defines which pipeline failures notify which channels, such as email, Slack or PagerDuty, and where run metrics and logs are sent. Where the client needs managed alerts or Insights, the scope states whether that comes from Dagster+ or from integrations the client already runs, and it names the on-call owner for each alert path. The output is an alert routing table that operations signs off.
Document the handover before build work
DeployOpen writes the scope, deliverables, acceptance criteria and handover plan in a single document, and the client approves it before any build begins. The document also states what the client must confirm with its own vendors, auditors or environment owners. The step closes when both parties have signed the written scope, which is the basis for the quote.
Price the written scope
DeployOpen does not publish a price list. A quote follows from the approved written scope, and the cost components it reflects include the design, build, integration, hardening, documentation and handover work the client has chosen. Dagster+ subscription and credit costs are paid to Dagster and are separate from DeployOpen's fee, so the client should ask the quote to show each line item and what recurs after handover.
How DeployOpen plans, deploys and supports self-hosted Dagster
DeployOpen approaches Dagster OSS vs Dagster+ as an infrastructure decision first, then a feature decision. We map which Dagster+ capabilities your team actually needs, then plan and implement the self-hosted option inside your own cloud accounts, data centers or air-gapped networks if that is the path you choose.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope lists which Dagster OSS components are in play, such as the webserver, daemon, code locations and storage.
- We record which Dagster+ features you need, including authentication, role-based access control, audit logs and alerts.
- The scope states whether your code runs in Serverless or Hybrid, and where the execution environment will sit.
- A quote follows from the written scope, and ongoing support is available as a retainer.
How we build
- We deploy Dagster OSS to your chosen target, such as Kubernetes with Helm, Docker or Amazon ECS.
- We configure run, event log and schedule storage, choosing between the SQLite default and PostgreSQL.
- We set up the daemon, code location servers and run launcher to match your scheduling and isolation needs.
- We wire identity, alerting and audit trails to your existing systems where the chosen design requires them.
- We test pipeline runs, failure handling and upgrades in a non-production environment before cutover.
How we hand over
- We document the deployed architecture, configuration keys, secrets locations and operational runbooks for your team.
- We agree the upgrade path for Dagster releases, so your team knows how each new version gets tested and rolled out.
- We run a handover session covering on-call tasks, restore steps and how to add new assets and code locations.
- We prepare the evidence your compliance assessors may ask for, though auditors and certification bodies make their own determinations.
- We confirm with you which Dagster+ features remain outside the self-hosted scope and why.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover Dagster version upgrades, backup checks and changes to code locations as your pipelines grow.
- Security testing of the deployed environment can be scoped separately if your governance requires it.
- Ask us to confirm the support scope, response expectations and exclusions in writing before you sign.
- If you later move to Dagster+, we can scope the migration work the same way, in writing and before work starts.
