Application stacks
Maintained application stacks you can customize and keep in Git
Start from a reusable stack, customize its services and configuration, and keep receiving reviewable updates without rebuilding every environment.
- Keep stack templates and stack.yml in Git
- Customize services without losing the update path
- Adopt maintained stack revisions environment by environment
Create the blueprint once and reuse it everywhere
Stacks define the services and configuration behind an application so you do not have to rebuild the same setup for every environment.
A stack contains the services your app depends on, such as Nginx, PostgreSQL, Node.js, and supporting integrations. You can start from one of Wodby's predefined stack templates or build your own, then apply that definition to any number of app instances.
- Keep service choices and configuration in one place.
- Create new environments faster because the blueprint already exists.
- Reduce drift between development, staging, and production.
Keep stack configuration in Git without giving up updates
Use a repository as the source of truth while Wodby imports the template and tracks new revisions.
A custom stack can be imported from Git using a stack.yml template. That gives platform teams a code-reviewable path for defining services, defaults, environment behavior, and the application model that other teams will reuse.
Keep the source of truth in a repository while using the dashboard for day-to-day app operations. Wodby can follow allowed Git changes and import an updated template as a new stack revision, preserving a reviewable path from code to running environments.
- Define reusable app infrastructure in a
stack.ymltemplate. - Review stack changes in Git before they become stack revisions.
- Use one imported stack as the foundation for multiple apps and environments.
- Continue receiving maintained service and origin updates through explicit revisions.
Extend stacks with catalog services, custom services, and Helm charts
A reusable stack should not be limited to the services Wodby ships by default.
Wodby catalog services cover common application components, while custom service templates let teams define their own operational surface. When the best source is an existing Helm chart, a Wodby service can wrap that chart and expose it through the same stack and app workflow.
Catalog services
Use maintained Wodby services for common runtime, database, cache, email, and supporting components.
Custom services
Define services from Git when your team needs custom settings, actions, configs, volumes, links, or integrations.
Helm chart services
Bring an existing Helm chart into the Wodby model so it can be configured, versioned, and reused in stacks.
Stay secure with maintained, reviewable stack updates
Move security and maintenance fixes forward without turning every update into an immediate production change.
Catalog service updates, Git-backed service changes, and origin synchronization all flow through the stack revision model. Running applications keep their current revision until the team or an approved automatic-upgrade policy moves them forward.
Automatic update policies can reduce routine maintenance while still preserving visibility. Teams can decide which stack services should follow upstream updates automatically and which ones need explicit review before a new revision is adopted.
- Review a new revision before it reaches a running environment.
- Test stack changes in development or staging before production.
- Use maintenance windows and per-environment upgrade policies where appropriate.
- Keep a history of stack configuration and service changes.
Handle environment differences without duplicating the stack
Consistency matters, but production, staging, and development still need different settings.
Wodby stacks support environment-aware configuration, so the same stack can apply production-only safeguards, development debugging tools, or staging-specific resource values where they belong. You get the benefits of a shared blueprint without forcing every environment to behave identically.
Next step
Standardize how your team ships infrastructure changes
Move from ad hoc environment setup to a repeatable stack model that supports safer updates and clearer ownership.