Dagster orchestration stack for data pipelines, scheduled jobs, and asset-based automation workflows.
Why teams use this stack
Start new instances with the right services already linked
Use a ready service baseline.
Deploy to managed Kubernetes, VMs, or dedicated servers
Keep one stack across hosting models.
Keep services current with managed stack auto-updates
Included services get managed updates through new revisions.
Reuse one stack across all environments
Create dev, staging, and preview copies with per-environment configuration.
Choose the right database model per environment
Switch between container and managed databases.
Auto backups and data import
Upload archives to cloud storage and import between environments.
Start with recurring jobs already in place
Reuse cron schedules and lifecycle actions across environments.
Customize service configs per environment fast
Override configs and settings without rebuilding the stack.
Services
These are the services enabled by default when you create a new instance from the Dagster stack.
Stack services can be configured, added or removed for specific instances, and their versions can be changed as your workload evolves.
| Stack service | Base service | Role |
|---|---|---|
| Dagster | Primary | |
| PostgreSQL | Enabled by default |
Explore the full stack service catalog for configs, settings, actions, cron, volumes, links, backups, and imports attached to each service in this stack.
Deploy
The stack stays the same while the hosting model changes. That lets you keep one stack across lighter environments, production clusters, and self-managed servers.
Start without running a cluster in your own account when you want the most managed option.
Keep the cluster in your own cloud account while using the same stack to deploy and operate the app.
Run the same stack on a VM, bare-metal, or dedicated server when you want a leaner self-managed setup.
Explore hosting options for this stack to compare Wodby Cloud, managed Kubernetes, and K3S in more detail.
Get started
Launch this stack with the enabled services, integrations, hosting options, and managed updates outlined on this page.
Databases
This stack includes container-based databases such as PostgreSQL. You can also add managed database services when you want the database to run outside the stack.
Container databases in this stack
Managed database integrations
Explore database options for this stack for container services, managed providers, and the connection model used by this stack.
Backups
Container-based services in this stack can run automatic backups, upload archives to connected cloud storage, and import working data into other environments when teams need realistic copies.
Run automatic backups on a schedule
Keep backup workflows attached to the stack instead of rebuilding them manually for each environment.
Refresh other environments with working data
Import from an archive, uploaded file, or public URL to create realistic staging copies, onboard developers faster, or test against working data.
Upload backup archives to cloud storage
Send backup archives to third-party storage instead of keeping them only inside the platform.
Services with backup workflows
Backup storage integrations
Explore backups and migration workflows for archive destinations, restore paths, and ways to move working data onto Wodby.
Get started
Use backup and import workflows to bring existing data onto this stack or refresh another environment when teams need a realistic copy.
Configs
Configure services once, override values per environment where needed, and reuse the same setup across many environments or multiple related instances built from this stack.
Explore configs and settings in the full service catalog for the exact stack-level knobs this stack exposes.
Cron and actions
Cron schedules and lifecycle actions are part of the stack, so maintenance workflows and recurring jobs can be reused across environments instead of recreated manually.
Explore cron schedules and actions to see the repeatable maintenance and scheduled jobs defined for this stack.
Stack control
Included service updates can mark the stack as outdated. Upgrading the stack releases a new revision, but existing instances stay on their current revision until you decide to move them or enable automatic updates.
Explore stack control to see how revisions, app-by-app upgrades, and auto-updates work.
Domains and TLS
HTTP services in this stack can get technical domains with auto-renewed TLS certificates, so secure preview and non-production environments are ready without extra setup.
Explore technical domains and SSL to see how certificates are issued and renewed automatically.
Environments
Reuse the same Dagster stack for development, staging, production, customer-specific environments, or short-lived feature branches, with per-environment values and configuration overrides where needed instead of rebuilding the stack every time.
Create development and staging environments from the same stack
Teams can test against the same enabled services and integrations instead of maintaining a separate setup for non-production environments.
Spin up dedicated feature environments when teams need them
Short-lived environments can reuse the same stack instead of forcing teams to create a new stack for every branch or task.
Preview app instances on branch push are coming soon
Automatically create a new preview environment on branch push. Coming soon.
Explore app instances for reusable environments, preview apps, and branch-based workflows.
Get started
Reuse the same stack across environments without rebuilding the definition for every new instance.
FAQ
Dagster orchestration stack for data pipelines, scheduled jobs, and asset-based automation workflows. Instances created from this stack inherit the services enabled by default, attached integrations, hosting options, and stack revision history.
You can reuse the same stack for multiple similar apps and for development, staging, production, and other environment types. The stack defines the shared services and defaults, you can set different values for env types such as dev and prod, and each app instance can still be configured individually.
When an included service gets an update, the stack can be marked as outdated. Upgrading releases a new stack revision, but existing instances stay on their current revision until you upgrade selected ones manually or enable automatic updates.
External providers stay attached to the stack definition so SMTP relays, backup storage, managed databases, and related services can be reused across app instances.
Yes. Development and production instances from the same stack can run on different hosting models, including Wodby Cloud, managed Kubernetes, and K3S on a VM or dedicated server, while keeping the same stack definition and upgrade path.