Reusable stacks for repeatable infrastructure delivery

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.

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.

Git-backed stacks are useful when a team wants the dashboard workflow for day-to-day use but still wants the source of truth for the stack template to live in a repository. Wodby can track the origin and help teams keep the imported stack aligned with upstream changes.

• Define reusable app infrastructure in a stack.yml template.
• Review stack changes in Git before they become stack revisions.
• Use one imported stack as the foundation for multiple apps and environments.

1. 1

   Choose how to start

   Add a predefined stack from the catalog, create one from scratch in the UI, or import a stack template from your Git repository using the stack template guide.
2. 2

   Configure the stack for future apps

   Prepare it as a reusable blueprint: connect buildable services, choose service versions, and define integrations and environment-aware settings once.
3. 3

   Create apps and extra environments

   Launch the application from the stack, then add development, staging, customer-specific, or other environments without recreating the infrastructure model.
4. 4

   Issue new revisions from updates or config changes

   Service updates and manual stack edits both create explicit revisions, so infrastructure changes remain visible and deliberate.
5. 5

   Upgrade each instance on its own schedule

   Roll new revisions out environment by environment when each app is ready instead of forcing one all-at-once infrastructure change.

Every change to a stack creates a new revision. Running applications keep using their current revision until you decide to upgrade them, which makes it easier to test service changes or configuration edits in lower environments before they land in production.

• Test stack changes safely before a broader rollout.
• Keep a history of how infrastructure evolved over time.
• Separate the act of changing a stack from the act of deploying it.

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.

When you use services from the Wodby catalog, the platform can alert you when stack components need attention. Catalog service updates, Git-backed service updates, and origin synchronization all flow through the stack revision model so teams can review a change before rolling it out to app instances.

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.

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.

Instead of pushing every infrastructure task into raw Kubernetes YAML or bespoke automation, Wodby exposes stack management through the same interface used for the rest of the platform. That keeps platform control accessible to product teams without removing guardrails.